Skip to content

You Can No Longer Charge for Alternate App Icons

Stuart Breckenridge
Stuart Breckenridge
2 min read

After eight months on the App Store and 11 releases, App Review have rejected the next version of Singapore Rail because it contains alternative icons that are part of an in-app purchase. This in-app purchase has been part of every release so far. Similarly, in my App Library, I can count at least five other apps that charge distinctly for alternative app icons and yet more that include them when bundled as part of a subscription[1]. The application of this rule is inconsistent, to say the least.

The rejection:

Guideline 3.2.2 - Business - Other Business Model Issues - Unacceptable

We noticed that your in-app purchase product provides access to built-in iOS capabilities, which is not appropriate for the App Store. Specifically, your app uses in-app purchases to sell alternative app icons.

Next Steps

To resolve this issue, please revise your in-app purchase product to provide functionality other than what the device provides or remove it entirely.

The 3.2.2 guideline makes no mention of alternative icons:

Monetizing built-in capabilities provided by the hardware or operating system, such as Push Notifications, the camera, or the gyroscope; or Apple services, such as Apple Music access or iCloud storage.

Regardless, the current submission is a bug fix release for a crasher that I want to get out as soon as possible. Short of removing the purchase entirely, I asked if, given that this is a bug fix release, if it could be approved and I'll work on the violation in the next update. This would be inline with the App Review process updates:

For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues. You’ll instead be able to address guideline violations in your next submission.

The response I got back was not helpful:

We are happy to work with developers to deliver bug fix submissions to their users as quickly as possible, provided the app is already on the App Store and is free of legal or safety concerns. Otherwise, we ask that you resolve issues before we approve a submission. If we can grant you additional time to implement our feedback in a future submission, we will let you know.

You can find more information in the App Review process update.

We look forward to reviewing your app once the appropriate changes have been made.

I don't understand this response. The is a bug fix submission for an app already on the App Store, and the app is free of legal and safety concerns (this is a business model issue). So do I have to resubmit—in which case App Review is ignoring their own guidelines—or is the current submission ok to go forward?


  • I'd argue that Push Notifications should not be included in the list of features that developers can't monetise. While they are undoubtably a feature provided by the operating system, the infrastructure to support them is not free. There's, at a minimum, at least one server required for both an API and a database, along with backups etc.
  • Bug fix releases should be approved before guideline violations are enforced. It shouldn't be the case that a bug fix release is rejected and only approved after a back-and-forth with App Review.
  • The App Review Guidelines should be updated to specify whether Alternative Icons are considered a built-in capability of the OS and therefore not available for in-app purchase. These issues shouldn't be enforced inconsistently through App Review case law.

  1. I am not sure what App Review's stance is on the latter of these scenarios. Bundled as part of a subscription, or otherwise, it's still the case that they are providing access to a built-in iOS capability. ↩︎

📱App Development