5 Essentials to Take Care of When Publishing an iOS App to the App Store in 2021
Small details in the submission package can be the difference between approval and rejection
Apple is famous for its tedious process of reviewing new app submissions. The company’s App Store is one of the few places where every app is still reviewed manually. Developers rarely get everything right on the first try, despite the fact that there is a lot of documentation on the Apple website on what to take care of when submitting an app.
Some requirements are clear, and it is likely you already did, or tried, everything in your power to ensure they are met. For instance, the list of most common rejection reasons includes crashes and bugs, broken links, inaccurate description, or substandard user interface. Solving these issues is fundamental for any digital product.
However, there are several tricky requirements that are hard to come across in the guidelines, which also tend to change from time to time. Getting these details right will dramatically improve your chances to be approved by Apple in 2021, substantiated by my recent submission of the Wellwork app.
Lately, privacy has been one of the focus areas for Apple when presenting new products and services. This is why this subject gets a lot of attention from reviewers when you submit an app to the App Store.
- In the app itself (for instance, in Settings)
- In the app description in the submission form
- In the app itself
- In the app description in the submission form
Disclose data usage in App Store Connect
The new privacy “nutrition labels” were first introduced at WWDC last summer, and they are now live in the App Store. Apple states that the goal here is to better inform consumers of the privacy practices of individual applications. The App Privacy labels are divided into three sections: “data used to track you,” “data linked to you,” and “data not linked to you.”
To put correct labels on your App Store page, you need to identify all the data that you or third-party SDKs collect on the user and if they are linked to the user or not. Then, you should use the Product Page Preview section under App Privacy page in App Store Connect to disclose your practices.
For more details, read the page on Apple Developer website.
Refine your app login process
Apple can be rather strict in their guidelines regarding the correct implementation of a login process.
One of the most important rules is that a registration and login should not be used without a valid reason. For instance, you can require registration only if some parts of content are associated specifically to the user for the account-specific functionality. This could be some statistics, achievements, or other data that you want to synchronize across devices.
This requirement also means that you should not hide a purchase screen behind the wall of a login screen, and you should only identify the user if she signs in later. Here is the feedback that Apple sent me for one of the versions of the app:
“Apps cannot require user registration prior to allowing access to app content and features that are not associated specifically to the user.
Please make it clear to the user that registering will enable them to access the content from any of their iOS devices and provide them a way to register at any time, if they wish to later extend access to additional iOS devices.”
Clearly disclose your in-app purchases’ names and prices in the description and in the app
If you have in-app purchases or subscription options in the app, you should disclose these in the app description in App Store Connect.
For instance, below the text that describes the functionality of your app, you should clearly state which in-app purchases you offer, provide their names, length (in case of subscription), and disclose pricing. It is usually enough to include prices for at least one store provided that you give a clear explanation. Below is the example of text that is used in my recent submission:
“These prices are for United States customers. Pricing in other countries may vary and actual charges may be converted to your local currency depending on the country of residence.”
You should also be very clear in the app itself about all the details related to the purchase — what a user will get, for how long, and if the purchase is recurring, like in the case of renewing subscriptions.
Move your CloudKit database to production
If you use CloudKit or Core Data with iCloud synchronization, you should not forget to move the databases into Production mode before publishing the app.
For private Core Data synchronization, it is enought to go to your CloudKit dashboard and deploy the schema to production. After that, your users’ data will be stored in their own private container in CloudKit with production settings. This data is not accessible by developer.
If you use a public database on CloudKit (for instance, to store login credentials), you need to add a piece of code to your release entitlements file in addition to schema deployment:
After doing this, you’ll start to see users’ records in you CloudKit dashboard under the Data section, where database is Public and environment is Production.
Submitting an app to the App Store is a huge step that might require a lot of determination from the developer. I hope this article will make your process smoother, and we see more great apps available for iOS devices.