TL,DR “The first and most important thing to realise about app store submission is that you are dealing with a human at the other end of iTunes Connect.”
We built an iOS app for a client of ours last year. They happen to be one of the largest e-commerce merchants and distributors in the UK trading in the ‘adult’ sector. Their brand personality is light-hearted, and they like to have a bit of fun with new ways to promote their own twist on sexual happiness.
Although this is a niche market, most of what we learnt is applicable to the wider app store submissions process, especially in the way that development companies and their clients need to build a relationship with the iTunes connect team.
The app was adult oriented, but what does this mean in the world of Apple? Apple are ubiquitous and pride themselves on quality, inclusivity and brand perception. Catering for all ages, and backgrounds means they are rigorous in what is deemed to be acceptable to be associated with their brand. When a user experiences the App Store and content downloaded on behalf of Apple, it reflects directly on the brand.
Apple have a series of checks and ratings that prevent inappropriate content being made available on their platforms. They own the landscape and it is in their interest to utilise it in the way they see fit. No apps will be allowed into the app store which display objectionable content or encourage unacceptable behaviour (more on this later…).
In its simplest form there are two very basic levels of app checking on submission:
- Automated checks
- User Testing
Validations
As part of the initial submissions process there are a set of weighted criteria that must be met before the submission can continue. There are set measures for content based on age ranges i.e. no mature themes for children through some mature themes for older users (up to 17+).
Even if the most mature rating is selected (17+) and the app has both strong sexual themes and strong violence it will be automatically rejected. However, if the app has strong sexual themes, but no violence it is more likely to be accepted (depending of course on the other criteria).
There are also other automated checks which happen during the submissions process from a development point of view, such as certificate validation, app capabilities and presence of icons which may cause an app to fail pre-submission checks.
User Testing
The actual submission process once through the initial validations and automated checks is conducted by a member of the App Review team who will test the app as a typical user. It is entirely down to their testing process, and understanding of the acceptance criteria that will result in either a successful or unsuccessful application. If the application is unsuccessful an explanation, typically with supporting screengrabs and a reference to the submission guidelines will be be supplied.
Releasing the app
Beta testing
Apple categorically will not allow an unfinished app into the App Store. All content must represent a finished, releasable application. An app will be rejected if there are any apparent bugs or incomplete features. For developers and clients, we need a way of presenting an application for internal quality assurance testing (QA) and user acceptance testing (UAT) prior to release. There are currently two general options:
- Using a 3rd party service
- Apple Testflight (Internal and External Testing)
3rd Party Services
We typically use services such as Hockey App when alpha testing across iOS and Android builds. This allows developers to upload early builds of the application which can be accessed by remote teams or clients to view work in progress. As 3rd Party Services are not bound to iTunes Connect, Android versions can be be shipped through the same channels
This approach requires the UUID of every device used in testing to be registered with the app before downloading.
Pushing new releases to the app also requires the current application to be manually removed from every device to be sure of a clean install, unlike the update process through Testflight and iTunes Connect which is fully automated. This can be tricky with less technical clients and users, but provides an effective way of pre-release testing.
Apple Testflight
Testflight used to be a 3rd party service, which was acquired by Apple to bring Beta testing into the App Store framework. There is a great history and tutorial on Testflight and App Store submisson here.
Testflight works on the concept on internal testing and external testing. For development teams to test their apps internally (QA), builds can be uploaded to testflight, and installed on registered devices by members of the development team (similar to 3rd Party Services such as Hockey App). Up to 25 internal testers are allowed, per app.
External testing differs from other 3rd party services, in that it requires a fully release-ready version of the app to be submitted to the App Store, before external testing (UAT) can begin. Even if you are not ready to release the app to the wild, and are using the service for closed Beta testing with external testers, it must be fully functional to be accepted. Up to 1,000 external testers are allowed, per app, per year..
The benefit of this approach is that once approved you can use the versioning and distribution capabilities of iTunes Connect for app updates, even without a public release (and no need for manual updates and individual device UUIDs as in 3rd party apps). It also has the key benefit that any grounds for rejection will be highlighted early on in the development cycle (never underestimate the importance of this!).
The difficulty lies in the fact the app is more likely to be declined due to bugs or unfinished features at this early stage, and the overheads of the initial submissions process. You can read in detail in this great post about Testflight setup from Dani Arnaout.
Submitting your app
Apple has comprehensive documentation around the requirements, which must be read and understood fully before submission. The key pages you must read before submission are:
- App Store Review Guidelines. (Read them carefully!)
- Marketing Guidelines. (Use them!)
App Store Review Guidelines
The guideline documents are mercifully short in the grand scheme of things. This is amazing, but also highlights the inherent ambiguity around the criteria. No specifics are given in what will or won’t be deemed acceptable until the actual submission process itself. The guidelines serve as exactly that, a guide – nothing more, nothing less. The specifics are left up to the developer and client to pitch their app at the right level in the hope the content is acceptable to Apple.
Marketing Guidelines
As brand perception is of paramount importance to Apple, there is a defined set of requirements for promotion of the app on the App Store. Assets are provided for logos and branding which need to be incorporated into all marketing materials.
One key point to note is that good quality screencapped images that are representative of the app are required for all relevant devices and form factors. Bear this in mind during development so these are available on submission to save time. There are few mandatory fields such as a working support email address for the app which should be taken into consideration.
Embracing Rejection (and why every cloud has a silver lining)
Our app was rejected. Sad face. This was no big surprise based on the subject matter and content of the app. We knew this was a risk from the start, now began the process of shaping the app for acceptance.
Rejection should not be a shock. We all want to succeed first time, but this is simply part of the process. The app store has a great list of common rejections which is an invaluable resource to help submissions.
The first step is to understand why the app was rejected and look to fix or change any obvious issues. There are two key reasons apps are declined:
- Non-compliance with App Store Guidelines
- Bugs
Non-compliance with App Store Guidelines
The first and most important factor to realise about App Store submission is that you are dealing with a human at the other end of iTunes Connect. That person could be any gender, race or religion. That person could also be simply having a bad day. Apple are consummate professionals in their approach, but the nature of the brand guidelines can lean more towards the subjectivity rather than the objectivity in some cases.
On a side note: With a recent app we experienced a slightly different issue where 2 iterations were accepted, and released to the wild. On the 3rd submission adding a new feature, the app was rejected on the grounds of a pre-existing feature, already available in the first iterations. We ended up having to change one of the core flows in the app to satisfy the reviewer and continue with the application lifecycle.
Bugs
Any obvious bugs will cause an app to be rejected. Something as simple as a misconfigured setting, or plugin with a 3rd party service which prevents some functionality being used, can cause an app to be rejected. This becomes more relevant in multiple rejection scenarios where other developers may be brought on to the project without deeper prior project knowledge.
The Appeals Process
TL,DR “Be nice!”
Every rejection can be appealed through the iTunes Connect appeals process. We appealed the decision on the grounds that there are other apps freely available in the App Store that host incredibly extreme content, such as the Urban Dictionary and potentially pornographic material such as KamaSutra apps.
It didn’t wash. It turns out that the accepted sex apps are pitched in such a way that they are not deemed ‘arousing’ or ‘objectionable’. The Urban Dictionary app provides a platform allowing users to upload and share content. Hypothetically this is what allows them to circumvent the submission criteria, no matter how extreme or objectionable the content could potentially be. We believe this may be why the Urban Dictionary remains in the App Store store today (hooray!).
(One important point to note: Apple is very clear that apps which incorporate user generated content must contain ‘report this’ functionality baked into the app, to satisfy their submission criteria.)
No matter how frustrating the process, the overriding rule is: be nice. You are dealing with people, and they will either help you, or not. Always be level headed and un-emotional. Deal in facts, figures and examples. Do not blow your stack otherwise you risk harming the reputation of your company, your developer account and your client. Don’t do it! Remember these are people, doing their jobs, just like you. It’s absolutely not worth finding out where Apple draw the line at blacklisting an account…
There are rumours about hacks to move your case up the appeal chain. The rule of thumb is it is better to address the problem at source, rather than try to argue your way through the process and risk at best being de-prioritised by the reviewer, or at worst blacklisted.
Re-submission and repeated rejection
There is a school of thought that you can re-submit an app and hope that you luck out and get a more receptive, easy-going reviewer who may accept your app where others wouldn’t. Although there is a grain of truth in this, you must change enough in the app to warrant re-submission. Simply re-versioning and trying to re-submit multiple times is not a good strategy for a healthy relationship with the iTunes Connect team, and may end up getting you blacklisted. Besides, if there is something wrong, you should invariably change it.
You can submit as many times as you like. Each submission has to go through the same approvals process. If you are consistently rejected, listen to the feedback from your reviewers. Understand what is the cause of the issue and try to work out a way to solve the problem in the most efficient and amicable way possible. Use the appeals process if required, but always try to use this time to get more information on the issue, not as an opportunity to get into arguments. When it comes right down to it, no simply means, no.
In the end we had to remove some of the ‘racier’ content to tone it down to a level that was deemed acceptable to the reviewers. It seems crazy even now that something so inherently subjective can hold the key to a yes/no decision getting a client app in to the app store.
Happily ever after
We (and our client) were concerned that removing the ‘naughtier’ content would make the app less enjoyable and fun. In the end, if the app never made it out into the public, it would never be any fun for anyone, and so we decided together to release it. What actually happened was the submissions process subtly changed the character and tone of the app, making it more inclusive and accessible to a wider audience, which could only be a good thing.
Check out Nookii Swipe for yourself here.
