My (First App) Journey to the Apple Store
A tale of three months of Apple Review Rejections
Last year I finally made the jump: I bought a Macbook and started learning Swift and iOS App Development.
About 3 months later I submitted my first app to the App Store: I couldn’t be so proud!
Disclaimer: I’m a Software Engineer, your mileage might vary.
Swift is an amazing language and, after dealing with the fact that I can’t know everything there is in Cocoa Touch, there was nobody to stop me building and launching my app.
Boy, was I wrong.
The App
Quick description of the App I’ve submitted:
it’s the standard Twitter App with real-time functionalities: just input any keyword you're interested in and let the Tweets flow on your screen as they’re posted! (here’s a 50-seconds video of the app in action).
First Rejection
See the little email above? This is the very kind way Apple uses to let you know that no, your app is not going to the App Store just yet.
My app was pretty simple: I was quite surprised when I woke up with a rejection in my mailbox.
It turns out, the App Review Team didn’t even have to launch the app in order to reject it: naively, in the app description, among other keyword comparison examples, I put “iOS vs. Android”:
3.1 Apps or metadata that mentions the name of any other mobile platform will be rejected
The App Store Review 3.1 Guideline is as clear as it gets: this rejection is completely my fault. Luckily there’s no need to change the App binary, let’s change the description and re-submit the app!
Second Rejection
The App Review message
This time the App Review Team summoned the App Store Review 14.3 Guideline (under the Personal attacks chapter):
14.3 Apps that display user generated content must include a method for filtering objectionable material, a mechanism for users to flag offensive content, and the ability to block abusive users from the service
My app doesn’t let the user generate any content: it just shows you Twitter’s content (where you can report/flag/block anything/anyone you want).
Even if I were to implement what I was asked to, the App uses only real time data, it would be of no use to the app itself.
If a user were to flag a Tweet, that Tweet would be old already: it would never be displayed on the App again, ever!
I felt that the Guideline 14.3 didn’t applied to my case so I wrote an appeal with the reasons above:
The App Review Board replied to my appeal within a few hours.
The Appeal response
Lesson learned: if your app shows user generated content, implement a flag/moderator/block mechanism, even if the content is not created within your app.
Luckily for me, Twitter API offers everything I need:
My two additions to comply with App Store Review 14.3 Guideline
Time for another submission!
Third Rejection
At least now I’m used to it
While waiting for each review, I kept adding more and more features to the app, at some point I even added some non-consumable in-App Purchases.
That’s too bad, because these in-App Purchases were the reason of the new rejection.
All my in-App Purchases are non-consumable: once the user buys one, this purchase can be “bought” (again) as many times as the user wants, for free.
I like to have as little UI elements as possible: since these in-App Purchases can be “re-bought” for free, I didn’t implement a Restore button.
The App Review message
After explaining my logic above, the App Review replied:
If you reply kindly to the App Review message, they will reply kindly as well!
Lesson learned: Restore button it is!
This time, probably out of pity, the reviewer suggested me to request an expedited review (via the Expedited Review Request form) after I submitted the new binary with the restore button.
@IBACTION func restoreTap(sender: UIButton) {
SKPaymentQueue.defaultQueue().restoreCompleteTransactions()
}
Implementing the restore button was the quickest change that I’ve ever made: I just had to drag a button to the storyboard and write 3 lines of code, connecting the UIButton
to the associated UIViewController
class.
Why did I even try?
Seems like the Expedited Review Team didn’t have the same compassion of the previous reviewer. I have to wait for another round of App Reviews.
Fourth Rejection
I actually saw this submission going into review before falling asleep and I had a good feeling that I would wake up with an accepted app, HA, I better keep dreaming:
This is how the only kind of mail that I expect from Apple.
This time the Reviewer thought he/she needed some special Twitter authorization in order to use the app:
After explaining that any Twitter account will do, the app went under review again and…..it was accepted!
Do you mean…I finally made it?
Too bad I had a change of heart on the App name. There’s only one way to change the name now:
I really missed having my app rejected
Changed the app name, let’s make a new submission!
Fifth Rejection
Were you expecting anything else?
The reviewer (I assume, newly employed) was using an iPad and was claiming that he couldn’t get past the Twitter authorization screen: that’s the screen that shows up when you launch the App for the first time.
The problem was not very clear because of the reviewer’s inaccurately cropped screenshots and ambiguous messages.
After a few messages exchanged, I recorded myself using the App in an iPad: the app went under review again and then it was accepted!
Lesson Learned: Don’t assume that everybody in the App Review Team knows what they’re doing.
Conclusions
After building the app in just 3 months, I had to enjoy 3 more months of App Rejections before finally releasing it to the Apple Store.
During these months I learned quite a lot: I hope to have given you a sneak peek of both my frustration and passion that has kept me company during this journey.
If you made it this far, I would like to leave you with a few suggestions for your next submission (after all, I’m an expert now /sarcasm):
- Read the App Store Review Guidelines every once in a while: it’s much shorter that what I expected and it will save you a few rejections
- When submitting a new build, use the App Review Information fields to guide the reviewers and letting them know what has been changed/fixed/updated from the previous build
- In case you’re submitting a new build after a rejection, use the Notes field also to point out what you did to overcome the last rejection
- Be polite: when reviewers reject your app, thank them and gently ask for more information (if needed) or let them know that you’re going to fix the issue(s) with a new submission
- I’ve always worked with very polite and kind reviewers that were more than happy to help me with any issue I had
- Be patient: releasing an app can be a burden, Apple has very high standards and this is why its Store is not polluted like the competition
Good luck with your next submission!