Developers keep submitting apps that violate Apple's rules.

Thomas Claburn, Editor at Large, Enterprise Mobility

September 3, 2014

5 Min Read

IT Job Interviews 101: What Not To Wear

IT Job Interviews 101: What Not To Wear


IT Job Interviews 101: What Not To Wear (Click image for larger view and slideshow.)

Apple has a message for its developers: Read the @#$% manual.

Though Apple is far too reserved to actually let the expletives fly -- unlike former Microsoft CEO Steve Ballmer, if Mark Lucovsky's testimony is to be believed -- the company has for the first time published data about the reasons iOS and OS X apps get rejected by its app review staff, to stress the importance of becoming familiar with its app review criteria.

"We've highlighted some of the most common issues that cause apps to get rejected to help you better prepare your apps before submitting them for review," Apple explains on its website.

Apple requires that apps submitted to its App Store and Mac App Store meet a long list of technical, content, and design requirements. Initially, the company disallowed registered developers from discussing its requirements through a non-disclosure agreement. But in September 2010, after a number of controversial app rejections, the company made its app review rules public.

Apple's requirements are more numerous and broader in scope than Google's rules for Android developers. Both companies ban apps that attempt to deceive or violate laws or community standards. But Apple's rules give it the latitude to ban pretty much any app because it's not sufficiently useful or is somehow offensive.

[Not our fault, says Apple in celebrity photo hack. Read Apple Not Hacked In Celebrity Nude Photo Breaches.]

Both companies gain coincidental competitive benefits from bans issued ostensibly for the benefit of customers or other developers: Apple's refusal to allow iOS browsers not based on WebKit gives it control of mobile browsing on iOS devices, while Google's recent ban on Disconnect Mobile makes mobile ads more profitable.

But Google takes a more permissive approach, letting developers publish apps to Google Play without review and only removing apps when violations are discovered. Apple tries to be more careful. It employs a large number of app reviewers who approve every app before the app is admitted in its App Store or Mac App Store. Each approach presents advantages and disadvantages.

One disadvantage for Apple appears to be that too few developers actually bother to familiarize themselves with Apple's rather lengthy set of rules. By publishing the most common reasons it rejects apps, Apple aims to improve app quality and to lighten the workload of its review staff.

Here's what Apple's developers are doing wrong. Below are the 10 most common reasons Apple's reviewers reject apps, representing about 58% of all app rejections during the seven-day period ending Aug. 28.

14% -- Incomplete information
When submitting apps for review, developers must provide a substantial amount of information, from specific files to updated contact information. Unsurprisingly, many developers omit a few required details.

8% -- Crashes and bugs
Software has bugs. There's no way around it. But thorough testing can get rid of most of them. A fair number of developers appear not to be very conscientious about debugging. But Apple's review process may be part of the problem: Because it tends to take about a week from the time an app is submitted until it is reviewed and approved, developers who discover bugs after their app is submitted may be disinclined to halt the review process and restart the clock with a revised app submission. Apple should consider a way to submit a new app binary for review without affecting the app's place in the review queue.

6% -- Failure to comply with developer license agreement
This could be anything, from breaking Apple's non-disclosure agreement terms to using private APIs to inappropriate use of Apple intellectual property.

6% -- Ugly interfaces
Apple review guideline 10.6 says, "If your user interface is complex or less than very good, it may be rejected." Beauty is not in the eye of the beholder; it's a determination made by Apple.

5% -- Metadata misuse
Guideline 3.3 says, "Apps with names, descriptions, or screenshots not relevant to the App content and functionality will be rejected." These are likely to be scammy bait-and-switch apps.

5% -- Icon hijacking
Guideline 22.2 says, "Apps that contain false, fraudulent or misleading representations or use names or icons similar to other Apps will be rejected." Unethical developers will often clone successful apps and market them with confusingly similar icons or names.

4% -- Name mismatch
Apple wants app names in iTunes Connect (its developer console) to be similar to the name an app displays on a device.

4% -- Placeholder content
Apple will reject apps that have placeholder text in the app metadata, which gets displayed in App Store listings.

3% -- Missing or inaccurate app ratings
Apple asks its developers to assess the age appropriateness of app content. Sometimes developers may err, cynically (in an effort to maximize the audience for an app) or innocently (when the developer's interpretation of, say, cartoon violence differs from Apple's).

2% -- Forbidden labels
Apple says it will reject apps labeled "beta," "demo," "test," or "trial." Yet somehow, 2% of developers submitting apps for review are labeling their apps using these terms.

Apple deserves credit for publishing this information, which brings more openness to the company's relationship with its developers. In so doing, the company is broadening the commitment CEO Tim Cook made two years ago to be more transparent in terms of supplier and environmental responsibility.

You've done all the right things to defend your organization against cybercrime. Is it time to go on the offensive? Active response must be carefully thought through and even more carefully conducted. This Dark Reading report examines the rising interest in active response and recommends ways to determine whether it's right for your organization. Get the new Identifying And Discouraging Determined Hackers report today (free registration required).

About the Author(s)

Thomas Claburn

Editor at Large, Enterprise Mobility

Thomas Claburn has been writing about business and technology since 1996, for publications such as New Architect, PC Computing, InformationWeek, Salon, Wired, and Ziff Davis Smart Business. Before that, he worked in film and television, having earned a not particularly useful master's degree in film production. He wrote the original treatment for 3DO's Killing Time, a short story that appeared in On Spec, and the screenplay for an independent film called The Hanged Man, which he would later direct. He's the author of a science fiction novel, Reflecting Fires, and a sadly neglected blog, Lot 49. His iPhone game, Blocfall, is available through the iTunes App Store. His wife is a talented jazz singer; he does not sing, which is for the best.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights