Tips for a successful AppStore submission?

Question

In a day or two I'll be ready to submit my iPhone app to the AppStore and I'm curious whether people who have gone through this process have any tips / suggestions for a smooth submission process.

Here's things I've covered;

• No memory leaks
• Tested performance on an actual device
• Doesn't crash :)
• Using correct certificates / profile

What I'm a little unsure about are how to configure the "Bundle Display Name" /"Bundle Identifier" and "Bundle Name" in info.plist. I understand the first is the text that's shown on the iPhone itself, but what about the last? Does this have to match Bundle Identifier?

Are there any other things I should add to the info.plist? I've noticed that when built for Adhoc distribution my app does not have any author/title information in iTunes.

Answer 1

Display name and name should be similar/identical unless you know that they don't need to be (for example twitteriffic and twitteriffic premium both display as 'twitteriffic' on the iphone but they're different apps with different names)

Bundle identifier is the apple equivalent of a registry path in some ways, windows developers would use HKLM\Software\Company\Application - apple uses a convention more like com.companyname.appname

(Disclaimer: no knowledge of appstore development, just a small amount of knowledge on Macs and plist files)

Answer 2

First, don't worry about the missing author/title information (and icon) in iTunes. That's meta data that arrives when you distribute using the App Store.

Your bundle identifier, as sascha says, should be unique and is usually your domain backwards. This needs to match the App Id you created in the Developer Portal.

The Display Name (CFBundleDisplayName) is how it appears on the home screen. One important thing I found about this is that it can be localised, so if your app was called "Beer" in English, it could display as "Birra" in Italian and "Bier" in German.

The mechanical stuff, as long as you follow the instructions, is actually fairly straight forward. I found the key is being prepared. You basically get no notice before your App goes live, and the review process can take any where from a few hours to a few weeks. Make sure you have a website up and running and the ability to accept (and provide) feedback. I just used Blogger.

Unless your app is trivial the real world will find problems that you didn't anticipate and your unhappy users will always be the most vocal, so you need the ability to reply!

My app is Yummy, by the way.

Answer 3

Make sure you have a flame proof suit to deal with all the retarded reviewers that give bad marks without trying the app or reading the description of what it's supposed to.

I got marked down for not doing things that my description says it doesn't do.

The review process, and inability to really respond, is maddening.

Answer 4

When submitting an app, make sure you set the version number properly in the info.plist file -- When updating an app, you must increase the version number. You can use x.x notation, or x.x.x notation. (I forgot to update it on my first app update). Not that it's hard to update and recompile, but it is one of those thing to easily forget.

I agree with Hunter as well. You WILL get bad reviews. It's ok. They're morons. Your app is great.

If you ever have problems with certificates, there are a few things I've found helpful:

1. Restart XCode.
2. In your iPhone/iPod, Go into Settings>General>Profiles Make sure the distribution profile you use is in there, and there are no other conflicting profiles (I had two distribution profiles for the same app). You can remove them right in the iPhone/iPod.

At some point you will see the "Application failed codesign verification" error. it will make you insane. Take a deep breath. Restart XCode, restart your development hardware. Go hit a wall, go have a drink, and it will all work again.

Then, you'll want to:

