Panel

Andrew Madsen (twitter github blog)
Pete Hodgson (twitter github blog)
Rod Schmidt (twitter github infiniteNIL)
Ben Scheirman (twitter github blog NSSreencast)
Charles Max Wood (twitter github Teach Me To Code Rails Ramp Up)

Discussion
 01:33 - The Apple Developer Portal
 01:57 - When the portal goes down
 05:35 - What the Portal Does

iBooks
System Status

07:20 - Certificates and Provisioning Profiles

Wildcard Certificate
nomad
cupertino
shenzhen
venice

17:50 - Managing the Device List
 21:45 - Clients and Developer Accounts
 23:00 - NDA
 27:04 - Submitting Apps to the App Store
 29:04 - iTunes Connect
 34:24 - Rejecting Apps
 37:46 - Apps on Particular Devices
 Version Requirements
 44:05 - Entitlements
 44:44 - TSIs

Picks

FontAwesome-for-iOS (Rod)
When to use -retainCount? (Andrew)
Strange Loop (Pete)
Boxen (Pete)
Homebrew (Pete)
The Changelog (Pete)
Brian Gorby - AppResigner: Easily re-sign iOS apps (Ben)
Apple - Support - iPhone - Enterprise (Ben)
Average App Store Review Times (Ben)
Brian Stevens / Data Porters (Chuck)
Canvas by Instructure (Chuck)
Wistia (Chuck)

Next Week
 Performance Tuning with Brandon Alexander
 Transcript

