With my 6 years of application development experience, I have accompanied hundreds of applications being published in app stores, and have been rejected many times (80% of which were by Apple). All of these processes have shortened my life by about 5 years :-) Since my life has been shortened, I wanted to share my experiences in a concentrated way so that others’ lives do not get shorter.
When it comes to publishing an app, it is not enough to just drag and drop the .ipa or .bundle and assume it will be published. Especially when publishing an app to the Apple store, a very meticulous review is carried out. Although these reviews are largely carried out using automation tools on the Google side, there are real people at Apple who are directly involved with your application. So when you submit your application for review, Apple assigns a team to your application and those people use your application for hours and hours. So you should know that you will face a very serious review on the Apple side.
The publication of the application is an important milestone for many companies. Not being prepared for the application publication process can cause serious financial and time losses. Even an application that you have worked on for months may never be published in stores due to principles. In this article, I will explain the most common reasons for rejection, which are very simple to solve.
Social authentication methods
If you are using an Authentication logic in your application, you are most likely using Social Authentication methods in addition to email and password login. Social Authentication methods are very important for the user experience because they help users authenticate quickly in your application. But why should we reject the application because of this? Understanding Apple is where we start here.
You may think that the majority of users use Gmail or that logging in with Google alone is sufficient, or you may have implemented login only with Google for technical reasons. But Apple doesn’t care :-) If there are other social logins (Google, Twitter, Facebook, etc.) in your application, Apple also requires the function to log in with Apple. However, you will not be rejected if you use only log in with email. This is only valid if other social logins are implemented.
We will encounter this perspective in many places. Our special child, Apple, says, “Since you are going to use my store, you must use me too.” There are some places where this is justified, but it’s a little irritating that this is an obstacle to getting published.
Insufficient permission explanations
When developing a mobile application, developers often ask for permissions from users to access device features such as Camera Access, Microphone Access, and File Access. When asking for these permissions, it is expected that you write content for the user to understand why you need this permission. These contents can be simple sentences like “We need access to your camera.” Although these contents are not very important during the development phase, they are important for the user experience.
But for Apple, who doesn’t compromise on user experience, this can be a reason for rejection. Apple explicitly requires you to state the reason and purpose for requesting access to device features in your permission requests. Therefore, don’t forget to double-check your permission messages in your .plist file.
Application screenshot discrepancies
If you think you’re only rejected for technical reasons, you’re wrong. The information you enter for your app to appear in the app store on Apple’s side can also cause rejection. For example, the first thing users see when they click to download your app is the “Application Screenshots” section, which contains the in-app images you uploaded. The content of these images is crucial to Apple. They argue that users should see what they will encounter before downloading the application in this section. From a user experience perspective, they want you to show which functions and contents to concentrate on before downloading. Therefore, you need to prepare these screenshots very carefully.
The most common reason for rejection in this section is Appbar. If you have taken in-app screenshots from an Android-based device and there is a non-iOS-based Appbar on top of this screenshot, it is highly likely that you will be rejected by Apple. As I mentioned at the beginning of the article, this is evidence that real people scrutinize pixel by pixel. Even a tiny Appbar image on a 1000-pixel image is enough for you to be rejected. Additionally, the screenshot you put for iPads should not be stretched, but should be a screenshot of what is actually displayed on a real iPad.
I would like to point out that the list of reasons for rejection by Apple is endless. I want to emphasize that every rejection response you receive will waste 3–10 business days. Therefore, it is necessary to read Apple and Google’s Review Guidelines in detail as much as possible. However, even though Apple’s Review Guidelines are as long as possible, your rejection reasons are not explicitly stated. You can also be rejected due to any reason arising from the interpretation of a clause. I want to emphasize that even a single sentence in Apple’s guidelines can be divided into hundreds of pieces, and one of those pieces can cause you to be rejected. Therefore, you need to not only read but also interpret. Finally, to take advantage of my service, where I conduct a detailed and professional review of your app for four days during the initial publication of your app in the stores and make it suitable for the stores, you can contact me by email.
