Choosing a name for your iOS app

As you can imagine, you can't have 2 apps with exactly the same name in the App Store. So grabbing an app name is like grabbing a good domain name. First come first serve. For domain names you probably know that some people registered desirable domains, with no intention to actually use them, only to resell them to the highest bidder. Apple learned something from that, and they try to prevent namejacking. So once you create an app in iTunes Connect, occupying a name, you have a 120 days grace period to submit your app for review. If you fail to do so, the app will be automatically removed from the system and you'll lose the right to use that name ever again under your account.

When that happens you'll get an email from Apple saying that:

You did not upload a binary for your app, ***, during the 120-day grace period. As a result, the app has been deleted from iTunes Connect.
This app cannot be restored, nor can you use the App Name or SKU for any other app under your account in the future.

The same happens when you explicitly delete an app from your account, either before your grace period expires, or if the app is already live.

Deleting it will permanently remove it from iTunes Connect, along with any associated In-App Purchases. The App Name and SKU will not be reusable, even once the app is deleted. 

There are a a few ways to mitigate the risk of losing your app name:

1. Once you grabbed a name, submit the app, any app, perhaps with limited functionality, or even unrelated functionality. Something that Apple would accept in their store. Example apps would be a native wrapper for a web site, PDF publication or a simple app perhaps built off some sample code available from either Apple or 3rd parties. For a competent developer 120 days should be enough to build a version 1.0 of most apps.

2. If you're approaching the end of the grace period, you could try to open a new account, maybe under a different name, of a relative or associate, and move the name to the new account to get a new extension. You'd have to relinquish it from your current account, before it can be registered to the new one.

3. Register the domain matching the app name. That may deter people form trying to use it.

4. Register the name as a trademark. That may give you a legal recourse in claiming ownership with Apple or infringers.

If it comes to worse, and you lose your name, you can still publish your app using variations of that name.

How to deal with "Cannot connect to iTunes Store" errors

Even after I got plenty of experience building apps with in-app purchase capabilities, having gone through the lessons learned at my first attempt, today I was still hit by this error. My purchase attempt on the sandbox would still fail with this laconic message. This is ridiculous. Apple still doesn't provide enough information, or even a small hint of what could be wrong.

Like I mentioned in my post referred to above, you should first check your provisioning profile, to make sure it's bound to a fully qualified app id, not one with a wildcard. In my case it wasn't, even if I should have known better. D'uh ! That's easy to fix, right ? In Xcode I just go in the build settings for the project and set the code signing identity for Debug builds. Any sane person would expect that to be enough. Not so, the build settings for the actual target is still stuck at the old, incorrect, value. That's arguably a bug in Xcode. Why would one have the same setting available in 2 different places is beyond me. Anyway, I had to fix the setting for the target to match that for the project. To my frustration the same "Cannot connect to iTunes Store" failure kept popping.

At that point the only thing I could think of is that Apple's sandbox lost its marbles. So I created a new test account. Tada ! It worked. This is insane. Having to deal with such issues, with deadlines looming, it's the last thing one could wish for. Unfortunately it's not the first time it happens. I had other issues in the past, so ridiculous as having tests accounts used on the sandbox locked, after repeatedly being denied login. After filing a bug report for that lock-out Apple came back with some sort of explanation citing recent changes/"fixes" to the sandbox and prompting me to try again.

I hope my experience could be useful to you if you run into some similar issues. Do you know any other relevant tricks ? If so please comment.

How to deal with "A network timeout error occurred. Please try again later." in iTunes Connect

I first encountered this error about a week ago, while trying to set up a new purchase item for an existent app. Given the recommendation to try again later, I assumed it's a transient error and I ignored it.

About a week later I tried again, with the same result:

Hmm, now this doesn't look any more like a transient error, unless a really unlikely coincidence it at play here. In any case I alerted Apple. Then I figured I should also try with a different browser, and sure enough it works fine with Safari.

So if you're getting this too, try switching to Safari and you may be able to work around it.

Hidden, recurrent costs of developing iOS apps

So you're thinking of building an iOS app for that great idea you have. Awesome ! But if you're not an expert in iOS development you'll need to hire one to build it for you, or maybe you're thinking of using one of those cookie-cutting app makers, that promise "no coding required".

If you want something to stand out from the competition, or if you have some special requirements, your only choice is custom development, with "plenty of coding required". Assuming you're doing it the right way, which will be the subject of a future post, you'll soon figure out that this is going to set you back a certain amount of coin. Just be aware that the sum you're contemplating at that point, based on the quote you got from the developer, is most likely only going to cover the cost of development. Is that all there is ? Well, not really, you'll also need to consider some recurrent, or revolving, costs.

Why recurrent costs ? Well, for one, if you have the app published under your own account, which is probably going to be the case if you're building a custom app, there's the $99 annual membership fee for Apple's Developer Program. Beyond that you'll need to think about the maintenance of the app. What ? Maintenance, like car or building maintenance ? Exactly.

