Apple App Submission Anxiety(AASA), and how to Alleviate it
OK so first of all i'm not actually sure that medical journals actually recognise AASA as a condition, but they should. As an agency head I watch the submission process happen up to 50 times a year, and each time is as nerve racking as the last. You submit your app to the Apple god's and wait to hear whether they deem it satisfactory.
It is off course true that Apple do have a set of guidelines you can try to interpret in order to minimise the chances of seeing that little red circle that alerts you to the fact your app has been rejected. In practice however I have found the guidelines to be interpreted inconsistently amongst Apple's many testers.
All hope however is not lost, use some of the simple techniques below to minimise your risk of rejection, and get your app out there as quickly as possible.
User Interface:
I for one am not a fan of sticking with convention when it comes to user interfaces, however creating something 'different' is one of the easiest ways of getting a rejection from the Apple app store.
Do not however let this stop you imagining up a unique layout and design for your app. In my experience Apple apply sensibility to most decisions they make, so ensure you do too.
DO's:
- Use icons that make sense, they don't have to be standard apple icons, but do make sure that your pause button doesn't look like a menu button for example.
- Ensure total consistency throughout your application.
- Ask users to test your application, and make sure they can understand your navigation with zero assistance.
DONT's:
- Assume because you know how your app works everyone will.
- Use layouts that are not relevant to IOS.(Such as an app layouts designed for Android or Windows phone)
Admin Accounts:
If your app needs a user account to access any parts of it, then ensure that a demo account is supplied to Apple at time of submission.
Test Data:
Apple does not accept an app that is potentially still under testing. This is what test flight is for. Ensure that there are no mentions of the words 'testing' or 'beta' anywhere within your app, and that even places such as news-feeds are emptied of any test data. I find this requirement a bit strange, for example I recently submitted an app that showed users upcoming events. (minor functionality) I submitted it to apple with a test event so they could see what it would look like, the app was rejected. When I explained to Apple it was because we had no events coming up to insert into the app, and I just wanted to show them what an example would look like, I was told that was not good enough.
Complex/Multi User Workflows:
This doesn't happen often, but occasionally we create an app that needs 2 or more people to interact with it for it to function correctly. For example a game that needs 2 or more players, or a taxi app that is used by riders and drivers.
Under these circumstances I have been asked by Apple to supply video walkthroughs of how the app interacts and functions. If you do have a situation where you need to submit a complex or multi user app then I suggest you ensure you explain to Apple the functional flow as graphically as possible.
Hardware Dependencies:
This is an interesting case, you have built an app that only works with a unique piece of 3rd party hardware or bluetooth or wifi. How will Apple test this? Over the years I have usually provided a demo mode within the app so that the tester can use the functionality without the third party device. I double up by attaching a video overview of the app. So far I have been lucky enough not to have to ship hardware devices to Apple.
General Quality:
This is the most ambiguous part of the review process, when we first started cross compiling apps, Apple kept rejecting one particular app over and over again only citing general quality as an issue. Nothing we could do made the situation any better. We finally rebuilt the app using the native SDK, identically to the cross compiled version and it was accepted. I haven't had any cross compiled issues since, but it does highlight how 'quality' is a relative term in these circles.
At the very least, focus on the points below and your chances of success will be enhanced:
Speed: Ensure the app loads data within a reasonable amount of time, think a maximum of 2-3 seconds, not 5-10.
When a button is pressed it should respond precisely, if you do have a large amount of data to download such as audio or video content that is not streaming, then ensure the user knows about it through download status indicators and user friendly messages.
Crashes: Ensure you thoroughly test your app to limit any crashes to zero. There are no excuses for an app that keeps crashing.
Improper use of SDK for Storage, etc: Apple has strict guidelines for where data is stored, in order to ensure only appropriate data is backed up to its cloud service for example. Ensure you comply with these. A rejection related to this is simply laziness.
Payment Mechanisms: Since the launch of in app purchases Apple have been very strict on the use of third party payment methods within published apps. That is not to say you cannot use any third parties, but it is imperative any third parties are used within the rules set out by Apple.
Trademarks: This one may be obvious, but ensure that none of the content included in your app infringes on anyone else's intellectual property.
This list is not exhaustive, its a snapshot from someone that has overseen the submission of well over 50 applications, each bringing its own unique set of challenges.
Forming a checklist using some of the above, mixed in with points related directly to the nuances of your own app will give you the best chance of first review approval, and reduce the nasty symptoms of AASA.
Post A Comment:
0 comments: