Over the years, we’ve submitted hundreds of apps to the App Store. In that time, we’ve learned that there’s a lot of grey area to navigate within the stated App Store guidelines, which often seem a bit overarching. And while it is certainly helpful to know what the most common app rejections are according to Apple’s developer site, we find that there are actually just a few areas which we see entrepreneurs and businesses overlook, time and again. Each of them is common sense if you just put yourself in Apple’s shoes, and what clearly differentiates using their mobile app ecosystem from just viewing internet over a smartphone.
Lack of Native iPhone/iPad Functionality
Apple knows that one of the main things that sets apart a mobile optimized website (i.e., a website that is easy to navigate on a mobile device) and a mobile app, is the ability for a mobile app to provide a more robust and engaging experience to the user through integration of Apple’s native device features such as the camera, the microphone, GPS, swipe navigation, etc.
Think back to the first time someone showed you that really cool mobile app they were using. It was almost like magic to see things such as GPS mapping overlays and limitless feature sets built around photo, music and contacts integration. This list of native features now is mind-blowing, with things like augmented reality views of items inside the mobile app with the surrounding landscape outside the mobile app. Accordingly, it’s not a surprise that Apple wants to make sure that you are highlighting at least a few of their native features if you are going to build on their platform. This is probably the single biggest deficiency we see with app ideas that come to us for initial development. Too many static content tabs, and not enough magic!
The Website as a Mobile App
Too often we have clients come to us to build an app wherein the majority of their app is just going to be links to their existing website. If Apple wanted to get in the business of hosting websites they would have done that a long time ago. Remember that it always comes back to this core principle with Apple of providing users a highly engaging user experience. If you are in an app and click on a button or tab, and the app stops, thinks for a second, then spits you completely out of the app to a slow loading website… ask yourself if that is an engaging experience that you’d expect from a mobile app.
While certain, rarely used, content tabs in an app are fine being links to Web landing pages, the vast majority of key features and functionality in your mobile app should be native within your app. We understand why certain businesses want to have one more distinct, digital media highway (besides the Internet and Facebook) for people to find their company, but so does Apple, and it’s why they reject apps which are essentially just websites trying to onramp the App store freeway.
Abnormally Long Load Times
Somewhat overlapping with the problem of ‘website as a mobile app’, as discussed above, is the problem with apps that take abnormally long to either open and/or for a particular piece of functionality to occur. An example of this might be when a user submits or enters something in the app in order to obtain information back, or make something appear, from that action. If there’s a progress bar that barely moves or takes forever, Apple will question the Web server set-up you are employing, and subsequently reject the app until you pony up for a better server package and configuration to host your data calls. This is where a good app developer can really be an asset to you for configuring the best server set-up on a host provider that will ensure that your app runs efficiently, but also doesn’t break your bank in server costs.
Apple’s standard is that any app that takes more than 15 seconds to load from scratch is a candidate for rejection because users are not expected to wait longer than that duration. Much of the solution to the problem also involves designing the app user experience (UX) so that a clear user objective is performed by each user action, combined with the code being written correctly to expedite the calculation time. This is often a major difference between an inexperienced developer and one that has experience solving problems using the latest coding conventions and programming logic.
Over the years, we’ve submitted hundreds of apps to the App Store. In that time, we’ve learned that there’s a lot of grey area to navigate within the stated App Store guidelines, which often seem a bit overarching. And while it is certainly helpful to know what the most common app rejections are according to Apple’s developer site, we find that there are actually just a few areas which we see entrepreneurs and businesses overlook, time and again. Each of them is common sense if you just put yourself in Apple’s shoes, and what clearly differentiates using their mobile app ecosystem from just viewing internet over a smartphone.
Completely differentiate your app from your website. Otherwise, you could spend a ton on development hours creating something that Apple will simply reject at the end of the day.