Another week, another Tuesday, and time for another edition of AppBoard Tuesday (ABT). By the way, have you ever wondered why we don’t bring out our internal newsletter on the first day of the week? Well, Mondays are when you might be feeling a little ‘blue’ (c’mon, who doesn’t feel a bit of ‘Monday Blues’?) – so Tuesday is a much better option to get your attention to the stuff we share in our ABTs.
Okay, enough of the starters – now for the main course. This week, we will be discussing an issue that every mobile application developer lives in mortal fear of – the risk of their apps getting rejected at Apple iTunes. According to CEO Tim Cook himself, around 30% of all the submitted apps are rejected every week, simply because developers fail to meet specific guidelines. We won’t be talking about the more evident causes of such app-rejection, like presence of bugs/malware and a high frequency of app crashes. Instead, readers will be acquainted with other, often overlooked factors. Be wary of these issues, before submitting your app:
Usage Of Apple’s Copyrighted Images
Apple Inc. has a wide range of bright and stylish user-interface components, pictures, buttons, and similar stuff – which you might feel would look just perfect on your app. If you happen to pinch and upload a copyrighted image though, your app is almost certain to get rejected. The designers at Apple are creative, but they don’t like their creations being randomly used by others.
Mentioning The Names Of Other Platforms
Like Teknowledge, there are many other companies that are into cross-platform mobile app development. On iTunes though, you must never mention that your app is ‘also available on Google Play Store’, or any other platforms. Apple, understandably, hates it when the names of its rivals are mentioned in its store – and your app might face a swift rejection as a result.
Note: This is not an iTunes-exclusive regulation. On no online store should you ever mention the other platforms your mobile app supports. Publish such information on your website, social media pages and press releases instead.
Use Of Apple Product Names
Have an app (let’s say it’s name is ABCWorld) fully customized for iPhone 5? Don’t make the folly of naming it ‘iPhone ABCWorld app’. In general, avoid the temptation to use the names of any Apple product in your app name. Remember, terms like ‘iphone’, iPad’, ‘iPod Touch’ and the like are trademark properties of Apple. App developers have no right to use them for commercial purposes.
Submitting Apps That Save Data On Users’ Devices
With the release of iOS 5.1, Apple has categorically debarred any app that saves data on the devices of users. The latest iOS smartphones and tablets have iCloud support, and your app is not supposed to abuse the space available here. Create the application in a way that, the Local Storage and the device cache is used for data-storage. Saved data should never have any overwrite option.
Using Only The iOS Simulator For Speed Testing
No matter how beautiful and innovative the splash screens of your apps are, no one would wait for minutes for it to load properly. On the iOS simulator, an app should load within a maximum of 15 seconds. However, that’s not all what you need to consider. Test the speed of the app on slightly older iOS device models as well, and make sure that the load speed is high enough on them as well. Not everyone has the iPhone 5S – and you need to offer great user-experience to those having older phones too.
A ‘Beta’ App Never Gets Approved
All iPhone app developers have felt that the review process at the iTunes store is too stringent. Let’s be fair over here though – why on earth would Apple want to showcase a mobile application that is unfinished? Submit only the final, pre-tested version of the app, and do not put in words like ‘preview’ or ‘beta’ in its name. At times, naming a new app ‘Version 0.9’ can spell its doom!
Creating An App With Extremely Limited User Appeal
Apple wishes that all iOS apps should have a mass appeal (okay, our My Budget Tracker is not meant to be as popular as Angry Birds!). If you develop and submit an application that caters to the needs of an extremely small niche of mobile users – you would be, in essence, toying with the risks of rejection. It’s not always possible to come up with apps that everybody would be interested in – but it is advisable to widen the set of potential users as much as possible.
Using Third-Party Payment Channels
Users should have the option of purchasing an iOS application through their iTunes account, and there must never be any other alternative ways. Do not include links on any of your app pages/screens, that lead users to a third-party payment gateway (for digital subscriptions as well as in-app purchases). Even biggies like Dropbox got banned from the Apple store – simply because it had flouted this regulation. Don’t make the mistake of thinking that providing more purchase options would add to users’ convenience. If your app gets booted out, no one will get to see it!
Implementation Of Private APIs
Apple cares for the confidentiality of the information stored in the iOS devices of users’ – and hence this regulation. If your app calls an external framework, private API, or a coding library – there are chances that it will pick up (without the user’s content) information from the smartphones and tablets in which they are installed. Avoid using such external, private APIs – the authorities at Apple do not like them at all!
Excessive Vibrations
While there has been no official statement about the maximum permissible level/duration of vibrations in iPhone apps, it is always better to err on the safer side. There have been many cases till date where apps that generate excessive vibrations (mostly at the time of sending notifications) have been disapproved by Apple. In general too, people won’t like apps that would cause their phones to vibrate all day long – so what’s the point?
Developing Apps That Are Bandwidth Killers
If your all-new snazzy app places too much strain on the available mobile bandwidth of prospective users, Apple won’t take too kindly to them. Applications that have .ipa images of size more than 50 MB have practically minimal chances of approval. You need to remember that there are many users who have limited cellular data plans on their devices – and your app would be either too slow, or completely non-functional for them. Keep a close tab on the megabytes of data downloaded, every time your app is launched (during the mobile app testing phase). If it hogs too much of data, don’t bother submitting it to iTunes before doing the necessary modifications.
Not Bothering To Ask For User Permissions
Apart from ensuring that your app remains functional even when the network connectivity is weak (or absent) – this is yet another factor you need to consider. On all iOS 6 devices, Apple has made it mandatory for apps to ask for users’ permissions for accessing the information stored in their devices. Even when such permission request is denied, the app needs to remain functional. If the app you have submitted crashes whenever someone does not allow it to access personal information, it won’t be approved by Apple. Rest assured.
Presence Of Adult Content In Apps
Right from the app name, to the on-page content and links present in it – if anything is even vaguely suggestive of porn, iTunes will refuse to take a second look at the application. In early-2010, Apple cracked down on all apps that had sexually provocative names and/or functionality. At Google Play Store, you can use a third-party marketplace to showcase adult-themed Android apps. On iTunes, there is no chance of doing the same.
Apps Created For A Short Time-Span (Usually, an event)
Apple wishes all iOS applications to deliver value to users over a long time-span. Apps that are specifically developed for lotteries, sweepstakes or any other form of one-shot contests violate this – and hence, are generally rejected at the first go. If you have come up with an app that only promotes a short-duration event, don’t expect it to find favor at iTunes.
Make sure that your products do not have the same (or are not too much ‘inspired’ by) the existing applications at iTunes. Do not submit an app that has the look and feel of a mobile website. Be careful while implementing all the human interface features. We’ve learnt these little tricks to get iPhone apps approved at iTunes without any hassles – and we hope that other app developers would be benefited by the above pointers too.
And with that, it’s time to wrap up the fourth edition of AppBoard Tuesday. Next week, we will be covering yet another relevant issue related to mobile apps. Do feel free to suggest any topic that you wish to be addressed through this newsletter. Oh, and keep in mind – on the 31st, ‘Infowatch May’ will be out. Till the next time, stay zapped with…you know it by now…apps!