You see, what happens is, these apps are not built in a vacuum, from scratch. Instead they're built on top of an existent platform, the iOS system, which keeps evolving. No doubt you're familiar with the fact that Apple periodically issues updates to the iOS system, indicated by different versions, like iOS 2.1, 3.1, 3.2, 4.2, 4.3, and so on. All these updates add new functionality, and, here's the rub, sometimes change existent functionality. That's right, stuff that used to work in older and current versions of iOS will stop working in future versions.

Why's that ? Two reasons. The first one is controlled. It's called deprecation. As they go along, folks at Apple figure out better ways to accomplish the same thing, or in some cases, the old ways of doing things stands in the way of progress, or conflicts with new planned functionality. In those cases they flag some functionality as deprecated, and provide some alternatives. You're given a period of time, usually unspecified, between several releases, to migrate to the new functionality. That means that for the time being the old functionality still coexists with the new one, but at some point in the future, solely at Apple's discretion, it will go away, and if you didn't migrate, you'll be left hanging.

The other reason is uncontrolled. It's because of bugs and defects that are the usual unintended consequences of changing software code. Every time Apple releases a new version of iOS, that new version has new functionality, fixes for known problems, and new, not yet known, problems. That's the nature of the business.

The biggest changes to the platform, and the most potential for bugs, are when the major version changes. The major version is indicated by the first number in the versioning scheme. For example in version 4.3.5, 4 denotes the major version. When iOS 5.*.* comes about, you'd better watch out.

I've been building iOS apps for a living for more than a year now. Based on that experience I can tell you that if your app has a fair amount of functionality, touching different areas of the platform, chances are high that it will break on the next major release. I had problems both when iOS 4 was released and when iOS 5 got released.

You may ask, how come, since iOS 5 hasn't been released at the time of this post. That leads to the solution. You see, Apple issues beta releases available for developers prior to the official releases. So all you need to do is have your developer proactively test the app on those betas, as they come along, and look for issues. This gives it the "hidden" nature of the cost. You can't know in advance how many problems you'll encounter. So you'll need to budget for that. On my latest project, which took about a year to develop, I had to spend a week to fix problems in iOS 5 beta.

How can one fix those problems ? In some instances they are problems in Apple's code. In those instances the developer must file a bug report with Apple, to let them know about the problem. The developer should next look for possible workarounds, because even if a bug report has been filed, there's no guarantee that Apple will fix it in time for the next release. You can gauge the likelihood of that to happen, by monitoring the incoming betas. The higher the number of the current beta, the closer it's to the GM (gold master) release, after which all bets are off.

In other instances, changes in the platform may rattle some dormant bugs already present in the app. Those bugs are the developer's responsibility. The good thing is that with that responsibility comes power and control too. That is, a competent developer should be able to fix them. That's opposed to the previous scenario, where you're entirely at Apple's mercy, to fix their mess, unless you have a developer that can come up with a workaround. If you work with a less gifted developer, your option is to find a second opinion, or, if the problem hasn't been fixed in time before the release that introduced the breakage, enlist the help from Apple DTS (Developer Technical Support). You get 2 free support incidents per year with your membership in their developer program, and you can purchase more at a low cost. I never had to use that myself, so I couldn't comment more on that.

So there you have it, a rundown of the issues that may crop up post-release. On all my projects I offer my clients a maintenance plan that charges a monthly fee to test the app on the latest beta and to handle any issues encountered. So they can have the piece of mind knowing that their initial investment is protected.

Obvious shortcomings of Apple's App Store

Having published more than 40 apps in the App Store, on behalf of my clients, I'm in a good position to comment on possible ways to improve it.

Perhaps the most glaring omission is the inability to quickly revert to a previous version of an app, once a newer update has been approved and went live. Sometimes mistakes occur, and those mistakes could easily go live.  Based on my experience, once an account has a fair number of apps published (like over 30), and an unblemished history, with few app rejections, it seems that Apple's review process gets noticeable lax (as a better word for sloppy). In one instance an app update was glaringly broken on retina display devices (i.e. iPhone 4), yet it was approved and went live.

In such instances your only recourse is to either pull the app from the store, and/or to prepare and issue a new update, but that has to go back to the waiting queue. This could have terrible business consequences, because there wouldn't be a working app available for about a week. You could try to speed it up, by requesting an expedite review. Although the onus is on the developer to test each update before publishing it, it'd be very helpful to be able to revert to a previous, functioning, version.

A related idea would be to have some sort of a staging area, whereby a new app, or an update of an existent app, could be made available through an obscure URL to a set of testers, after it has been reviewed, but before being made available to the public at large. This may be already supported through the option of manually releasing the app after the review completes, though the fact that there's a single URL that points to the app in the store, irrespective of its version, may suggest that the URL points to the latest live version. This staging area mechanism would be similar to the Ad-Hoc distribution, only more scalable.

Another thing missing is an API to access the App Store functionality programatically. Some apps lend themselves to a cookie cutting model, whereby the same template is used to produce multiple apps, perhaps being differentiated by the content they package and some branding. In such instances the ability to programatically interact with the store would be very useful.