1. Clean the Build Target (or all targets if you're mad at all of them)
2. Set the Code Signing Identity (in the Target properties) to "Don't Code Sign"
3. Close Xcode
4. Remove all directories in build folder
5. Open Xcode
6. Reset the Code Signing Identity to your iPhone Distribution: certificate
7. Sacrifice a small animal.
8. Build.
9. Submit Application to iTunes Connect
10. Profit!

Answer 5

If you get rejected your submission date will stay the same as when you first submitted resulting in a lower ranking when you app eventually becomes available. If you do get rejected ask apple to remove the first submission and instead of replacing the binary on the rejected app, submit it as a new application with a newer version number 1.1 etc.

Some people suggest keeping your app free for a week or so during a promotional phase, then raising the price later. I have tried both ways and so far it appears to be 6 one way and 1/2 a dozen the other. For every 1000 free downloads you are getting expect about 10 at $0.99 (again this is my experience)

One minor thing I ran into. Make sure you Small Embedded icon 57x57 matches the Large 512x512 icon. If it is "too" different in their opinion they will reject the app. So avoid trying to showing even a little more detail in the larger icon.

Answer 6

Follow the UI guidelines, if you're using any Apple widgets. For example, reusing Apple's icon sets in contexts that change their meaning (such as reusing the camera icon, which is for bringing up the Pictures album, for, say, screenshots) can be grounds for rejection.

Answer 7

My advice is to create a wildcard distribution profile. This way you can leave the Bundle Identifier alone, the default value works.

Leave the "Bundle Name" setting its default value. You can change the displayed name by renaming the product (go to the project info screen, select all configurations and search for "product".) You can overwrite this with the Bundle Display Name setting, but it's unnecessary if your product name is correct.

You should have a high res (512x512) version of your logo or promo image ready when you submit your app.

If your app gets rejected, apple tells you what to fix. They are pretty reasonable, so don't worry about that.

Answer 8

Submitting information from the device to Internet is also a potential pitfall. The SDK Agreement says:

Any form of user or device data collection, or image, picture or voice capture or recording performed by the Application (collectively “Recordings”), and any form of user data, content or information uploading, syncing, or transmission performed by the Application (collectively “Transmissions”) must comply with all applicable privacy laws and regulations as well as any Apple program requirements related to such aspects, including but not limited to any notice or consent requirements. In particular, a reasonably conspicuous visual indicator must be displayed to the user as part of the Application to indicate that a Recording is taking place.

If you do something like submit the highscores from a game, make sure you give the user a chance to skip the transmission. Otherwise you may get rejected, happened to us.

By the way: There is no guarantee that if your first version gets through, all the updates will. Our 1.1 got rejected for a feature that was already in 1.0. This is very annoying, since the update might be fixing a bug and if it takes a week to get rejected, you’re already a week late when you have to start fixing something you thought was not broken.

Answer 9

I find they don't really check for memory leaks and stability issues, more usability issues. For instance, my app uses Core Location to find bus stops in Perth. When they tested it in California, they found none nearby (what a surprise!). They pinged me over not displaying an out of area message.

Another thing they pinged on was over the bus stop numbers. In Perth, they are 5 digit numbers. The Apple testers were entering 2 digit numbers, and inadvertently bringing up train stations, for which I use a slightly different code path, and the described functionality in my description wouldn't have worked.

It was actually very handy feedback, and it was good to have someone I didn't know give it the once over. I was quite surprised at how thorough they were at testing. I thought it would just be some sort of automated static verification tool to make sure you weren't trying to breach the iPhone security.

Answer 10

Don't use images in the tab bar items that resemble an iphone/ipod touch. They use to allow them, but now they are rejecting them. It seems that other apple hardware is not an issue.

Answer 11

Once your app is approved, you should change the Availability Date to today's date. This ensures that it will show up at the top of category list, which is sorted by date. We do this for our app, iStylist Makeover.

Answer 12

If you create a lite version of your application be careful not to lock out features that might make it be considered non fully functional. You are also not supposed to up-sell to the full version (although it seems that many apps do this anyway).

Answer 13

watch out for the keywords. don't use other apps as keywords. (my music app was rejected after 3 weeks becase i used 'last.fm' as a keyword.)

Answer 14

This article is by far the most comprehensive answer to this excellent question:

http://iPhoneIncubator.com/blog/app-store/rejections

The post has links to other resources on the topic as well.

Good Luck, Matthew

Information in article includes :

Bugs
HIG Lite Versions Internet
Connectivity (excellent information
you might be surprised to read)
Excessive Bandwidth Usage Over
Cellular Networks Device Capabilities (Another great point here that saved me)

Private API:s Limited Functionality No Interpreted Code Handling of UserData Copyrighted Content Use of Trademarked Images Objectionable Content UIWebViews Transactions Outside The App Store
Price Information App Icon and App
Store Image Application Description
App Store Keywords Updates Are
Reviewed As New Apps

---

Answer 15

When you submit there is a box for you to enter any demo account details that might be needed by your application.

This box is also a good place to put any extra details that the reviewers may find helpful when checking your application.

Answer 16

My tip: don't fret if your app gets rejected - sometimes Apple rejects apps for weird reasons.

Answer 17

I created snatchboard and it went through perfectly, however I tried to do an update an it got stuck in "upload recieved" it seems quite a few have had the same issue.

Answer 18

Read the current page of rejections / acceptances at AppRejections.com, and check you're not about to fall foul of some recent change in Apple's "secret" approval reasons.

Answer 19

Got "Invalid binary" on several tries. What finally worked was zipping the bundle directly on the Mac and uploading on a Mac. Of course, leave out the .dSYM file. On previous tries, zipping was done on a PC. Rezipping to leave out the .dSYM was also done on a PC on the failed attempts.

Answer 20

Didnt Apple change the sort-date method for newly submitted apps?

We no longer need to play the "set your date in the future, then to today" game.

"New apps" are sorted by "approval date" now

Answer 21

If it's an iPad app, don't mention iPad in either the app name when you submit it or the display name in your Info.plist.

This was a bit of a bugbear for me because I have "one" app (two binaries) that has a different interface for iPhone and iPad - I couldn't call the iPad version "Symmetry Lab" because that's what the iPhone app is called, couldn't call it "Symmetry Lab iPad" because you can't say iPad in the name, and didn't want to call it "Symmetry Lab HD" because it has more differences than resolution. I ended up settling for "Symmetry Lab Pro."

Answer 22

Apple have now (as of 9th September 2010) published their official list of app store review guidelines, so it's worthwhile checking you'd not breaching any of them:

http://developer.apple.com/appstore/resources/approval/guidelines.html

(apple developer login required)

or a mirror here:

http://stadium.weblogsinc.com/engadget/files/app-store-guidelines.pdf