Ok, you’ve spent months developing, testing and “polishing” your app and there is one final step left to introduce it to potential users. But no matter how awesome your software might seem, submitting it to the Store can turn out to be quite complicated. Let us share some of the rejection reasons you might encounter and ways to avoid them.
First things first, App Store and Google Play platforms – the two giants in the area of apps distribution – each have their own submission process. To get your app live and running in both, you’ll need a deep understanding of the specific guidelines and submission requirements for each of the Stores. Be ready for the approval and publishing process to take time and be tricky. Even a small thing can lead to an app rejection.
The App Review department for the iOS platform deals with over 100,000 submissions every week and rejects about 40% of them. The app approval process engages a review team of developers who look through every aspect of an app manually to check if there are any errors. That is why the approval takes longer than for Android. If the Review team finds any issue violating Apple’s rules or guidelines, they provide the developers with feedback indicating the guidelines they consider to have been broken. After that, the development team needs to resolve the issue before re-submitting the app.
The Android approval process is less strict and time-consuming as it involves a team of experts as well as automated tools. The review algorithms scan the app to check if it violates any Google policies. After that, an internal team of reviewers examine the software. In general, the average review time is a couple of hours.
With 10+ years of experience in software development and hundreds of apps submitted to the stores, Ekreative professionals know the do’s and don’ts of app reviews. Let us share a few things to verify when submitting your app that might help to avoid rejections and possible struggles.
1.Include Apple login option among others
According to Apple’s guidelines, apps that use any social or third-party login services (e.g. Google, Facebook, Twitter, etc.) for user authentication must also offer a ‘Sign in with Apple ID’ option. Apple recently introduced this guideline for iOS 13. The tech giant argues that there is real value to offering users a sign-in option which does not require them to pass on their personal details to a third-party company. This rule is not required if the app uses its own internal setup and login systems instead of social login.
This is a case that we encounter often. A lot of our iOS projects at Ekreative have a Facebook sign-in option, and after the release of iOS13, these apps would have been rejected if we hadn’t also added a “Sign in with Apple” button. Once our developers made the appropriate changes and implemented Apple ID authentication, the software was successfully released.
2. If you launch a coronavirus app, make sure it is published by a source acceptable to Apple
As a response to the spread of misinformation about Covid-19, Apple is now rejecting coronavirus apps that are not from government or recognized health institutions. The company applies this ban even for software created with good intentions – like apps demonstrating statistics of recent confirmed cases or affected countries, by taking data from official sources. Developers who experienced coronavirus app rejections said that Apple reviewers cited guideline 5.2.1 stating “apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights”.
3. Make sure the screenshots don’t contain any unapproved content
Before submitting your app for App Store review, make sure you have a deep understanding of Apple guidelines and requirements. Even a small catch can result in app rejection.
We’ve encountered this type of rejection several times, for quite different screenshot elements. On one occasion for including the logo of other apps in a screenshot, on another occasion, our parental control app was rejected for including a link to a real site in a screenshot showing our content blocking feature. On both occasions, the screenshots were genuine reflections of what our apps might look like when a user is interacting with them, but the inclusion of app logos or website addresses which are not associated with the app in question was considered unacceptable. To successfully pass the app store review, we changed those elements to fictional equivalents, not associated with any real company.
Apple pays attention to what is in the screenshots, down to the level of small on-screen text. Apple might reject your app if they consider any detail of those screenshots to be objectionable content like gender and religious discrimination, violence, sexual or pornographic material.
4. Your Store subtitle is consistent with app functionality
A subtitle is a vital ASO tool, but don’t go too far in the wrong direction. Apple intends the subtitle to be a short phrase which gives a potential user further information about what an app is for. It should clearly state the purpose and value of the product. It turned out to be a sticking point on one of our projects.
Our team was about to release a new location tracking app. The initial subtitle was “GPS Tracker for Kids”. We chose this title in large part for the ASO value it would bring to our storefront. Yet Apple decided that the phrase was misleading, and doesn’t reflect that the software is aimed for family use, so they didn’t let us into the Store. Once we changed the sub-title to “Find location of your family” we were successfully accepted.
5. Verify you don’t mention other platforms
One more aspect that developers and designers should take into account is the app icon. Apple provides general recommendations to keep it simple and recognizable. But sometimes other rules also affect what’s allowed and you need to make sure your design has taken the entirety of the guidelines into consideration,
A while back now, one of our apps faced App Store rejection because of an issue with the icon. The icon showed a drawing of a phone, but it wasn’t an iPhone. At that time all iPhones had a button below the screen, but the button was missing on the icon. Implicitly, the icon showed an Android phone and Apple’s review team wouldn’t let it into the Store because of this. The software was successfully released only after the app icon was edited so that an iPhone was unambiguously depicted. It is a vivid example of how picky Apple can be about Store approvals. They take every detail very seriously.
6. Check that the app doesn’t ‘request permissions’, it does not use
Sometimes the rejection reason is not on the surface and requires thorough investigation. The app could even be dismissed because of unused permissions in a library it uses! One of our client’s apps was removed from the Store because of a violation of paragraph 4.8 in the “Google Play Developer Distribution Agreement” connected to privacy policy. As Google didn’t provide us with any clarification, our developers ran a thorough investigation. As a result, they decided to modify the screen with the privacy policy to make it explicitly clear that the app wouldn’t send user data to third parties. After several further submission attempts, Google still rejected the app. Finally, the team concluded that the real rejection reason lay in some permissions which were requested inside the library of an integrated service, even though they were not used by the app itself. So the problem was solved by removing those permissions from the final manifest.
This case also raised a small practical lesson for us. Remember that emails about policy changes are sent to the owner of the Google Console account (usually the client, not the developer emails) so the developer team can be unaware of the details which Google has sent.
Understanding app submission
As you can see, sometimes rejection reasons are fairly obvious, if easily overlooked, other times it can be a real challenge to work out what the problem actually is, as the app stores point you only to the guideline they think you’re breaking, not the specific part of your app which is non-compliant.
Over the course of many years developing and submitting mobile apps, we’ve gained the experience and knowledge of the app store guidelines and submission procedures needed to avoid the simpler rejections and effectively analyse and remedy more unusual cases. In one extreme case, we even took Apple to the European Commission to resolve the problem! Of course, nothing is guaranteed when playing inside the walled gardens of the tech giants, but if you want to give your app the best possible chance of getting accepted, partnering with Ekreative for app development and submission is the way to go.