Why mobile apps get rejected from the Apple app store?
The Apple App Store review process is designed to keep the application ecosystem healthy and to protect users from hostile or low-quality mobile applications. And the system works mainly. But sometimes an application is rejected for reasons that can not be expected, and may force mobile app developers to fight to delay release dates or even have to redevelop key functions.
Before continuing on that path, here are nine surprising reasons why the App Store rejects applications you should consider before submitting your next application:
1. Use of the word "beta" or indicating that your application is unfinished
Google has become an industry-standard practice for launching indefinite "beta" services, but Apple can be quite strict about any indication that an application is not finished or is not yet ready for prime time. We have seen applications rejected by being labeled "Beta", "Preview" and even "Version 0.9".
2. Long loading time
All mobile operating systems, iOS, Android and even Windows, impose a maximum time to start the application. For iOS, the limit is approximately 15 seconds, and if your application is not running, the operating system will kill it.
But even if your application is loaded within limits during your local test, slower network connections, slower hardware, and other differences in the environment can cause your application to start too slowly during the review process. So do not rely on the iOS simulator alone: be sure to test the real hardware and keep some older phones to make sure all users have a quick start.
Remember, the loading time of your application is your first opportunity to impress your users.
3. Link to external payment schemes
Apple requires that all digital content be sold through the integrated shopping mechanism in the iTunes-based application. This applies to both single purchases and digital subscriptions. If your application accepts other payment mechanisms for digital content, you can be sure that it will be rejected. This is the reason why the Kindle application does not allow users to buy new books.
An important subtlety is that this rule applies even to linked web pages from your application. The Dropbox application was famous for its rejection by Apple because the web-based login screen contained a link to buy additional space. This not only affected the Dropbox application, but also all the applications that used the Dropbox SDK!
Therefore, check your workflow to ensure that all purchases are made through the user's iTunes account or that they are completely deleted. This rule does not apply to non-digital services or products, so Apply does not apply a reduction of your Uber trips or other hotel rooms booked through an application.
4. Do not mention other compatible platforms
This rule is not exclusive to Apple: none of the markets of cured applications like when applications mention rival platforms by name. Therefore, if your application is also available in Windows or Android, advertise it on your website, not in the app or in the description of the app store.
5. Technical problems of location
The users of your mobile application will be everywhere, not only in the city or country where the development took place.
Even if you have not located your application for several languages, you will look like an amateur if 300 Yen comes out with a cost of $ 300.00 for in-app purchases. Use add-ons such as NSNumberFormatter or Invariant Culture and a simulator to test the user experience in different regional settings to make sure dates and other data match the user's location.
For example, we have seen that European applications do not handle the negative values of latitude and longitude and, therefore, do not pass the revision in Cupertino, which is in Longitude -122.03. Make sure your application works at all points on the map, and especially check that your latitude and longitude mathematics for groups of points cover the positive / negative limits of the main meridian and the equator.
6. Inappropriate use of storage and file systems
Shortly after iOS 5.1 was released, Apple rejected an application update because the developers had unpacked the 2MB database from the application package into the file system, violating iCloud's ideal of backing up only the content generated by the user.
You can not make a backup copy of the data that can be generated again because they are static, are sent with the application or are easily downloaded from a remote server. For non-user data, choose a cache storage location or check with a "do not backup" attribute.
7. User blocks that deny permits
In iOS 6, users must give permission for applications to access the address book, photo gallery, location, calendar, reminders, Bluetooth accounts, Twitter and Facebook. If the user decides to deny an application access to any of these services, Apple requires the application to continue functioning anyway.
This will undoubtedly be tested during validation and will be an automatic rejection if it does not work properly. You must test all combinations of "allow" and "deny" for all the data your application uses, even if the user allows access but then denies it in Settings.
8. Inappropriate use of icons and buttons
Many iOS applications have been rejected due to small UI issues that have nothing to do with performance or functionality. Make sure Apple's built-in icons and buttons are uniform in appearance and functionality by using a UItabBarSystemItem standard and familiarize yourself with Apple's human interface guidelines.
For example, you do not want to use the "compose" icon for anything other than creating content. Apple engineers want applications to behave predictably and, therefore, are understandably strict about it.
9. Misuse of trademarks and logos
Do not use any proprietary material or Apple icons or logos in any part of your application or product images. This includes the use of icons that have a drawing of an iPhone! We have also seen applications denied for having trademarks in the keywords of the application.
The flip side of this is that you should make sure your mobile application does not hide attribution information on any embedded maps; this is also an automatic rejection.
For more information related to mobile app development services and app installation help please go through: www.sp-assurance.com/mobile-app-development
Contact Details:
Company: SP Assurance
Email: sales.team@sp-assurance.com
Mobile: +1-972-992-4200
Website: www.sp-assurance.com
Contact: www.sp-assurance.com/contact-us
Before continuing on that path, here are nine surprising reasons why the App Store rejects applications you should consider before submitting your next application:
1. Use of the word "beta" or indicating that your application is unfinished
Google has become an industry-standard practice for launching indefinite "beta" services, but Apple can be quite strict about any indication that an application is not finished or is not yet ready for prime time. We have seen applications rejected by being labeled "Beta", "Preview" and even "Version 0.9".
2. Long loading time
All mobile operating systems, iOS, Android and even Windows, impose a maximum time to start the application. For iOS, the limit is approximately 15 seconds, and if your application is not running, the operating system will kill it.
But even if your application is loaded within limits during your local test, slower network connections, slower hardware, and other differences in the environment can cause your application to start too slowly during the review process. So do not rely on the iOS simulator alone: be sure to test the real hardware and keep some older phones to make sure all users have a quick start.
Remember, the loading time of your application is your first opportunity to impress your users.
3. Link to external payment schemes
Apple requires that all digital content be sold through the integrated shopping mechanism in the iTunes-based application. This applies to both single purchases and digital subscriptions. If your application accepts other payment mechanisms for digital content, you can be sure that it will be rejected. This is the reason why the Kindle application does not allow users to buy new books.
An important subtlety is that this rule applies even to linked web pages from your application. The Dropbox application was famous for its rejection by Apple because the web-based login screen contained a link to buy additional space. This not only affected the Dropbox application, but also all the applications that used the Dropbox SDK!
Therefore, check your workflow to ensure that all purchases are made through the user's iTunes account or that they are completely deleted. This rule does not apply to non-digital services or products, so Apply does not apply a reduction of your Uber trips or other hotel rooms booked through an application.
4. Do not mention other compatible platforms
This rule is not exclusive to Apple: none of the markets of cured applications like when applications mention rival platforms by name. Therefore, if your application is also available in Windows or Android, advertise it on your website, not in the app or in the description of the app store.
5. Technical problems of location
The users of your mobile application will be everywhere, not only in the city or country where the development took place.
Even if you have not located your application for several languages, you will look like an amateur if 300 Yen comes out with a cost of $ 300.00 for in-app purchases. Use add-ons such as NSNumberFormatter or Invariant Culture and a simulator to test the user experience in different regional settings to make sure dates and other data match the user's location.
For example, we have seen that European applications do not handle the negative values of latitude and longitude and, therefore, do not pass the revision in Cupertino, which is in Longitude -122.03. Make sure your application works at all points on the map, and especially check that your latitude and longitude mathematics for groups of points cover the positive / negative limits of the main meridian and the equator.
6. Inappropriate use of storage and file systems
Shortly after iOS 5.1 was released, Apple rejected an application update because the developers had unpacked the 2MB database from the application package into the file system, violating iCloud's ideal of backing up only the content generated by the user.
You can not make a backup copy of the data that can be generated again because they are static, are sent with the application or are easily downloaded from a remote server. For non-user data, choose a cache storage location or check with a "do not backup" attribute.
7. User blocks that deny permits
In iOS 6, users must give permission for applications to access the address book, photo gallery, location, calendar, reminders, Bluetooth accounts, Twitter and Facebook. If the user decides to deny an application access to any of these services, Apple requires the application to continue functioning anyway.
This will undoubtedly be tested during validation and will be an automatic rejection if it does not work properly. You must test all combinations of "allow" and "deny" for all the data your application uses, even if the user allows access but then denies it in Settings.
8. Inappropriate use of icons and buttons
Many iOS applications have been rejected due to small UI issues that have nothing to do with performance or functionality. Make sure Apple's built-in icons and buttons are uniform in appearance and functionality by using a UItabBarSystemItem standard and familiarize yourself with Apple's human interface guidelines.
For example, you do not want to use the "compose" icon for anything other than creating content. Apple engineers want applications to behave predictably and, therefore, are understandably strict about it.
9. Misuse of trademarks and logos
Do not use any proprietary material or Apple icons or logos in any part of your application or product images. This includes the use of icons that have a drawing of an iPhone! We have also seen applications denied for having trademarks in the keywords of the application.
The flip side of this is that you should make sure your mobile application does not hide attribution information on any embedded maps; this is also an automatic rejection.
For more information related to mobile app development services and app installation help please go through: www.sp-assurance.com/mobile-app-development
Contact Details:
Company: SP Assurance
Email: sales.team@sp-assurance.com
Mobile: +1-972-992-4200
Website: www.sp-assurance.com
Contact: www.sp-assurance.com/contact-us
Comments
Post a Comment