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.

Adaptive volume level for audio on mobile communication devices

Mobile devices are meant to be used in various environments, as such I find it pretty surprising that the designers of user experience for these devices fail to address one obvious fact: the ambient noise can vary dramatically from one environment to the other. To be fair, each device has a volume control, meant to adjust the level of the audio volume above that of the background noise, however in some cases unexpected bursts of noise may occur in an otherwise quieter environment. It'd be great if the volume would adjust automatically to make up for the increased noise, and later subside when the noise is gone.

The alternative to automatic adjustment is to do it manually, which is the current state of the art. While that's merely a nuisance for regular audio output, like when listening to a podcast, or while in a phone call, it could have more severe effects when applied to the volume of the ring tone. I missed many calls on my mobile phone while I was out on the street, with heavy traffic around me. Even though I have my phone set to both ring and vibrate at the same time, I would still miss calls.

In thinking about solutions to this problem, the obvious approach is to use the microphone, if available on the device, to listen to the environment and react appropriately on increased noise. The drawback of doing such a continuous listening is that it may consume CPU and battery power, and that's probably why it hasn't been considered. Perhaps a better approach would be to let the user decide when that's worth doing. After all, this listening should only happen when audio is playing, so it may not be such a drag on battery.

One could apply further optimizations, by employing location information correlated with past data collected on the same location as a hint for quieter places, or data from the motion sensors as a hint that the user is on the move, hence more prone to the vagaries of the environment.

I remember how my first mobile device, a NEC pager, solved this beautifully. Upon receiving a message, it would first start blinking an LED. If the message was ignored it would start beeping ever so slightly, than it would gradually increase the volume to the point where it was so loud that it was almost painful to hear.

In any case, this should be handled at the level of the platform, since it's a concern that cuts across several apps that produce audio output. I'm looking forward for the first platform that will handle this effectively. My previous experience on Symbian/S60 and my current experience on iOS uncovered this as still lacking. What do you think, have you missed this capability too ?