You’ve designed a brilliant app and signed up for the Apple Developer Program, and now it’s time to publish it to the App Store. The app review process can be tedious because you have to comply with all of Apple’s rules in order for your app to be available in their store… and there’s a lot of rules. Eventually you’ll get the hang of it, but even seasoned developers sometimes get their app rejected by Apple. I’ve been publishing apps to the App Store for four years, so I wanted to share some tips I’ve found useful to help make this process as simple as possible for you.

1. Test your application

If your application requires an internet connection to work, does it open without crashing when there is no internet connection? Can it run without issues on an iPad if it was specifically built for an iPhone? Are 4-inch displays (iPhone SE) properly supported?

One of the first things you should focus on is ensuring you have a quality product. Having a quality app will save you a ton of development time, minimize app rejections due to crashes, and you’ll have happier users. Make sure your app is thoughtfully tested both programmatically (with unit tests and UI tests) and manually before submitting.

2. Automate the delivery process

You’re going to do a lot of repetitive tasks, so why not automate them using a continuous delivery tool?

Fastlane, a continuous delivery tool

Fastlane is used by thousands of mobile developers. It requires minimum configuration and is much simpler than configuring continuous integration servers because it runs locally in your machine. It uses a file called Fastfile where you can specify what steps you want it to do:

Just a bit of ruby

The Fastfile above describes a beta distribution process using the beta lane. The application is first compiled using gym, then uploaded to Crashlytics. You can create complex lanes to run your tests, build the project, and notify the team that a build is being processed, all with a line of code. Pretty cool, huh?

3. Beta test your application

There’s no better way to get feedback and catch some extra bugs than allowing people to do it for free. There are many options out there like Crashlytics, HockeyApp, etc. To use these services, you’ll either need to have an Apple Enterprise account or specify which users are going to be able to test your app outside the App Store. If you’re not using an enterprise account, you’ll need to add the Unique Device Identifiers (UDIDs) for users’ devices to your distribution certificate, which can be a tedious process.

Testflight

Testflight is another option to test your app (if you don’t mind longer review and build processing waits, that is) because you can have up to 2,000 beta testers with any kind of developer account.

When using Testflight there are two kinds of test groups: internal and external. Internal testers are usually part of the development crew, marketing team, or the group who owns the application because they will have some extra permissions for the app depending on their role. Any new build is available for them immediately after it’s finished processing in iTunes Connect.

In the case of the external testing group, your build will first be reviewed by Apple every time your app version changes.

The review process is much less strict than the one for the App Store and usually only takes 1–2 days.

4. Know what to expect in the review process

Before 2016, the review process was very, very slow. Waiting a week for an app to be reviewed was the norm. Some major companies with fast release cycles even accommodated their release schedule for this limitation:

“A lot of the way that we build software for iOS is controlled around the fact that you have a one-week release cycle,” said Maddern, whose team has done work for Uber Technologies Inc. and Foursquare Labs Inc.

Apple has done a good job making the process much faster. As a result, now it only takes an average of 1–2 days (based on my experience). I usually check App Review Times website to have an idea of how long I’ll have to wait.

5. Read the app store guidelines

If you haven’t read the App Store guidelines at least once, take a look at them. If your app idea doesn’t comply with those rules, it probably won’t make it to the App Store. Another interesting page is the App Store Review Guidelines History, where you can easily see the diff between the updated guidelines versus previous versions.👌

6. Look for the most common reasons for rejection

Definitely take a look at this and stay away from them. As of now, this list constitutes 67 percent of all rejections:

Most common reason for rejections

Here are some additional things to keep in mind based on what I’ve encountered personally:

Remove all placeholder content. Even if you specify you want to release the app manually and not when the review process is approved, you need to have real content.

If users are able to post content, have a reporting mechanism.

Disable unused application services both on identifiers in the developer profile and in Xcode under capabilities.

Don’t use Apple logos. For example, if you want to indicate an audio streaming action, don’t use the Airplay logo even if it might be more intuitive for users.

If your app has a login screen, be sure to leave a demo account under app review information on iTunes Connect.

If your app gets rejected, work with the Apple review team and carefully read the reasons behind it. You can always appeal a decision if you truthfully believe you were complaint with the guidelines, or if you feel like they made a mistake when rejecting your app. Just make sure to be respectful.

7. Set the app metadata

Besides the usual App Store optimization techniques (like using 100 characters under the keywords section), you should put the most important keywords in the application title.

Help your reviewers better review your application by leaving test credentials if your app has any kind of login screen.

Apps that use a single sign-on mechanism from social media apps are included in this requirement

Also, you can leave a note about anything the reviewers should know when they review your app. Trust me, they actually read it.

8. Know the review steps

Prepare for Submission: Set all the app metadata, like descriptions and screenshots.

Set all the app metadata, like descriptions and screenshots. Waiting for Review: App will be reviewed in the next 1–2 days. You can still make changes to the app metadata.

App will be reviewed in the next 1–2 days. You can still make changes to the app metadata. In Review: The changes to some of the app metadata (like screenshots) are frozen. You’ll need to reject the app to update the screenshot and wait another 1–2 days.

The changes to some of the app metadata (like screenshots) are frozen. You’ll need to reject the app to update the screenshot and wait another 1–2 days. Pending Developer Release: This only happens if you selected Manually release this version. The app was approved. You can now release it when you’d prefer.

This only happens if you selected Manually release this version. The app was approved. You can now release it when you’d prefer. Processing for App Store: Will be available soon.

Will be available soon. Ready for Sale: Live in the App Store.

Apple Review Steps

If you’re facing extenuating circumstances, you can request the review of your app to be expedited by completing a form. Expedited reviews are granted on a limited basis, so not every request will be approved. I’ve used this before and mine was granted so it just depends.

Bonus: Keep your app in the App Store

Congrats! Your app has been approved and the world has yet another app to choose from in the App Store. 🎉 But be careful, your app can be removed from the App Store for a number of reasons… So please don’t send push notifications promoting your new Android version of the app :]

I hope you found the tips useful! If you want to add any additional insights, or if you have an experience with Apple’s review process, I’d love to hear it!

Stay engaged with Propeller on LinkedIn, Twitter, Facebook, and Instagram.