Just before the annual holiday shutdown of the App Store, Apple has revised its App Store Review Guidelines to address new App Store functionality like Pre-Orders and clarify or expand a handful of existing guidelines, including the creation of apps from templates and how ’loot boxes’ and VPNs should be handled. Below is a summary of the major changes to the Guidelines. To see all the changes, check out Rich Hong’s App Store Review Guidelines gist on GitHub.
Apple has clarified its approach to which apps should be in the App Store in the introductory section of the Guidelines:
We strongly support all points of view being represented on the App Store, as long as the apps are respectful to users with differing opinions and the quality of the app experience is great. We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it.
As we reported when pre-orders were announced, apps must be complete and deliverable to customers when submitted for review:
2.3.11 Apps you submit for pre-order on the App Store must be complete and deliverable as submitted. Ensure that the app you ultimately release is not materially different from what you advertise while the app is in a pre-order state. If you make material changes to the app (e.g. change business models), you should restart your pre-order sales.
There’s a long history of apps being developed that use frameworks and APIs in ways that Apple didn’t intend. The fate of those apps has been mixed. The Guidelines now use HomeKit and HealthKit as expamples of APIs that should only be used for their intended purposes. I wouldn’t be surprised if this change is motivated in part by developers trying to use HealthKit to make watchOS podcast players that don’t have a health and fitness component.
2.5.1 Apps may only use public APIs and must run on the currently shipping OS. Learn more about public APIs. Keep your apps up-to-date and make sure you phase out any deprecated features, frameworks or technologies that will no longer be supported in future versions of an OS. Apps should use APIs and frameworks for their intended purposes and indicate that integration in their app description. For example, the HomeKit framework should provide home automation services; and HealthKit should be used for health and fitness purposes and integrate with the Health app.
Apple has also clarified In-App Purchase rules as they apply to the common practice of selling ‘loot boxes’ of random items that can be used in games. The Guidelines now require that developers disclose the odds of getting each item:
3.1 Payments
3.1.1 In-App Purchase:
Apps offering “loot boxes” or other mechanisms that provide randomized virtual items for purchase must disclose the odds of receiving each type of item to customers prior to purchase.
As Polygon reported earlier this week:
This update mirrors regulations in China that require games with randomized elements disclose the odds that control the “random” loot drops.
Subscription mechanics have been revised too. A single subscription can be shared across apps and services, but not with third-party apps or services. Apple specifically notes that games offered this way must be owned or licensed by the developer and not be part of a game publishing platform:
You may offer a single subscription that is shared across your own apps and services, but these subscriptions may not extend to third party apps or services. Games offered in a game subscription must be owned or exclusively licensed by the developer (e.g. not part of a game publishing platform). Each game must be downloaded directly from the App Store, must be designed to avoid duplicate payment by a subscriber, and should not disadvantage non-subscriber customers.
Subscriptions must work on all of the user’s devices where the app is available. Learn more about sharing a subscription across your apps.
Cryptocurrency Guidelines have been expanded, noting that apps for transmitting cryptocurrencies must comply with state and local law and that ICOs, futures trading, and similar transactions may only be conducted by banks, securities firms, and similar financial institutions:
3.1.5 (b) Cryptocurrencies: Apps may facilitate transmission of approved virtual currencies (e.g. Bitcoin, DogeCoin) provided that they do so in compliance with all state and federal laws for the territories in which the app functions. Apps facilitating Initial Coin Offerings (“ICOs”), cryptocurrency futures trading, and other crypto-securities or quasi-securities trading must come from established banks, securities firms, futures commission merchants (“FCM”), or other approved financial institutions and must comply with all applicable law.
More broadly, financial trading, investing, and money management apps must come from the institutions offering those services or use public APIs offered by them, and apps that facilitate the trading of certain financial products must be properly licensed:
3.2 Other Business Model Issues
3.2.1 Acceptable
(viii) Apps used for financial trading, investing, or money management should come from the financial institution performing such services or must use a public API offered by the institution in compliance with its Terms & Conditions.3.2.2 Unacceptable
Apps that facilitate trading in contracts for difference (“CFDs”) or other derivatives (e.g. FOREX) must be properly licensed in all jurisdictions where the service is available.
It seems Apple has already seen its fill of apps that are little more than an ARKit tech demo, requiring that such apps do more than drop a model into an AR view:
4.2 Minimum Functionality
4.2.1 Apps using ARKit should provide rich and integrated augmented reality experiences; merely dropping a model into an AR view or replaying animation is not enough.
The Guidelines have been amended to elaborate on the use of template apps too. In recent weeks, the app rejections for violations of the rule caught small business like restaurants off guard. The new section provides that it’s permissible to use app generation services as long as the app is submitted by the owner of the app’s content:
4.2.6 Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app’s content. These services should not submit apps on behalf of their clients and should offer tools that let their clients create customized, innovative apps that provide unique customer experiences. Another acceptable option for template providers is to create a single binary to host all client content in an aggregated or “picker” model, for example as a restaurant finder app with separate customized entries or pages for each client restaurant, or as an event app with separate entries for each client event.
Finally, in the aftermath of Apple’s removal of some VPN apps from China’s App Store, the Guidelines now state in the guidelines that VPNs must comply with local laws:
5.4 VPN Apps
Apps offering VPN services must utilize the NEVPNManager API and must make a clear declaration of what user data will be collected and how it will be used. VPN apps must not violate local laws, and if you choose to make your VPN app available in a territory that requires a VPN license, you must provide your license information in the App Review Notes field.
Maybe it’s the lawyer in me, but I’ve always found the evolution of the App Store Review Guidelines fascinating. Each rule is a direct reflection of changes in Apple’s APIs, developers’ attempts to use them in unique and unforeseen ways, and the inevitable unintended consequences of both.
