Top 6 Mistakes Developers Make When Submitting an App to Apple

Partner Post - Gummicube Big Data Analytics for Mobile & ASO

Posted: February 1, 2016

Dave Bell is the Co-Founder and Chief Executive Officer of Gummicube. In this role, Dave is responsible for overseeing the business strategy for the company, driving growth and market development. Dave is a pioneer of the mobile entertainment industry with more than 15 years of experience publishing, marketing and distributing mobile applications and games across carrier, direct to consumer and app store channels.

Submitting a new app or significant update to the app stores is always an exciting time and one of the highlights for those involved in mobile app publishing, marketing or development. Unlike web apps or websites in general, mobile apps go through a review and approval process before they are released or made available on the app stores.

One of the worst-case scenarios after submission is an app rejection.

Google Play’s review process is generally quick, with apps being approved or rejected within 24 to 48 hours. Recently, Google added manual reviewers and no one even noticed.

Apple on the other hand is known for having long and uneven review periods, normally at least 7 to 10 business days.

If Apple rejects your app, a simple metadata adjustment could be all that is needed. However, a fix requiring code files essentially restarts the review process.

Want to avoid being rejected by Apple? Check out the common mistakes developers should avoid before submission.

Mistakes Requiring New Bundle


Your app needs to work. Apple’s primary goal is to provide an amazing user experience, just as Facebook encourages sharing and connections. Apple wants users to be happy with the Apple ecosystem of products, all the way down to the apps in the store.

Apple has humans reviewing the app. If your app crashes or has a bug, an app will be rejected.

No “Restore Button” for in-app purchases

This one hurts because it is so easy to overlook, but will get your app rejected every time.
If your app has an in-app purchase, from removing ads to virtual currency, your app needs a Restore Button. This can be added to settings or right in the store screen, but forgetting will get your app rejected and require a new submission.

Using copyrighted material

Use of copyrighted material in the app seems to be outside of the enforcement guidelines for the Apple reviewer, but use of copyrighted images (brand logos, celebrity images, athletes with team logos) in the icon, screenshots or even mentioning a popular figure in the description will likely get your app flagged and rejected.

If your app does get rejected, screenshots can be swapped out in the app listing, but icon changes require a new code submission.

The same applies for the keywords. Apple will reject or just remove words associated with brands that the app publisher does not have a license to use, like “MLB”, “Nike” and “Disney”. Either the app is rejected or you waste a portion of these valuable 100 characters on words that Apple will reject. Instead use this space to build phrases your target users are searching for.

Just because the app made it through the review process despite copyrighted in-app content, doesn’t mean you are safe from any penalties. Brands routinely check the App Stores to find any infringement and will not hesitate to send a cease and desist or worse.

Repeated Submission of Similar Apps

Also known as “spamming the app store”, building a single code-base and repurposing for every imaginable niche will likely get your app(s) outright rejected.

The trend of building a copycat source code and re-theming 50 times (for example, Flappy Bird clones) has largely died, but it is still common for Apple to consider an app too specific, or addressing too narrow of an audience and reject.
[vc_row][vc_column css=”.vc_custom_1535357475702{padding-top: 0px !important;padding-right: 0px !important;padding-bottom: 0px !important;padding-left: 0px !important;border-radius: 5px !important;}”][vc_cta h2=”” shape=”square” style=”custom” el_width=”xl” css=”.vc_custom_1535460113877{border-top-width: 0px !important;padding-top: 10px !important;padding-right: 0px !important;padding-bottom: 10px !important;padding-left: 0px !important;background-color: #ffffff !important;border-top-color: #ffffff !important;}” custom_background=”#ffffff” el_class=”cta-directory”]

IOS App Developers

See all IOS app development companies to find the best fit for your business.

[/vc_cta][/vc_column][/vc_row][vc_row][vc_column][vc_btn title=”IOS App Development Companies” style=”flat” shape=”square” color=”green” align=”center” link=”||target:%20_blank|” css=”.vc_custom_1535459943751{margin-top: -62px !important;}”][/vc_column][/vc_row][vc_column css=”.vc_custom_1535357475702{padding-top: 0px !important;padding-right: 0px !important;padding-bottom: 0px !important;padding-left: 0px !important;border-radius: 5px !important;}”][/vc_column]

App Listing Metadata Mistakes

Incomplete submissions

The process of building an app or adding a new app version with the app listing elements is generally a marketing function. Uploading the build is usually done by a developer. It is not uncommon to create an app listing and leave some placeholder images in one of the supported device screenshot fields or to add dummy text to a description of an in-app item while the developers complete the app.

This mistake like others is easy to fix, but can add days to the review period and is easy to avoid with a good app submission process or checklist.

Keyword Stuffing Metadata

Apple provides three fields for a developer to help index their app: App Name, Keywords and Description.

Apple provides and allows 255 characters for the App Name field of the app store listing. Since the keywords field and the app name have such a big impact on how Apple indexes an app – publishers would “stuff” any remotely relevant keyword into the app name resulting in “keyword stuffed” titles.


Apple will deny your app for keyword stuffing, or just remove any keywords they don’t agree with from your app name and keywords field.

Instead, try to maximize the value of the App Name field by limiting the characters to around 80 characters, and following a format of “App Name – most important feature, second most important feature”.

Between your App Name and Keywords, your app description needs to include the keywords you chose. Apple has become quite strict with enforcing what they perceive as attempts to game their app store ranking algorithm. This includes adding words to the Keywords field that may have a higher traffic but are not relevant to the app.

An example is adding words like “bird,angry,candy” to an app that has nothing to do with birds, candy or anger.

The easiest way for a reviewer to determine if the words used in the app name and keywords field are relevant is if they have been used in the description as well. If in 4,000 characters there was no usage, why would they be used or needed as declared keywords?

The same applies to the reverse. If you choose to stuff your description with too many keywords, the chance of rejection may be higher. App store optimization strategies focusing on your app’s metadata should make sure that everything reads naturally.

Apple keeps a list of common app store rejections here.

An App Store rejection is not an insurmountable obstacle and even can be challenged with some success, but avoiding simple mistakes can shave days and even weeks off of the App Store review process.

By signing up you agree to our privacy policy. You can opt out anytime.