A Road M-app – Submitting Your App to the App Store
The application world is changing; companies today want an “app” more than they want traditional desktop applications. An “app” is a mobile application designed to run on iPhone, Android, or Windows Mobile. Many new companies even forgo a full web presence and launch solely in the mobile space. At Rose-Hulman Ventures, we encounter these companies, others migrating their legacy applications to mobile to follow their market, and many that just want to extend their platform into mobile. Our contacts frequently ask, “What is involved in submitting an app to the App Store for iPhone/iPad”?
Submitting to the App Store has become straightforward but requires planning, testing, and an Apple Developer Account. The key steps in the process are:
- Planning/Design – Before starting to develop, identify how the app will function and how the screens will look. This is critical to efficiently working with developers.
- Implementation / Internal Testing – Developers will use Objective-C or the new Swift language to create the application code and user interface. Apple’s TestFlight system allows you to pre-test your app.
- Beta Testing – TestFlight allows you to share your app with up to 1000 pre-selected users. This allows you to test the application and get valuable feedback before launching.
- Submission – The last step is for developers to upload the app and your team to choose how it will be featured in the App Store.
Apple’s App Store is accessible directly from the App Store icon on a device or via iTunes on PC and Mac and is the only official way to distribute iPhone and iPad applications to the public. Apple’s TestFlight gets apps to beta testers. Enterprise distribution, typically used by large corporations to distribute apps privately within the company, is also available.
Collectively known as iOS applications, iPhone and iPad applications are tightly regulated by Apple. (This is in stark contrast to the Google Play store for Android where the most substantive requirement is a nominal registration fee.) Early on, Apple’s rejection criteria were unpublished and shrouded in mystery. Now, after 7 years of operation, the review guidelines are published and app creators should feel confident the guidelines have been well tested. If you are hiring developers, a seasoned group will identify potential issues even as you are beginning your design stage. If you are constructing the app in-house, review Apple’s guidelines as your first step. If your app will be integrating with a custom hardware device, check to see if you will also need to be part of the MFi program as well. Tethered devices and some Bluetooth devices will need this extra step.
The common causes of app rejections lie in these five categories:
- Bugs/crashes – Exhibiting poor quality includes things such as apps that crash and obvious bugs where the application does not perform as expected. If a dialog has a delete button, pressing it should delete the appropriate item. Apple will test your app. Any of these issues will mean they stop reviewing and return your submission with a rejection notice. The motivation here is to improve end user experience. No one likes to install a new app only to have it crash.
- Incomplete/Shoddy looking app – Apps that are not complete will not be accepted. You cannot submit your app half-way completed to see if the completed portions are approved before finishing the other half. Unfinished, shoddy looking apps, and ones that are the same as numerous others in the App Store, will be rejected.
- Trademarks and competing technologies – Apple is protective of its trademarks and will not approve an app that displays them without permission. This includes the app itself and the meta-data such as the description and screenshots of your app. Similarly, references to a competing technology such as Android, are also prohibited. A photo of an iPhone or Android device to showcase your image editing software is an example of inappropriate use.
- Forcing users to provide private info – Apple is very conscious that users value their privacy and will reject an app for requiring disclosure of private information when it’s not necessary. Examples include requiring users to provide their Facebook account information or email addresses when that information is not required for the app to function.
Test your app thoroughly and review for these criteria before submitting. “Testing by fire” by submitting the app without thorough testing will lock you into a lengthy process of rejection-fix-resubmit. Each submission cycle typically takes two weeks from the time you make your submission to when you receive a response from Apple. Several cycles will quickly throw a schedule off track and likely far exceed the time it may have taken to test the app more thoroughly.
Once your app is submitted, you enter the maintenance phase. As you discover bugs, improve your functionality, or the user interface, you can submit new versions. The process is the same as the initial submission. Minor changes and bug fixes should be quick and painless since the app has already been through tough scrutiny.