[This show is sponsored by The Pragmatic Studio. The Pragmatic Studio has been teaching iOS development since November of 2008. They have a 4-day hands-on course where you'll learn all the tools, APIs, and techniques to build iOS Apps with confidence and understand how all the pieces work together. They have two courses coming up: the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

CHUCK: Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen.

ANDREW: Hi from Salt Lake City!

CHUCK: Pete Hodgson.

PETE: Hello from San Francisco where BART is not striking here.

BEN: [Chuckles]

CHUCK: Where what is not striking?

BEN: BART.

CHUCK: BART.

PETE: Bay Area Rapid Transit.

CHUCK: Rod!

ROD: Hello from Salt Lake City!

CHUCK: And we also have Ben Scheirman.

BEN: Hello from Houston where it's 180 degrees!

[Laughter]

CHUCK: I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire!

Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working.

[Chuckles]

ANDREW: Which is, sort of mostly right now.

BEN: Yeah. We'll be back soon [laughs].

CHUCK: Yup.

PETE: Except not soon.

[Laughter]

PETE: For some definition to see.

CHUCK: Yeah.

ANDREW: Oh, man!

BEN: Yeah. They have a very loose definition of soon, I think.

PETE: [Chuckles]

BEN: Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said --

CHUCK: [Laughs]

BEN: "I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

 

the first one is in July, from the 22nd - 25th, in Western Virginia, and you can get early registration up through June 21st; you can also sign up for their August course, and that's August 26th - 29th in Denver, Colorado, and you can get early registration through July 26th. If you want a private course for teams of 5 developers or more, you can also sign up on their website at pragmaticstudio.com.]

Hey everybody and welcome to Episode 16 of the iPhreaks Show! This week on our panel, we have Andrew Madsen.

Hi from Salt Lake City!

Pete Hodgson.

Hello from San Francisco where BART is not striking here.

Where what is not striking?

BART.

BART.

Bay Area Rapid Transit.

Rod!

Hello from Salt Lake City!

And we also have Ben Scheirman.

Hello from Houston where it's 180 degrees! [Laughter]

I'm Charles Max Wood from DevChat.tv. Real quickly, one of the reasons that I do this show is so that I can get work. So if you need backend work for your iPhone application and you're interested in using Ruby on Rails, I am available for hire! Alright, well let's get to the show! This week, we were talking about and having a discussion on the "Apple Developer Portal", when it's working. [Chuckles]

Which is, sort of mostly right now.

Yeah. We'll be back soon [laughs].

Yup.

Except not soon. [Laughter]

For some definition to see.

Yeah.

Oh, man!

Yeah. They have a very loose definition of soon, I think.

Do we want to start off by just talking about what happened there? I don't know if anybody has any like behind the scenes info on the portal being down, but from what I heard, they detected some sort of hack attempt. And then shortly there after, this, I think he was an Israeli hacker, or I shouldn't say hacker, security researcher, came out and said --

"I successfully exploited this thing, and I told you about it and filed a radar. I just wanted to see how deep it went," so he pulled out, I don't remember how many users' contact info from the Dev Portal, and he posted a little screencast on the type of data he got and the level. I don't know if that -- they seem to be related because it was like around the exact same time.

I think that's classic that he posted a radar [laughs].

Yeah.

Definitely from the Apple community.

I have to say that I'm really happy that Apple handled it the way it did. It's inconvenient to have the portal down, but dang it! If my information's in there, especially my credit card information and other things like that that can affect my company and things like that, pull the plug!

Yeah.

And then just tell me that we pull the plug.

I think the amount of damage that you could potentially do by having access to the Dev Portal is relatively small. Like you might be able to compromise their certificates so that you could sign your own apps for the App Store, which seems pretty big, but then they could just revoke it.

I'm kind of surprised that they haven't done that. Or, I guess that would be a serious --

Yeah, I think every iPhone would have to get some major update to the OS. [Crosstalk]

I don't think credit card information or anything like that would have been exposed or you're in at risk just because you're in different systems. But yeah, I agree. However, it does sort of remind me of kind of cowboy coding where you're like halfway through version 2 and that's on the master branch, and then somebody comes in with the, "Hey, you have a screen iCal vulnerability," and they're like, "Let's just push through version 2," and hope it gets fixed [laughs] because it seems like they're just doing like active development to say, "Okay, screw it! We're just going to release this one that's under development," instead of patching the problem.

My take on it is slightly different. I think what happened is they got this compromised, they got some security consultant in who said, "You guys have no," that could have been a real exploit; you contrast any of these machines, you need to start fresh. They went to the sys admins and they said, "We need new machines," and they said, "We have no idea how these machines are setup. They've accumulated over several years as it couldn't take us 2 weeks to even figure out how to reconfigure a new data center," and then they spent 2 weeks running around, trying to get a new data center up and running. That's my guess just based on how challenged Apple are on backend stuff and having seen kind of similar things before where you need to stand up in new environment and no one actually knows how the existing environment works.

[Chuckles] So they need to use Chef, that's what you're saying?

Yes! Actually, I think I tweeted that. I said, "I have a feeling that Apple are not using Chef or Puppet." [Laughter]

That's why.

So if anyone's on the inside and wants to confirm or deny these rumors, I would love to hear about it.

Does Chef work with WebObjects? [Laughter]

Oh man, that's a quote. [Laughter]

So when it is working, what does it do?

Wait, Chef?

WebObjects.

Well, let's see...I've been through the nightmare of setting up certificates and provisioning profile.

Does iTunes Connect to kind of those lists or does iTunes Connect to separate thing?

I think it's still online, right?

ANDREW: iTunes Connect is a separate system; it never went down.

Okay.

Right.

Yeah.

So the Portal doesn't do stuff like looking at the money you're making?

No.

Yeah.

I know when it doesn't be.

iTunes Connect is not just for developers either. It's used for, I know it's used for iBooks if you have an up book in the iBookstore; I don't know for sure about music, but I would sort of think it's used for people to sell music, too.

Oh, okay.

Oh, boy! I wish they would give stats on podcasts.

Yeah, it's kind of funny they don't.

What they did is release that status page, right? So if you go to developer.apple.com and you sign in, if you go to the portal, isn't it tell you what's up and what's down?

Yeah, it basically, in fact, I just pulled it up, the update is from the 5th, which is yesterday. And yeah, it tells you, "These services are online, blah, blah, blah. We plan to reinstate most of the remaining services this week," and then it tells you what some of those are and you can go to the status page

--

It looks like almost everything is back online now.

Yeah. Of course, I keep trying to figure out how to log in because I click on members center usually

to log in, and that's what it takes you to that page [chuckles].

Why don't we just talk about the certificates and provisioning profiles and that whole process?

Sounds good to me.

Alright -- [Crosstalk]

Does anyone know how to be able to have that work? [Laughter]

Oh, man! I've had 3 or 4 different iOS projects where each time, we stop talking about how to figure out the certs and the profiles and stuff, and I always find someone else to do it because I've just never understood it and I have this kind of vague, fuzzy idea in my head of how the pieces is up together. But if you locked me in a room without the internet and asked me to provision my iPhone [laughs], I would starve to death.

It has gotten better. When it first came out, it was a nightmare. Now, the portal will kind of guide you through the process.

Wait a minute, wait a minute. It was worst before?

Oh, man!

That was way far, far worst. Now, my solution is usually to have Xcode do it. Sometimes, if something goes wrong, I just delete everything out of Xcode's organizer and then tell it to refresh.

And the Keychain.

Yeah, exactly. 80% of the time, that fixes the problem. Before, that was not even an option because Xcode didn't do anything for Xcode didn't interface with this whole system.

Yeah. So you didn't have to go to the portal, like you could download Xcode and run things in the simulator without any kind of profiles or certificates or whatever, but as soon as you want to put it on to a device, you need to sign the build with a certificate. And the provisioning profile links a certificate to a listed devices and some other like permissions around what that app can do.

And an Apple ID; you have to tie the provisioning profile, ties the certificate, and the Apple ID.

Right. And then it has an expiration date on it so that's how they can tell your app, they're only valid for 3 months or whatever during development or ad hoc builds or whatever. Once you have all those pieces in place, then you need to go into your project and go into the settings for your target or your app's target, and go into the code signing section. There is some selection boxes, you probably want to select the automatic -- I forget what it's called -- automatic developer, and it will try to pick the provisioning profile and certificate that match. If it can't pick it, usually in that list it will tell you, "Hey, there's this provisioning profile, but it doensn't match your bundle identifier," or "Hey, there's this provisioning profile and I don't have any certificate in the Keychain that matches this," that can help you troubleshoot the issue. But if that item is selectable, then you have the backing certificate for that profile, and it matches your bundle identifier, then you select that; then you would build and run on a device, it would use that to code sign the application and run when it all works, but sometimes it doesn't [chuckles].

And you have to create a certificate for development and production as well as a provisioning profile for development and production, separate ones.

So how does the Wildcard Certificate stuff work? Because I remember coming to this stuff and doing one sort of dev profile for each developer for each app, and then one distribution profile for ad hoc builds and then one for App Store builds. And then somewhere along the line, Xcode came out with the Wildcard --

I thought the Wildcard was filled with bundle identifier? Or, is it more than just how broad the bundle identifier is?

I think it's when you create the provisioning profile, you specify an App ID, and you can instead, specify a Wildcard so then you could just use one provisioning profile for all your apps. But that doesn't work if you're using personal notifications or iCloud because you have to have a specific App ID.

Right.

Yeah, but if you're not doing that stuff, the Wildcard is on your bundle identifiers or something like com.companyname.appname, so it would be com.companyname.star. So any app in your companies that has a bundle ID that starts with your companies with those domain. In my experience, this is not that reliable. Xcode seems to create these for you at least in some case; it's a little hard for me to tell because mine's all cluttered up with stuff from multiple teams and lots and lots of projects. But I have some bundle identifiers or some provisioning profiles that matches star periods, which is any bundle identifier. It can be pretty tricky to convince Xcode to select the right one because if you've got 2 of those, then it just selects somewhere in there, and it's often the wrong thing.

Yeah, I was actually working with a company that they were writing -- I don't think they were writing the app, I think they were updating the app to do push notifications for their client, and I was writing the backend portion of that. So I was writing the part that would send the notifications to the phones. It was really interesting because the developer I was working with, after like the second or third time of him trying to explain to me how to setup a provisioning profile so that I could just build and put the app on my phone myself, I had the certificate already installed so he just sent me the app and I just copied it into the phone using Xcode. So the system, to me, is still kind of a blackbox mystery, sort of hard to use because I don't completely understand how all the pieces go together.

I don't know if you guys used the app like the NOMAD tools, the stuff --

Cupertino.

Shenzhen.

Yeah, I've used them a handful of times, not like as a whole package, but usually it's just like individuals one, like Cupertino is pretty cool. You can use it to automatically list and add devices to your portal. This is something that Xcode does if you plug it in to the list, but if you wanted to do something like automate the process by automatically adding your company's devices to a portal or something like that, you could use this tool to do that.

I think I've used shenzhen. I've used Cupertino kind of in an attempt to find a better, more understandable UI than Xcode, and the developer sends a website. I like it because it's a little bit clearer because I get really confused as to where I go to find this information because it's like different; some of it is on the [inaudible] sent us, some of it is in Xcode, some of it is in like the Keychain - the system, so that's kind of nice. I've tried to use shenzhen which helps you sign your applications and distribute them. I've played around using that for building distributing an app in Objective C.

That one was a little bit too...I won't say opinionated, but it had some assumptions about how you build your app. When I first looked at this, it didn't even work with workspaces so we had to work around that somehow. So we used one called "BetaBuilder", which is kind of older and it's not, I don't think it's being maintained anymore, but we had some minor additions to BetaBuilder to build and publish our app to TestFlight. But it has done the same thing as just in shenzhen where you can just do command-line building, get an IPA, and upload it to somewhere.

I use Venice.

Which one is the Venice?

It's verifying In-App Purchase Receipts. I don't do that from the command-line, but this is like, the command-line, it's just a thin layer over the Venice gem. Actually, when I started using this, it was really clean, I like the way it's done, and it automatically builds in support for checking production servers first, and then checking this inbox servers for In-App Purchase Receipts. This may be a little bit of sort of a side step to the conversation, but when you are working with In-App Purchases, you have this Test Mode, in which case you go to the Sandbox IAP servers so when you actually buy something, it doesn't charge you. And then when you're ready to submit your app, you need to flip those things to live, put those things to okay to approve it until Apple approves your app. So you're in this sort of chicken and the egg scenario where you want to push a live version of the app with live In-App Purchase products, but you have to wait until Apple approves them first. So what you end up doing is making the app work with Sandbox or production receipts, and then you try to verify them with the production server always first. If you get back with a specific error code, then you will then try again with the Sandbox servers. That way, as soon as you flip the switch live once, it go straight to production. That's the tip that I learned by attending a WWDC session on In-App Purchases. But anyway, Venice supports app natively so you just don't have to worry about it. The one thing that it didn't support, which I ended up adding, was support for the auto-renewable subscriptions which require a shared secret with iTunes; it was a simple addition to make. So, that's the one I use.

Rod, I'm a little curious, how does all this stuff with the provisioning and certificates work with RubyMotion?

I think it's pretty much the same. I haven't actually done it with RubyMotion yet, I haven't gotten that far. You pretty much have to go to the same and you probably have to put it in the rakefile for the RubyMotion project. Actually, I did do it once. It's kind of a bang, you have to paste in that whole, that name of the provisioning profile, which is [inaudible], it's no name so it's kind of a bang. So something like Cupertino and shenzhen might come in useful in that situation [inaudible].

Yeah, because presumably, RubyMotion just produces an IPA and then you just need to sign it with the appropriate things.

Yup. What else is in the portal? We talked about certificates and provisioning, there are a lot of other things in there aren't there, that we can talk about?

You have to manage the device list pretty carefully. It's kind of like a plant that you have to like prune it from time ot time.

They treat it on growth, make it get too big. Because you only get 100 devices, is that right?

Yeah, a hundred.

So you get 100 devices, and it seems like a lot if you're an individual. But if you do projects for clients, we at ChaiONE, we ran out of space really quickly by doing client work. Eventually, we just got to the point where we had to say, make our world say, "Okay, our clients are going to provide their own account from day 1," so we don't get into this mess where the client may have fight with their own people that they want to have on the app, and we have 20 employees or whatever we had at a time. It's just gets really old really fast with all the test devices and things that you want to add. It's unfortunate for established development shops to not be able to request to access for more or whatever. And then the worst part about it is when you delete a device, you have to wait until your renewal period for that slot to become available again, so you have to be careful. Once you invite people, if they no longer beta testing your app or those are no longer clients of yours or whatever, then go and then remove them as soon as possible so that you can free up those slots for the next renewal period.

How often does that renewal happen? I think it used to be once a year, right?

Yup.

But I think you can request a more frequent renewal if you have a good reason. So Ben, if you think it's tough being a dev shop, imagine being a really, really large organization like thousands of developers organization and technically having to share one organization.

If you have more than a couple of hundred employees, then you could qualify for the enterprise account, right? In which case, you have an unlimited device list.

Is that the reason that they've done that? Or, is that been there for a while?

It's been there since I've been in this industry. As far as I know, they've had enterprise development. But you had to have like 200 employee in minimum or something like that.

I was working for a big old bank and they had a device list that they have to manage. I definitely learned about renewal periods while I was there, so I don't know, maybe they just didn't know that they were able to do that.

I've only had limited experience with the whole enterprise distribution model because you don't have a specific device to use instead.

Yeah, seriously, if you're doing enterprise distribution.

Yeah. So if you wanted to build an app and distribute it to your own internal company, as long as everybody is still covered by the NDA, you have to be careful about that. Like, some of these larger companies have sub-companies so they'll have an internal development organization that builds apps for the business, and people in the "business units" that are paying for this. It's kind of weird to talk about it like this because it's all the same company, but it's like inter-departmental budgets and they have a budget for an app and they contract with their internal team to build it. You have to be careful about not giving pretty really software to folks even within your own company if they're not covered by an NDA. One of the problems that we're facing right now, and a lot of companies are, is that iOS 7 is coming out very, very soon, and we'd like to start doing all of our apps iOS 7 only, if possible. But, how do you do beta testing when your clients may not be covered by the

NDA?

Interesting.

So you have to be careful there because then they would have to install iOS 7 on their phone in order to test it.

That's an interesting problem; I haven't thought of that.

Do your clients push back on having to have their own developer account?

No, we just write it into our contract like, "Day 1, you got to do this," because we've seen it take a long time. And one of our clients accidentally started out with the enterprise one and had to contact Apple to get them to undo it. We didn't really see this a red flag until we were like 2 weeks into the project and still haven't been approved yet, so then they started that process. It was over a month before we had a developer account for them. So because that's a risk to the project, we want to make sure that we can start off immediately like, "Day 1, go here sign up for this," we'll advice them on which one to get. But yeah, it's written into the timeline.

But they accept that?

Yup! Not a single client.

And that, if they sign up, then they're on the NDA, aren't they?

Yeah, but it depends. If you are part of a larger company and you stand up for it, not the entire company is under the NDA. I don't know exactly how that works; you just have to be careful. Like I was saying, for a larger organization, the internal development team is definitely covered by the NDA, but the business at large is not.

Let's talk a little bit about the NDA for a minute. So when you sign up for a developer account, you agree to an NDA and non-disclosure agreement that says that you won't talk about certain aspects of what Apple provides to you in your developer account. In other words, you can't show off latest software, you can't talk about certain aspects or certain features of that software, are there other areas that you're restricting from?

I think just beta software and the SDK and stuff that are still not finished.

And released.

Typically, the line that people draw in the sand is, "Whatever is announced at WWDC during the Keynote is dream to the world so it's therefore public." And then everything that happens that week of WWDC after the Keynote is covered under the NDA, and they remind you that every step of the way. So if you tweet about it, chances are somebody is going to see it and then you'll get put on the lists somewhere and who knows what will happen, but you'd probably don't want to be on that list. Then when iOS 7 gets released or whatever the version is to the public, then at that point, you've had this knowledge for all those time, you've had time to play with it to be given, and had chance to talk about it. You'll expect all kinds of books and conference talks and articles and all kinds of material to come out at that time. But during in this between periods, it's just kind of a bit awkward because we want to start switching to the new stuff, but we can't really talk about it.

Now, if I remember right, there are also videos and things from WWDC that you can watch on here?

Right. But you have to be a developer to get access to those. Again, by signing up for the developer account, you've signed the NDA.

Right. And then you can see the conference videos and what have you.

Uhm-hmm.

Hey, you don't need a paid account to access the videos anymore, right? It used to need a paid account; well you used to not be able to get the videos without paying extra. But I think last year, they made it so anyone with a free account could watch the videos, is that right?

Only free developer can as the Safari developer can, if I remember it though.

No, that's not true. You can sign up for a login to the developer website without paying. You just won't get the stuff you get when you pay it, which is like a go to eat a run, or ability to do provisioning and run your apps on device, that kind of thing. But just to get access for documentation when --

Right. Because if you're just getting started with iOS development, you can write iOS apps or Mac development, you can write Mac apps or iOS apps and compile them and play with them; you just can't release them in the App Store so you need to be able to read the docs in order to do that especially. And the docs are hidden behind the developer file because of the NDA thing.

Got you.

Aren't those student accounts, too?

Probably. I don't know. Do you guys know any other development or any other software organization that does the NDA thing like Apple does? It seems like it's quite unique to the Apple philosophy?

I don't know. When I was in the Microsoft community, I went to the MVP center a couple of times, and they were similar brain like, "You're not supposed to talk about this stuff."

Okay.

I was listening to one of the tweet shows, I don't remember which one, This Week in Tech, and Leo Laporte went to an event for Google. Basically, it said that there were certain parts of it that he could talk about, and certain parts of it that he had to sign an NDA in order to see. I think it just depends on how strategic they're trying to be with it. But it seems like Apple is that way more than well to the other organizations.

The Microsoft MVP community was like 5000 developers or something; it was like a select group of people. So it's a much smaller thing, it's easier to keep the lid on that. So as then every Apple developer because I don't know how many registered Apple developers there are, but there's a whole bunch.

Yup.

They've said how many registered developers; I think how many paid developers there are, and it's a huge number - half a million or more.

Yeah. It's pretty chained.

Yup. So it looks like there's also a whole bunch of information. You talked about iTunes Connect, then there's an Appstore resource center, is this how you submit your apps to the App Store, is through the developer portal?

You actually submit your app -- well, most people probably just submit their apps through Xcode, but that's actually something that's in iTunes Connect.

Yeah, the only thing that a portal does is it give you access to generate a distribution certificate for that bundle identifier. You can figure the services that you want in a App Store provisioning profile, so if you want to talk to Game Center or In-App Purchases or iCloud, and you need to check those boxes and configure those certificates as well. Once you have that, then basically the portal is out of the question; you just have a distribution build. To submit it, you then go to iTunes Connect. iTunes Connect has a bunch of forms for you to fill out on what's the app name, the icon, the artwork, and keywords, all the information like privacy policy, URL, support URL, email addresses, the screen shots. Once you all have stuff in there, you'd say, "Ready to upload binary" in the iTunes Connect. This is something that savvy client or business owner could potentially do if they are familiar with the process. And then you could be the guy with Xcode who just says, "Okay, I'm ready to submit," and you would go into the product menu and, say, archive and tell it that you want your App Store built configuration. At that point, it will look in the portal to see which apps in iTunes Connect are ready for binaries so it will match up the version name and then you could submit it from there. But doesn't that still require you to login using somebody with permission to submit application?

Yes. But that actually, I think, is a function of an iTunes Connect user as well.

Let's talk about iTunes Connect for a minute. I think we've pretty well covered what the Developer Portal gives you, unless I missed something.

Yeah, I think we've covered that. It's just devices, certificates, identifiers, profiles --

They're just software.

There are ad hoc builds, I think we've talked about that. But it touches the different provisioning profile, and then you can distribute it for beta testing.

So iTunes Connect does all your sales reports like the submission process we just talked about like screen shots and keywords and all that stuff, whatever shows up in the store, and then you'll download your sales reports from iTunes Connect as well. This would be the same if you're like a musician and you were selling music on iTunes.

You also manage all of the information Apple needs from you to sell your apps. So contracts you have with them, tax information, bank account where they deposit your money in, that kind of thing.

Yeah, that makes sense.

And every time you log in, there's something new that you have to agree. [Laughter]

Yeah, I just did that actually.

Yeah, me too!

Well, that space's is unavailable, hasn't it because of the outage?

Yeah. I haven't had to go in for -- this whole period hasn't really effected me too much so I've been lucky, but when I just logged in --

iTunes Connect is listed on that stages page. So I guess, maybe it was always up and they wanted to put something green straight away.

Quickly.

Are there marketing resources that it makes it look like, and I haven't actually ever signed into iTunes Connect, are there marketing resources for your apps or anything like that?

It's mainly analytics and stuff around sales without contracting any of that stuff - contracting bank information.

Do these reports include free apps?

Yup!

Yes. You don't get any money from them, but you can see how many people downloaded your app.

And you can also, I think it's in iTunes Connect, you kind of manage like you can check on way or app is in the review process and kind of, if you're releasing a new version of the (someone correct me if I'm wrong here) if you're releasing a new version of your app, you can kind of see you submit the new version but the old version is what's currently on the App Store and then you can kind of, when you submit the app, you can say, "Release it as soon as it's ready" or you can kind of say, "Do the review now, but don't release it until I'm ready" and then I think iTunes Connect is where you go in there and kind of pull the trigger as it where and say, "I want to release the new version now".

In the developer's center, there are resources such as the images for the buttons that say "Available on the App Store" that you could put on your website as well as images of devices that you can use to create images.

I just found that! It's hilarious. I've been looking for those images for so long [chuckles] --

When I'm making a slide deck, often I want an iPhone image. But then I read the, of course, I read the contract and it says, "No, you'll have to use it for marketing or your application," and if I did it in any other way, I would be put on the list. [Laughter]

Yeah, don't get on the list!

[Chuckles] But yeah, the main interaction I've had with iTunes Connect, between interactions, is looking at the depressing graph that shows me that no one's downloading my application -[Laughter]

And then, reading the reason why my application was rejected from the App Store. [Laughs] That really is most of my time I spent.

Are they pretty good about telling you what it is about your app that they don't like?

Yeah, well, they'll be nice.

In my experience, they happen.

Sometimes, they're very vague especially when they reject you. My app Favors, which is a Passbook app was rejected in getting information out of them about, it's almost like they can't talk about it, they can't tell you the real reason, you kind of have to read between the lines.

I think it kind of depends on the context. For example, I have a Mac app which I tried to update to do the Sandboxing thing, and I didn't do it right and they just rejected it and said, "It doesn't conform to the Sandboxing requirements," that's kind of fairly clear. But if your app is using an internal API, for example, and they detect that, I think they're a little bit kind of vague about it because they don't want to tell you -- I don't know why, actually. But I guess I can kind of see the motion [inaudible], they don't want to tell you like what you've been trying to do in case everyone learned that there's this thing that they're checking for or something, I don't know.

Yeah, it's like they're still trying to make up their mind. In my case, they didn't like the way I was using coupons; they didn't think the way I used coupons was the way they wanted coupons to be treated. So it's like it's still in motion and they don't want to pin it down.

Yeah.

Interesting. They don't want to set a legal precedent on iTunes.

Maybe. I kind of think it is like that. Because you could take this stuff and write a blog post about it so they don't want to go on the record with this stuff. I think maybe it's because there must be an army of these guys or these folks doing these reviews and maybe they don't want to get in trouble with their supervisor for saying something that's not correct.

I'm a little bit curious, I've heard a few things about why they reject apps or some of the things they reject apps for, maybe you can verify some of these for me. One of the ones that was a little bit strange that I heard is that if you build the app and you allow on a phone, not on an iPad, just on the phone, if you allow the UpsideDown orientation that they will reject it? [Crosstalk]

I don't think that they will, but there should be a reason why you used UpsideDown orientation, and I agree with this actually. I think it's really sort of disorienting to be using a phone like, say, embed or whatever and I turn it, the UpsideDown orientation, and the whole interface flips up. So now I expect the home button to be at the bottom and it's not there anymore. To me, I don't think that that should be allowed, unless there's a reason why your app should rotate to that way. If so, then you could use it. But that wasn't always a rule; that came out actually after...I'm trying to remember when that came out actually.

Xcode still supports it; you can put that in orientation.

Yeah, you can set it. I just think that there needs to be a reason why you set it. And I don't know any like high-profile rejections for that specific setting.

The other one I've heard is for performance reasons. If it's too slow, or if the graphics aren't of high enough quality, I've heard that one, too.

The problem is there's so many examples of really terrible-looking apps on the store, it clearly don't follow those rules.

If your app, when it starts up, it doesn't start up within a minute, I think, it automatically --

I think it's like 20 seconds.

They'd probably reject you for that if that couldn't even start --

Yeah, they will definitely reject you if your app crashes on start up.

Yeah.

I think it's an unofficial error, undocumented timeframe, but I think it's 20 seconds. If you don't return quickly from the applicationDidFinishLaunching method, some people will end up going to download things on the main thread not realizing that they're delaying their application from launching until that's completed. So the watched out process will actually kill it if you're on a slow network connection or if that file ends up getting too big or whatever. We got rejected one time. We wanted to do an app for a client that basically, it was like World Cup was starting in like 2 weeks or something like that, and they're like, "Okay, we want to build this app for the World Cup," and I was like, "It's too late." So they were like, "Okay, what can we do?" and so we sort of brainstormed and we're like, "Okay, we can do this sort of interactive Twitter thing on a team basis, and it would just like show you the tweets for that particular flag, and then we'd be able to knock out the flags that were out of the torment," that was easy enough. So we built it in the weekend and submitted it; we called that World Cup Chatter. That got rejected because the term 'World Cup' is registered trademark of FIFA, and we're like, "Oh, man! How do we describe the app now?" Maybe we should have called it 'World Soccer Chatter' or something like that, that would have been a better choice. Now, what we did choose, which is just shorten it to WC Chatter, which I found out later from our

British friends that WC is typically referred to as the water faucet -[Laughter]

That's a totally different app, and that was a funny mistake. But then if the app got approved with that, then it went on the store, but only shortly after the World Cup has started.

One other thing that I want to ask is, can you push apps out for specific markets like the US App Store versus worldwide App Store?

Yes.

The other one is, does iTunes manage whether or not an app can be installed on a particular device? For example, I have an iPad 1; it only runs iOS 5 that doesn't run iOS 6, so it doesn't run certain apps. Does iTunes check for that? Or, do I have to tell it that it'll be run on iOS 6?

Yeah, you put the version requirements per app. It won't even show up on the store for an app like you wouldn't be able to search for an app that's iOS 6 only on your iPad 1. But if you support iOS 5.0 but you specifically don't want the iPad 1, there's no way to do that.

Okay.

I think that there is a way to specify requirements of your app like you could say, "My app requires telefony," in which case it would only at both iPads and iPod Touches, this requires real GPS or whatever.

There's actually a fairly long list of those hard work abilities that you can say you require.

That's [inaudible] unless you actually require them, then you can get rejected for not wanting to be in, like if you're gaming it because you don't want your app to be an iPad app, then they can reject you because you don't actually need telefony.

Right. We actually had this problem with an app that I worked on last year where we, for performance reasons, did not want to let it run on the original iPad or on the iPhone 4, and there's no way for us to say that because you can support version of the OS, any version of the OS, but this was at during iOS 5 and those both supported iOS 5. So we thought about requiring bluetooth 4.0 which would exclude the iPhone 4 and the iPad 1, which you can do, but we didn't actually used bluetooth 4.0, and that was pretty clear, so we ended up just having to basically put a disclaimer in the App Store listing that said, "This app may not run great on an iPad 1." You'll actually notice, though, that Apple does not have that same restriction on their own apps so they apps that require certain, like the new phone comes up, it might have an app that only runs on that phone so they don't have to follow their own rules.

Yeah, when you make the playground, I guess you get to do that.

Yup.

I think the most common, well, maybe not the most common, but in my experience, one of the most common reasons for rejection was accidentally using an internal API.

We did that one time.

Oopps!

[Laughs] We found out about it right away, and luckily, we keep our data pretty up to date in our staging system. But we ended having to do a DNS switch to say, "Okay, the staging is no longer staging." [Laughter]

It's now production. And we came up with a new name for staging, and once we got the update, we will double check who's using that older version. Eventually, we were able to say, "Okay, we can switch to the new one." But there was sort of short of period of time in that window like couple of hours when somebody went and created an account in staging, we have to migrate it over to production. That was not fun. So what we ended up doing as a result of that is just making it a part of our scripts that it's impossible to create an App Store build at this point of the staging, and there used to be a manual checkbox that we'd check. Eventually, those things, after like a year over regular deployment, eventually, somebody forgets to check that when they do the deployment. Things like that happen so you got to sort of account for human error and make it a non-issue by scripting.

I guess you could use DNS, maybe you could set up file where you do try the networking thing so you can only hit staging from your internal network and then presumably, the review, when you put that in for review, someone would notice. That would be an interesting experiment. Actually, I did a Facebook app and in order to use the application, you had to log in. And with Facebook, you can tell when people log in to use your application because you're using the Facebook APIs. So I could actually see when the reviewer was logging in [laughs], which is kind of cool. So I knew that the app was actually being reviewed because there was only one person using the app because it haven't been released in the App Store yet.

Alright, is there anything else that we want to cover related to online portals?

I think that's it. It's kind of a dry topic, but once you've sort of learned the magic incantations of this provisioning process, then you'd proceed on with your app and you do development, and then you forget it all. So the more Xcode helps out with this stuff, the better.

And then you have to figure out again when you have to do it again.

Yeah.

This whole provisioning and certificates thing is really every iOS developer's least favorite thing.

Yeah. I feel like there's a pessimist there. I think maybe someone could start a business as a provisioning consultant [chuckles].

What a horrible, horrible existence. [Laughter]

Oh, man!

That's like choosing to be like the bathroom cleaner.

You could charge like thousands of dollars an hour maybe, or maybe not. [Laughter]

Do you guys remember that in your ad hoc builds, you would have to add an Entitlements.plist, and then inside the Entitlements.plist, you would have to add a key called "get-task-allow", and uncheck it.

Which, I don't remember looking into it to see what the heck does that even mean? I think it was something related to like 'can processes debug themselves' or 'can we attach process to debug it', or something like that. I don't even remember, but I remember thinking, "Oh! That was just one of the items in my mental checklist. Did you have the Entitlements.plist? Does it have get-task-allow? Is it unchecked? Is it plugged in?" [Laughter]

That's no longer needed, by the way, for those listening and trying to follow along.

I was just thinking like, "Wait, what?"

Do you have to use Entitlements of all anymore? What is that for?

I think you do if you use like Game Center iCloud, right?

Yeah.

For Sandboxing.

It creates all that stuff for you, but I don't think you have to ever touch it.

Sandboxing on the Mac.

Yeah, that's what my current application got rejected just recently; I didn't do the Entitlements right, but I have no idea. So I have to say that the rejection things are clear; the rejections I just said, this was just like basically copying and pasting the rules around Sandboxing. They do it like, "Okay, I don't understand it clearly," [Laughter]

So retelling me in exact the same way it's going to --

One other thing maybe we should point out is that there's the TSIs, the Technical Support Incidence. So if you have something like that where you need somebody to take a look at it, you can use them for technical issues, but also for design reviews and I believe like App Store review issues that you're having. You get 2 per year, and I always forget to use them. So I'm always trying to find new ways of like, "Should I spend one on this thing?" Sometimes, they're pretty helpful.

Maybe I'll do that!

Yeah, I've been a Mac developer for 8 years and I have never once used one of those tech support incidence.

I really opt to.

Yeah!

ROD: iCloud probably be a good use for it.

Yeah! The other thing is if this is related to client work, there's no reason why I couldn't use the client's TSI for that, so then like my personal want or my company's, those always go unused. It seems like we always have one weak in pill form.

And you can also pay for those, right?

I think so, yeah.

I suspect, the average client would be okay if you'd billing that rather than billing them for 2 hours of beating your head against the keyboard.

Yeah, and with a lot of the potential problems you might ask there, even 2 hours is not going to get you anywhere.

Right.

Alright, let's go ahead and wrap this show up. Thanks for coming everybody! Let's do the picks.

Rod, why don't you start this off?

My pick is going to be "iOS FontAwesome", the same font icons that are in Bootstrap. You can also use in your iOS app so you can use fonts that have icons that will size whatever size you need; I have a link to an article that shows you how to do that. And, that's my pick!

Alright! Andrew, what are your picks?

My pick for this week is "whentouseretaincount.com".

You've spent any time on Stack Overflow in Objective C tags, you have seen this before, but it's a good explanation of when you should or should not use the -retainCount method.

That's awesome. "Here's a short and mildly abusive explanation why."

Was that the one where they were using key-value observing?

[Chuckles] Yeah. It's just hilarious.

They were doing key-value observing on -retainCount to find out when an object was deallocated.

Wow!

Yeah.

And this guy had like 9000 reputation. He had like the same reputation on Stack Overflow I do, and it was all in the iOS and Objective C tags, which makes you realize that bad reputation is not worth very much.

It's just a popularity contest, guys.

Or work someone as the most 3 time on their hand.

Right.

Yeah, that's true. Yup, most of my rep is still from .NET, which I haven't answered in over 3 years, any questions.

Yeah. You can get reputation without knowing anything as long as you hang out all day and try to answer questions first even with a kind of terrible answer because somebody will come along, give your point.

Because they don't know any better; they don't you, and it's just terrible.

That's my new business model: Stack Overflow Consultant.

How to gain the Stack Overflow system.

There you go. Write an eBook.

Oh, yeah!

Pete, what are your picks?

Today, I have few picks. I think I have established a pretty solid tradition of doing self-promotion as part of my pick, so I'm going to continue that, that highlight tradition. My first pick is a conference called "strangeloop". It's sold out, but the reason I'm picking it is because I'm doing a workshop there on iOS Unit Testing, and I'm going to be doing a free version of the workshop in San Francisco, a couple of them actually, in August or end of August, beginning of September. So if you want to learn about iOS Unit Testing and you are in the San Francisco Bay Area, then get in contact with me via Twitter or some other means, and I'll give you more details on that. My second pick is a tool from GitHub called "Boxen". Last night, I received from work a brand new laptop, which is quite exciting; I've had that wonderful, new mac smell. I promptly started using this tool called Boxen to set that up. Boxen is this kind of way to script, setting up a new developer machine. It does loads and loads of stuff; it uses Puppet under the hood, but it can do stuff like install software, set up keyboard shortcuts, or set up whether the dark is hidden or not, all the kind of stuff that when used using a new machine, you kind of spend like 2-3 days or 2 or 3 months maybe [inaudible] around, getting it setup, Boxen will do all that for you in an automated way. So it's pretty cool, fun technology to play with definitely. My third pick is a tool called "Homebrew", Boxen uses Homebrew under the covers to install all of its software. If you haven't used Homebrew, you should definitely check it out. I think maybe someone else has probably picked it already, but I'll pick it. And then my final pick is a rival podcast because it's a competition as podcasting business called "The Changelog". The newest episode, which is an interview with Mattt Thompson, talking about his stuff. I actually don't know what it's about because it initially just got released as we record this podcast, but I know Mattt Thompson is an interesting guy and he is an iOS person. And The Changelog is a really, really good show; it covers fresh and new open source, and they've been going for a long time and they do stuff. So that's all, again, Changelog. That's it!

Awesome. Ben, did we hear your picks?

No [chuckles].

Can we?

Sure! My first pick is "AppResigner". AppResigner is a free little app that will strip out the provisioning profile that an app was signed with and allow you to resign it with your own. This was super handy at one time when a client came to us who's developer had taken all the code and run basically, and then his ad hoc build expired and he wanted us to retribute the same app. So I was able to use AppResigner to resign it so that we could use it on our phones. The only other way you can do that is by Jailbreaking your phone, which is a choice that you might make. But in this case, AppResigner was pretty awesome. My next pick is the "iPhone Configuration Utility", which is pretty handy when you want to like plug in somebody else's phone and install provisioning profile or an ad hoc app or whatever without going through iTunes. It also lets you access the console logs, or somebody who just experienced the bug and you know it's in the logs, you can just plug in your phone into it. Some of that ability is available in Xcode, but if you need to do this remotely, then you can have somebody download this little tool. There's this link that you'd have to scroll down at the bottom of that enterprise link to find it for OS X and Windows. And then my last pick is going to be "Review Times", it's an App Store Review Times Service. It scrapes Twitter for specially formatted tweets saying, "My iOS App Time was approved in 3 days," or 5 days or whatever it is, and it aggragates and grasp those values over time. Like right now, the average review time for an iOS app is 5 days and same for Mac App Store, but it shows you like the rolling 30-day trend. Some of these, like when the Mac App Store first came out, you're looking at 30-40 day wait time, so it was good to see that trend to go downward.

I kind of like the time that it takes for WWDC to sell out that goes downward.

[Laughs] Yeah.

Sometimes, it goes up though. Last year, there was a period...I don't remember, iOS times were really high, too, but Mac App Store times were a month, one month.

Yeah.

Wow!

It's just pretty cool.

I don't know if they get backed up doing other things, or maybe reviews need to be more scrutinous or whatever, but we're trying to plan timelines with clients that's really difficult to lock down dates so we usually tell people, "Okay, you need to plan on it like 2 weeks," it's a pretty healthy estimate. But if you get a rejection, that doesn't give you much time to address it. So I would never go to this and say, "Oh, it will take 5 days because your app might be different," but this gives you an idea of what you can say with some amount of confidence.

Awesome. Alright, I'm going to go ahead and give out some picks. First off, I was fighting an issue on one of my servers so I tweeted that I was having this problem. I got some help from a fellow named Brian Stevens, he is @bdstevens on Twitter and you can find him at "DataPorters.com. This is kind of a thank you and a pick because he was super helpful in getting that little issue figured out. Another pick that I have, I've been putting together this Rails Ramp Up Course, and I've been hosting it using Instructure's "Canvas". I'll put a link to that in the show notes as well. They've released an open source version, and that's what I've been using. And then to post the videos, I've been posting them on "Wistia", that's W-I-S-T-I-A.com. It has been awesome for posting and plugging in videos. They have a whole bunch of other features, they have social sharing, you can also put in like a call-to-actions, you can say, "Hey, sign up for my email list," or whatever. Anyway, it's terrific. So I've really been liking it; I'm probably going to move a lot of my video hosting over to it. So Wistia is my pick there. That's pretty much it! Thanks again for coming guys! We'll wrap the show up, we'll catch you all in a week!