Useful Blogs for App Promotion
500,000 monthly readers are maximizing their advertising conversions with conversion intelligence.
The average online user is exposed to anywhere from 6,000 to 10,000 ads every day.
Aug 3 2021
For developers, the biggest frustration with the App Store review process is that apps are often returned as soon as an issue is found, rather than receiving a top-to-bottom check the first time around. For example, an app returned for metadata errors may still have a broken link or interface glitch that needs fixing — but the developer won’t find out about the additional issues until they’ve re-submitted their app, waited a couple weeks for review, and gotten rejected again.
It’s not uncommon for individual or inexperienced iPhone app developers to submit an app two, three, or ten times before being accepted. Meanwhile, carefully-planned launch campaigns hang in the balance for weeks. It’s one of the biggest reasons that developers working with agencies experience greater success than those trying to manage sprawling code bases by themselves, or with teams of freelancers.
While you might expect bugs and performance issues to be the biggest problem facing iOS app developers, an official report on Apple’s developer blog shows that only 12 percent of app store rejections are caused by bugs, making them only the second-most prevalent problem (behind incomplete information, at a surprising 16 percent).
So, what are the most common reasons for App Store rejections? And most importantly, how can your startup avoid them?
Users deserve to know what they're getting when they download or purchase your App, so make sure the App's description, screen snapshots, and previews accurately reflect the core experience of the App, and remember to keep it updated to stay current with new versions.
Apple has this ruling mainly because the app title, description, screenshots, etc. are seriously inconsistent with the function of the app. If you use Android screenshots or browser screenshots, it will cause rejection.
Ensure that your own title and subtitle meet the requirements. Apple has recently changed all the directions for title review, so developers need to focus on that.
In addition, if the title meets the requirements, consider replacing the metadata such as screenshots and preview videos to ensure that the App functions and processes are consistent with the relevant display.
Be sure to remove the hidden function module code, and if there is a need to hide the function code and directed jump link URL, it is recommended to obfuscate the processing and increase the logic complexity appropriately.
Applications submitted to App Review (including apps available for pre-order) should be the final version of the app and should contain all necessary metadata and valid URLs.
All placeholder text, blank websites, and other temporary content should be removed prior to submission. Be sure to test the App for errors and stability on your device before submitting the App; if your App requires a login, provide demo account information (and turn on your backend service).
If you provide in-app purchases in your App, make sure they are visible to the reviewer and complete and up-to-date, otherwise please state the reason in the review notes.
Please do not treat App Review as a software testing service. We will reject incomplete App packages and binaries that will crash or have obvious technical problems.
No obvious bugs such as crashes and loading failures in the uploaded App; App does not support use under IPv6 network; test account; hidden switches and other operations.
Developers must test the product in advance for bugs, whether it works properly under IPV6 network, etc. If you encounter a rejection for this reason, it is recommended to respond to each article and clarify that there is no violation.
If you want to unlock features or functionality within the App (such as subscriptions, in-game currency, game levels, access to premium content, or unlocking the full version, etc.), you must use the in-app purchase program.
The App may not use its own mechanisms to unlock content or features, such as license keys, augmented reality markers, QR codes, etc.
The App and corresponding metadata may not contain buttons, external links, or other call-to-action terms that direct customers to make purchases using mechanisms other than in-app purchase items.
The App may provide in-App purchase currency for customers to "reward" digital content providers within the App.
All credits and game currency purchased through in-App purchases may not expire, and you should ensure that a recovery mechanism is designed for all recoverable in-App purchases.
Be sure to specify the correct type of purchasable or your App will be rejected.
Apps may enable gifts for the content of their in-App purchases. Refunds for such gifts can only be returned to the original purchaser and the contents of the gift cannot be replaced.
Apps distributed through the Mac App Store can host plug-ins or extensions based on non-App Store mechanisms.
Apps that offer "loot boxes" or other random virtual item purchase mechanisms must disclose the odds of obtaining each type of item to customers before they make a purchase.
Non-subscription apps may offer a time-based free trial before offering a full unlocking option by setting the non-consumable IAP item in "Price Level 0" and naming it according to the naming convention "XX day trial".
Before starting the trial, the app must clearly indicate the length of the trial period, the content or services that will no longer be accessible at the end of the trial period, and any subsequent fees that the user will have to pay to get full functionality.
This is mainly due to the access to third-party payments in the App.
Continue to use Apple's own payment methods, by using the form of internal purchase for display. If the virtual product is hidden or the payment method is changed after passing, there is a risk of downgrading and pinning.
The main problem is that the App forces users to register and secretly collects/shares their personal information based on features that do not require user information.
Apple is taking this more seriously after WWDC, so developers need to pay extra attention.
It is necessary to consult with the user first and let the user agree to register, and the "strong login" function must be modified to prompt the login version.
In addition, some data retrieval functions should be consulted with users to avoid Apple's default unauthorized access to cell phone information.
For social products, or products with strong UGC content (e.g., Facebook, Twitter, instagram), Apple requires developers to filter objectionable content (e.g., violence, pornography, copyright infringement, etc.); and to provide a strict review mechanism and detailed developer contact information.
It is recommended to ensure that the user content in the App does not contain violence, pornography, etc. Also, according to the information collected so far, "active telephone communication" can only be applied for the 1.2 clause, so developers can try to apply for telephone communication if the relevant clause is rejected.
App is unauthorized to use copyrighted third-party materials; in addition, on-shelf App is not similar to Apple's existing products.
This time at WWDC, after Apple's own software update, developers are advised to verify their own products and differentiate the App from Apple products.
It is recommended that you ensure that the App contains only content for which you have created or have permission to use.
Use copyrighted third-party written evidence for presentation when submitting products.
App content that is offensive, inconsiderate, disturbing, offensive or vulgar.
It is recommended that the audit mechanism, the current national policy in this regard is also very concerned, it is recommended to ensure the safety of the content, timely processing of the relevant display content, do not have a fluke mentality.
This generally means that the App is similar to someone else's App on the shelf in terms of functionality or code, which in layman's terms is what Apple considers a vest package.
This can be solved by changing the name, icon, main color, code, etc. The focus is on the code. And be careful to submit the same App packages at least one day apart.
Don't put up multiple packages of the same type at once, as it is easy to be identified and targeted by Apple.
Apple believes that uploaded apps that don't have enough functionality or don't have their own core features, such as a product that is packaged directly onto a web page can easily trigger this problem.
You can add some features to enrich the product (navigation bar, drop-down refresh, push notifications, etc.). If you feel that the product is fully functional and has not yet passed the review, you can explain to Apple the user needs that the product solves and the specific features that are presented, and you can also send screenshots of the web page and the App directly to Apple for better identification.
The App does not have permission to share collected user data with third parties and does not specify the purpose of use, such as location, account number, etc.
If you want to take user data, you need to prompt the user and get permission from the user, or make it optional, and clearly inform Apple of the purpose of using the user's data.
In general, a pop-up message should be provided to indicate what the permission is for, and both the user and the provider (Apple) should be informed.
Of course, if Apple clearly gives the reason for rejection in the email, you can make corresponding changes according to the problems Apple feedbacks.
To ensure that the attitude is proper, timely processing, when no mistakes are made, you can directly appeal, and it is recommended to come up with strong evidence for proof, which will improve the speed of passing the review.
If you are seeking to know more about the game industry trends in 2021 and Advise of optimizing your game's development, growth, and revenue strategies please join our Facebook group for more fresh and timely industry news!
Get FREE Optimization Consultation
Let's Grow Your App & Get Massive Traffic!
All content, layout and frame code of all ASOWorld blog sections belong to the original content and technical team, all reproduction and references need to indicate the source and link in the obvious position, otherwise legal responsibility will be pursued.