Powered by

We will never spam you or give your email to others.

June 04, 2018

Changes after WWDC 2018

After the keynote of the World Wide Developers Conference 2018, Apple updated the App Store Review Guidelines with a bunch of changes and new rules. It is clear that the theme of this update is user privacy and data protection. You can check out all the additions (marked with green) and removals (marked with red) below, but a few noteworthy changes include:

  • Apps now must clearly describe new features and changes in the “What’s New” section of the App Store. Several of the large social network companies have been using a practice where they reuse a generic update text for every release and then enable new features remotely on a per-user basis. This appears to no longer be permitted.
  • Developers are now allowed to provide time based free trials for non-subscription apps.
  • Several new rules for apps dealing with cryptocurrencies. Apps are not allowed to mine coins, but in return cryptocurrencies no longer need to be “approved”.
  • New rules for apps and games with advertising. Users now must be able to see all information used to target an ad without leaving the app.
  • New rules for apps that enable Remote Desktop access.
  • Emojis are back! Section 4.5.6 says that it is ok to use Unicode characters that render as Apple emojis inside apps and app metadata.
  • All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app
  • Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that include the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos.
  • Apps that enable sign in using a 3rd party social network must also include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app.
  • There is a new Developer Code of Conduct section.

Check out all the changes yourself below.

Introduction

  • The guiding principle of the App Store is simple - we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful. We have updated the App Review Guidelines with that principle in mind. The On the following pages you will find guidelines themselves haven’t changed, but they are better organized and provide more context. On the following pages you will find guidelines arranged into five clear sections: Safety, Performance, Business, Design, and Legal. A few other points to keep in mind:

    • You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully.

    We hope these new guidelines help you sail through the App Review process, and that approvals and rejections are more remain consistent across the board. This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this. We love this stuff too, and honor what you do. We're We’re really trying our best to create the best platform in the world for you to express your talents and make a living, too.

  • 1.5 Developer Information

    People need to know how to reach you with questions and support issues. Make sure your app and its Support URL includes include an easy way to reach contact you ; this is particularly important for apps that may be used in the classroom. Failure to include accurate and up-to-date contact information not only frustrates customers, but may violate the law in some countries. Also ensure that Wallet passes include valid contact information from the issuer and are signed with a dedicated certificate assigned to the brand or trademark owner of the pass.

  • 1.6 Data Security

    Apps should implement appropriate security measures to ensure proper handling of user information collected pursuant to the Apple Developer Program License Agreement and these Guidelines (see Guideline 5.1 for more information) and prevent its unauthorized use, disclosure, or access by third parties.

  • 2.3 Accurate Metadata
    • 2.3.6 Answer the age rating questions in iTunes App Store Connect honestly so that your app aligns properly with parental controls. If your app is mis-rated, customers might be surprised by what they get, or it could trigger an inquiry from government regulators. If your app includes media that requires the display of content ratings or warnings (e.g. films, music, games, etc.), you are responsible for complying with local requirements in each territory where your app is available.
    • 2.3.12 Apps must clearly describe new features and product changes in their “What’s New” text. Simple bug fixes, security updates, and performance improvements may rely on a generic description, but more significant changes must be listed in the notes.
  • 2.4 Hardware Compatibility
    • 2.4.2 Design your app to use power efficiently. Apps should not rapidly drain battery, generate excessive heat, or put unnecessary strain on device resources. Apps, including any third party advertisements displayed within them, may not run unrelated background processes, such as cryptocurrency mining.
    • 2.4.4 Apps should never suggest or require a restart of the device or modifications to system settings unrelated to the core functionality of the application. For example, don’t encourage users to turn off Wi-Fi, disable security features, etc.
    • 2.5 Software Requirements
      • 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.
      • 2.5.11 SiriKit and Shortcuts
        • (i) Apps integrating SiriKit and Shortcuts should only sign up for intents they can handle without the support of an additional app and that users would expect from the stated functionality. For example, if your app is a meal planning app, you should not incorporate an intent to start a workout, even if the app shares integration with a fitness app.
        • (ii) Ensure that the vocabulary and phrases in your plist pertains to your app and the SiriKit Siri functionality of the intents the app has registered for. Aliases must relate directly to your app or company name and should not be generic terms or include third party app names or services.
        • (iii) Resolve the Siri request or Shortcut in the most direct way possible and do not insert ads or other marketing between the request and its fulfillment. Only present interstitial UI request a disambiguation when required to complete the task (e.g. asking the user to specify a particular type of workout).
      • 2.5.13 Apps using facial recognition for account authentication must use LocalAuthentication (and not ARKit or other facial recognition technology) where possible, and must use an alternate authentication method for users under 13 years old.
      • 2.5.14 Apps must request explicit user consent and provide a clear visual indication when recording, logging, or otherwise making a record of user activity. This includes any use of the device camera, microphone, or other user inputs.
      • 2.5.15 Apps that enable users to view and select files should include items from the Files app and the user’s iCloud documents.
    • 3.1 Payments
      • 3.1.1 In-App Purchase:
        • If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps and their metadata may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than in-app purchase.
        • Apps may use in-app purchase currencies to enable customers to “tip” digital content providers in the app.
        • Non-subscription apps may offer a free time-based trial period before presenting a full unlock option by setting up a Non-Consumable IAP item at Price Tier 0 that follows the naming convention: “XX-day Trial.” Prior to the start of the trial, your app must clearly identify its duration, the content or services that will no longer be accessible when the trial ends, and any downstream charges the user would need to pay for full functionality. Learn more about managing content access and the duration of the trial period using Receipts and Device Check .
      • 3.1.2(a) Permissible uses:
          Auto-renewing subscription apps may offer a free trial period to customers by providing the relevant information set forth in App Store Connect. Apps that attempt to trick users into purchasing a subscription under false pretenses or engage in bait-and-switch practices will be removed from the App Store and you may be removed from the Apple Developer Program. Learn more about Subscription Free Trials .
      • 3.1.3 (a) “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as educational classroom management apps that manage student grades and schedules), as well as provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are not designed to discourage use of in-app purchase.
      • 3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided that you agree not to directly or indirectly target iOS users to use a purchasing method other than those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods are must not designed to discourage use of in-app purchase.
      • 3.1.4 Content Codes: Hardware-Specific Content: Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, etc. In limited circumstances, such as when features are dependent upon specific hardware to function, the app may unlock that functionality without using in-app purchase (e.g. an astronomy app that adds features when synced with a telescope). App features that work in combination with an approved physical product (such as a toy) on an optional basis may unlock functionality without using in-app purchase, provided that an in-app purchase option is available as well. You may not, however, require users to purchase unrelated products or engage in advertising or marketing activities to unlock app functionality.
      • 3.1.5 (a) Physical Goods and Services Outside of the App: If your app enables people to purchase goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry.
      • 3.1.5 (b) Cryptocurrencies:
        • (i) Wallets: Apps may facilitate transmission of approved virtual currencies currency storage, provided they are offered by developers enrolled as an organization.
        • (ii) Mining: Apps may not mine for cryptocurrencies unless the processing is performed off device (e.g. Bitcoin cloud-based mining).
        • (iii) Exchanges: Apps may facilitate transactions or transmissions of cryptocurrency on an approved exchange , DogeCoin provided they are offered by the exchange itself.
        • (iv) provided that they do so in compliance with all state and federal laws for the territories in which the app functions. Initial Coin Offerings: 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.
        • (v) Cryptocurrency apps may not offer currency for completing tasks, such as downloading other apps, encouraging other users to download, posting to social networks, etc.
      • 3.1.7 Advertising: Ads displayed in an app must be appropriate for the app’s age rating, allow the user to see all information used to target them for that ad (without requiring the user to leave the app), and may not engage in targeted or behavioral advertising based on sensitive user data such as health/medical data (e.g. from the HealthKit APIs), school and classroom data (e.g. from ClassKit), or from kids (e.g. from apps in the Kids Category), etc. Interstitial ads or ads that interrupt or block the user experience must clearly indicate that they are an ad, must not manipulate or trick users into tapping into them, and must provide easily accessible and visible close/skip buttons large enough for people to easily dismiss the ad.
    • 3.2 Other Business Model Issues
      • 3.2.2 Unacceptable
        • (ix) Apps must not force users to rate the app, review the app, download other apps, or perform other similar actions in order to access functionality, content, or use of the app.
    • 4.2 Minimum Functionality
      • 4.2.3
        • (i) Your app should work on its own without requiring installation of another app to function.
        • (ii) Make sure you include sufficient content in the binary for the app to function at launch.
        • (iii) If your app needs to download additional resources, disclose the size of the download and prompt users before doing so. Existing apps must comply with this guideline in any update submitted after January 1, 2019.
      • 4.2.7 Remote Application Mirroring: If your remote desktop app acts as a mirror of specific software or services rather than a generic mirror of the host device, it must comply with the following:
        • (a) The host device is a personal computer owned by the user, and both the host and client must be connected on a local and LAN-based network.
        • (b) Any software or services appearing in the client are fully rendered on the screen of the host device, and may not use APIs or platform features beyond what is required to stream the Remote Desktop
        • (c) All account creation and management must be initiated from the host device.
        • (d) The UI appearing on the client does not resemble an iOS or App Store view, does not provide a store-like interface, or include the ability to browse, select, or purchase software not already owned or licensed by the user. For the sake of clarity, transactions taking place within mirrored software do not need to use in-app purchase, provided the transactions are processed on the host device.
    • 4.5 Apple Sites and Services
      • 4.5.4 Push Notifications must not be required for the app to function, and should not be used for advertising, promotions, or direct marketing purposes or to send sensitive personal or confidential information. Abuse of these services may result in revocation of your privileges.
      • 4.5.6 Apps may use Unicode characters that render as Apple emojis in their app and app metadata. Apple emojis may not be used on other platforms or embedded directly in your app binary.
    • 4.7 HTML5 Games, Bots, etc.

      Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view; your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; and (4) adheres to the terms of these App Review Guidelines (e.g. it must open and run natively in Safari without modifications or additional software); your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; and (4) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content). YouUpon request, you must provide an index of software and metadata available in your app upon request. It must include Apple Developer Program Team IDs for the providers of the software along with a URL which App Review can use to confirm that the software complies with the requirements above.

    • 5.1 Privacy
      • 5.1.1 Data Collection and Storage
        • (i) Privacy Policies: All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner. The privacy policy must clearly and explicitly:
          • Identify what data, if any, the app/service collects, how it collects that data, and all uses of that data.
          • Confirm that any third party with whom an app shares user data (in compliance with these Guidelines) — such as analytics tools, advertising networks and third party SDKs, as well as any parent, subsidiary or other related entities that will have access to user data — will provide the same or equal protection of user data as stated in the app’s privacy policy and required by these Guidelines.
          • Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.
        • (ii) Permission Apps that collect user or usage data must have a privacy policy and secure user consent for the collection. This includes—but isn’t limited to—apps that implement HealthKit or other health/medical technologiesPaid functionality must not be dependent on or require a user to grant access to this data. Apps must also provide the customer with an easily accessible and understandable way to withdraw consent. Ensure your purpose strings clearly and completely describe your use of the data. Apps that collect data for a legitimate interest without consent by relying on the terms of the European Union’s General Data Protection Regulation (“GDPR”) or similar statute must comply with all terms of that law. Learn more about Requesting Permission.
        • (iii) Data Minimization: Apps should only request access to data relevant to the core functionality of the app and should only collect and use data that is required to accomplish the relevant task. Where possible, use the out-of-process picker or a share sheet rather than requesting full access to protected resources like Photos or Contacts.
        • (iv) Access Apps must respect the user’s permission settings and not attempt to manipulate, trick, or force people to consent to unnecessary data access. For example, apps that utilize ARKitinclude the ability to post photos to a social network must not also require microphone access before allowing the user to upload photos. Where possible, Camera APIsprovide alternative solutions for users who don’t grant consent. For example, Photo APIsif a user declines to share Location, or other software for depth of facial mappingoffer the ability to manually enter an address.
        • (v) Account Sign-In: If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, HomeKit, Keyboard extensions, Apple Pay, Stickers and iMessage extensions, include a login, or access user data from the deviceexcept when directly relevant to the core functionality of the app or required by law. YourIf your core app description should let people know what types of accessfunctionality is not related to a specific social network (e.g. location, contacts, calendar, etc.) are requested by your app, and what aspects of the app won’t work if the user doesn’t grant permission. (ii) If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core app functionality is not related to a specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.), you must provide access without a login or via another mechanism. Pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality. The app must also include a mechanism to revoke social network credentials and disable data access between the app and social network from within the app. An app may not store credentials or tokens to social networks off of the device and may only use such credentials or tokens to directly connect to the social network from the app itself while the app is in use.
        • (iiivi) Developers that use their apps to surreptitiously discover passwords or other private data will be removed from the Developer Program.
        • (ivvii) SafariViewContoller must be used to visibly present information to users; the controller may not be hidden or obscured by other views or layers. Additionally, an app may not use SafariViewController to track users without their knowledge and consent.
      • 5.1.2 Data Use and Sharing
        • (i) Unless otherwise permitted by law, you may not use, transmit, or share someone’s personal data without first obtaining their permission. You must provide access to information about how and where the data will be used. Data collected from apps may only be shared with third parties to improve the app or serve advertising (in compliance with the Apple Developer Program License Agreement.). Apps that share user data without user consent or otherwise complying with data privacy laws may be removed from sale and may result in your removal from the Apple Developer Program.
        • (ii) Data collected for one purpose may not be repurposed without further consent unless otherwise explicitly permitted by law.
        • (iii) Apps should not attempt to surreptitiously build a user profile based on collected data and may not attempt, facilitate, or encourage others to identify anonymous users or reconstruct user profiles based on data collected from depth andApple-provided APIs or any data that you say has been collected in an “anonymized,” “aggregated,” or otherwise non-identifiable way.
        • (iv) Do not use information from Contacts, Photos, or other APIs that access user data to build a contact database for your own use or for sale/or facial mapping toolsdistribution to third parties, and don’t collect information about which other apps are installed on a user’s device for the purposes of analytics or advertising/marketing.
        • (v) Do not contact people using information collected via a user’s Contacts or Photos, except at the explicit initiative of that user on an individualized basis; do not include a Select All option or default the selection of all contacts. You must provide the user with a clear description of how the message will appear to the recipient before sending it (e.g. ARKit, Camera APIs, or Photo APIsWhat will the message say? Who will appear to be the sender?), or data that you say has been collected in an “anonymized,” “aggregated,” or otherwise non-identifiable way. You may not use or transmit someone’s personal data without first obtaining their permission and providing access to information about how and where the data will be used.
        • (iivi) Data collected from apps may not be used or shared with third parties for purposes unrelated to improving the user experience or softwaregathered from the HomeKit API, HealthKit, Consumer Health Records API, MovementDisorder APIs, ClassKit or from depth and/hardware performance connected to the app’s functionality, or to serve advertising in compliance with the Apple Developer Program License Agreement. (iii) Data gathered from the HomeKit API or from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs) may not be used for marketing, advertising or other use-based data mining, including by third parties. Learn more about best practices for implementing CallKit, HealthKit, ClassKit, and ARKit.
        • (ivvii) Apps using Apple Pay may only share user data acquired via Apple Pay with third parties to facilitate or improve delivery of goods and services.
      • 5.1.4 Kids

        For many reasons, it is critical to use care when dealing with personal data from kids, and we encourage you to carefully review all the requirements for complying with laws like the Children’s Online Privacy Protection Act (“COPPA”), the European Union’s General Data Protection Regulation (“GDPR”), and any international or local equivalents.

    • 5.4 VPN Apps

      Apps offering VPN services must utilize the NEVPNManager API API andand may only be offered by developers enrolled as an organization. You 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.

    • 5.5 Developer Code of Conduct

      Please treat everyone with respect, whether in your responses to App Store reviews, customer support requests, or when communicating with Apple, including your responses in Resolution Center. Do not engage in harassment of any kind, discriminatory practices, intimidation, bullying, and don’t encourage others to engage in any of the above.

      Customer trust is the cornerstone of the App Store’s success. Apps should never prey on users or attempt to rip-off customers, trick them into making unwanted purchases, force them to share unnecessary data, raise prices in a tricky manner, charge for features or content that are not delivered, or engage in any other manipulative practices within or outside of the app.

    December 21, 2017

    Crypto currencies and ICOs, template apps, loot boxes and more

    Wednesday the App Store Review Guidelines was updated with quite a few changes. Besides some minor clarifications, new sections were introduced about:

    • Crypto currencies and ICOs now have a dedicated section.
    • The ban on template apps is clarified so its now more clear exactly what kinds of apps are affected. Techcrunch spotted this change too.
    • There is a few paragraphs on apps available for pre-order.
    • Details about what is allowed when offering so-called “loot boxes” in games.
    • Financial apps must come from the financial institutions performing the services or they should at least use public APIs.
    • A new section on VPN apps details some rules specific to this app type.

    Check out all the changes below.

    Introduction

    • 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.
    • 2.1 App Completeness

      Submissions to App Review , including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission. Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login. If you offer in-app purchases in your app, make sure they are complete, up-to-date, and visible to the reviewer, or that you explain why not in your review notes. Please don’t treat App Review as a software testing service. We will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems.

    • 2.3 Accurate Metadata
      • 2.3.2 If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases. If you decide to promote in-app purchases on the App Store, ensure that the in-app purchase Display Name, Screenshot and Description are appropriate for a public audience , that you follow the guidance found in Promoting Your In-App Purchases , and that your app properly handles the SKPaymentTransactionObserver method so that customers can seamlessly complete the purchase when your app launches.
      • 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.
    • 2.5 Software Requirements
      • 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.
    • 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.
        • 3.1.2(a) Permissible uses:
          • 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. Subscriptions Games offered in a game subscription must work on all of the user’s devices where the app is available. Learn more about sharing a subscription across your apps . Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app. As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc. Subscriptions may not include consumable credits, gems, in-game currencies, etc., even when combined with other offerings, but you may offer subscriptions that include access to discounted consumable goods 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 .
          • Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.
          • As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc.
          • Subscriptions may include consumable credits, gems, in-game currencies, etc., and you may offer subscriptions that include access to discounted consumable goods (e.g. a platinum membership that exposes gem-packs for a reduced price).
        • 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.
      • 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
          • (viii) Apps that facilitate binary options trading are not permitted on the App Store. Consider a web app instead. 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.
      • 4.2 Minimum Functionality
        • 4.2.1 Apps using ARKit 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. 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.
        • 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.
      • 4.4 Extensions
        • 4.4.1 Keyboard extensions have some additional rules.

          They must:

          • Remain functional without full network access and without requiring full access; Provide Number and Decimal keyboard types as described in the App Extension Programming Guide ;
      • 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.

      September 15, 2017

      New guidelines for Face ID, ARKit, privacy policies and more.

      With the imminent release of iOS 11 and the announcement of the iPhone X with Face ID it was only natural for Apple to update the App Store Review Guidelines. But this update is actually rather big and includes many changes that does not relate to the new products as such.

      A few notable changes and additions that caught my mind:

      • Don’t market your app with features or content it does not have (such as claimed “virus scanners”)
      • You must support in-app purchases initiated from the App Store
      • Facial recognition for authentication must be implemented using the official Apple API.
      • Apps may facilitate peer-to-peer payments and are not required to use in-app purchases for such payments as long as no digital content or services are offered in exchange for rhe payment.
      • “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.”
      • Section 4.7 changes some wording in the context of downloading and running 3rd party code from an app.
      • The list of app types that must include a privacy policy has been extended to also include “apps that utilize ARKit, Camera APIs, Photo APIs, or other software for depth of facial mapping information”. So if your app falls into this category make sure you have the privacy policy in place and save yourself for a rejection.
      • Data gathered from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs) may not be used for advertising or other use-based data mining
      • Don’t visualize activity data in a way that resembles the Activity Rings in Activity control
      • IAP renamed to in-app purchases everywhere (not all cases included in the diff below)
      • Some typos were fixed (not all included in the diff below)
      • Various other changes; Check the details below.

      • 1.1 Objectionable Content
        • 1.1.1 Defamatory , discriminatory, or mean-spirited content, including references or commentary about religion, race, sexual orientation, gender, national/ethnic origin, or other targeted groups, particularly if the app is likely to humiliate, intimidate, or place a targeted individual or group in harm’s way. Professional political satirists and humorists are generally exempt from this requirement.
      • 2.3 Accurate Metadata
        • 2.3.1 Don’t include any hidden or undocumented features in your app; your app’s functionality should be clear to end-users and App Review. Similarly, you should not market your app on the App Store or offline as including content or services that it does not actually offer (e.g. iOS-based virus and malware scanners). Egregious or repeated behavior is grounds for removal from the Developer Program. We work hard to make the App Store a trustworthy ecosystem and expect our app developers to follow suit; if you’re dishonest, we don’t want to do business with you.
        • 2.3.2 If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases. If you decide to promote in-app purchases on the App Store, ensure that the IAPin-app purchase Display Name, Screenshot and Description are writtenappropriate for a public audience and that your app properly handles the Purchase Intent APISKPaymentTransactionObserver method so that customers can seamlessly complete the purchase when your app launches.
        • 2.3.3 Screenshots should show the app in use, and not merely the title art, log-in page, or splash screen. They may also include text and image overlays (e.g. to demonstrate input mechanisms, such as an animated touch point or Apple Pencil) and show extended functionality on device, such as Touch Bar.
      • 2.5 Software Requirements
        • 2.5.13 Apps using facial recognition for account authentication must use LocalAuthentication (and not ARKit or other facial recognition technology), and must use an alternate authentication method for users under 13 years old.
      • 3.2 Other Business Model Issues
        • 3.2.1 Acceptable
          • (vii) Apps may enable individual users to give a monetary gift to another individual without using in-app purchase, provided that (a) the gift is a completely optional choice by the giver, and (b) 100% of the funds go to the receiver of the gift. However, a gift that is connected to or associated at any point in time with receiving digital content or services must use in-app purchase.
      • 4.2 Minimum Functionality
        • 4.2.1 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. 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.
      • 4.7 Third-Party Software HTML5 Games, Bots, etc.

        Apps may contain or run code provided by third party developersthat is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as the code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view; your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; and (4) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content; uses IAPin-app purchase to unlock features and functionality). You must provide an index of third party software and metadata available in your app upon request.

      • Apps must comply with all legal requirements in any location where you make them available (if you’re not sure, check with a lawyer). We know this stuff is complicated, but it is your responsibility to understand and make sure your app conforms with all local laws, not just the guidelines below. And of course, apps that solicit, promote, or encourage criminal or clearly reckless behavior will be rejected. In extreme cases, such as apps that are found to facilitate human trafficking and/or the exploitation of children, appropriate authorities will be notified.

        • 5.1 Privacy

          Protecting user privacy is paramount in the Apple ecosystem, and you should use care when handling personal data to ensure you’ve complied with applicable laws and the terms of the Apple Developer Program License Agreement, not to mention customer expectations. More particularly:

          • 5.1.1 Data Collection and Storage
            • (i) Apps that collect user or usage data must have a privacy policy and secure user consent for the collection. This includes—but isn’t limited to—apps that implement HealthKit or other health/medical technologies, apps that utilize ARKit, Camera APIs, Photo APIs, or other software for depth of facial mapping information, HomeKit, Keyboard extensions, Apple Pay, Stickers and iMessage extensions, include a login, or access user data from the device. Your app description should let people know what types of access (e.g. location, contacts, calendar, etc.) are requested by your app, and what aspects of the app won’t work if the user doesn’t grant permission.
          • 5.1.2 Data Use and Sharing
            • (i) You may not attempt, facilitate, or encourage others to identify anonymous users or reconstruct user profiles based on data collected from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs), or data that you say has been collected in an “anonymized,” “aggregated,” or otherwise non-identifiable way. You may not use or transmit someone’s personal data without first obtaining their permission and providing access to information about how and where the data will be used.
            • (iii) Data gathered from the HomeKit API or from depth and/or facial mapping tools (e.g. ARKit, Camera APIs, or Photo APIs) may not be used for advertising or other use-based data mining, including by third parties.
        • 5.2 Intellectual Property
          • 5.2.5 Apple Products: Don’t create an app that appears confusingly similar to an existing Apple product, interface (e.g. Finder), app (such as the App Store, iTunes Store, or Messages) or advertising theme, and don’t misspell Apple product names (i.e., GPS for Iphone, iTunz). Apps and extensions, including third party keyboards and Sticker packs, may not include Apple emoji. iTunes music previews may not be used for their entertainment value (e.g. as the background music to a photo collage or the soundtrack to a game) or in any other unauthorized manner. If your app displays Activity rings, dothey should not modify the look and feel of the rings themselves or thevisualize Move, Exercise, or Stand data they representin a way that resembles the Activity control. The Human Interface Guidelines have more information on how to use Activity rings.

      June 08, 2017

      New rules following WWDC 2017

      After a densely packed WWDC keynote with many new features for developers and user, Apple also published a new version of the App Store Review Guidelines. There are many changes ranging from minor rephrasings to totally new rules.

      A few notable changes and additions that caught my mind:

      • New note on how to respond to App Store customer reviews.
      • Note saying developers must now use the provided API to prompt users for reviews rather than link to the App Store page from a custom prompt.
      • App names can now only be 30 characters long. Previosly this limit was 50 characters. There is a new subtitle feature in iTunes Connect that we should use instead of long descriptive titles.
      • Apps that provide a programming interface may now (in some cases) download and run code from the Internet.
      • Clarifications regarding IAP and other purchasing methods for “reader” apps.
      • Binary options trading apps are no longer allowed.
      • Apps created from a commercialized template or app generation service will be rejected.
      • Your app description should let people know what types of access (e.g. location, contacts, calendar, etc.) are requested by your app, and what aspects of the app won’t work if the user doesn’t grant permission.

      All the changes are listed below. Additions have green highlight and deletions have red highlight and strikeout.

      • Introduction
        • The App Store is a great way to reach hundreds of millions of people around the world. If you build an app that you just want to show to family and friends, the App Store isn’t the best way to do that. Consider Ad Hoc distribution or the Enterprise Program. If you’re just getting started, learn more about the Apple Developer Program.
        • If your app looks like it was cobbled together in a few days, or you're trying to get your first practice app into the store to impress your friends, please brace yourself for rejection. We have lots of serious developers who don't want their quality apps to be surrounded by amateur hour. 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. If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer's work, or manipulate ratings) your apps will be removed from the store and you will be expelled from the Developer Program.
      • Before you submit

        To help your app approval go as smoothly as possible, review the common missteps listed below that can slow down the review process or trigger a rejection. This doesn’t replace the guidelines or guarantee approval, but making sure you can check every item on the list is a good start. If your app no longer functions as intended or you’re no longer actively supporting it, it will be removed from the App Store. Learn More about App Store Improvements.

      • 1.1 Objectionable Content
        • 1.1.7 App Store Reviews:
          • App Store customer reviews can be an integral part of the app experience, so you should treat customers with respect when responding to their comments. Keep your responses targeted to the user’s comments and do not include personal information, spam, or marketing in your response.
          • Use the provided API to prompt users to review your app; this functionality allows customers to provide an App Store rating and review without the inconvenience of leaving your app, and we will disallow custom review prompts.
      • 1.4 Physical Harm

        If your app behaves in a way that risks physical harm, we may reject it. For example:

        • 1.4.1 Medical apps that could provide inaccurate data or information, or that could be used for diagnosing or treating patients may be reviewed with greater scrutiny. If your medical app has received regulatory clearance, please submit a link to that documentation with your app.
          • Apps must clearly disclose data and methodology to support accuracy claims relating to health measurements, and if the level of accuracy or methodology cannot be validated, we will reject your app. For example, apps that claim to take x-rays, measure blood pressure, body temperature, blood glucose levels, or blood oxygen levels using only the sensors on the device are not permitted.
          • Apps should remind users to check with a doctor in addition to using the app and before making medical decisions.
          If your medical app has received regulatory clearance, please submit a link to that documentation with your app.
        • 1.4.3 Apps should notthat encourage consumption of tobacco products, illegal or excessive consumption of drugs or alcohol; or encourage minors to consume drugs, or excessive amounts of alcohol are not permitted on the App Store. Apps that encourage minors to consume any of these substances will be rejected. Facilitating the sale of marijuana, or tobacco; and facilitating the sale of marijuana, or controlled substances (except for licensed pharmacies) isn’t allowed.
        • 1.4.5 Apps should not urge customers to use their devices in a way that contradicts safety documentation for Apple hardware, risking damage to the device or physical harm to people. For example, apps should not encourage placing the device under a mattress or pillow while charging or perform excessive write cycles to the solid state drive. Review device documentation.
      • 2.3 Accurate Metadata
        • 2.3.2 If your app includes in-app purchases, make sure your app description, screenshots, and previews clearly indicate whether any featured items, levels, subscriptions, etc. require additional purchases. If you decide to promote in-app purchases on the App Store, ensure that the IAP Display Name and Description are written for a public audience and that your app properly handles the Purchase Intent API so that customers can seamlessly complete the purchase when your app launches.
        • 2.3.3 Screenshots should show the app in use, and not merely the title art, log-in page, or splash screen. They may also include text overlays and show extended functionality on device, such as Touch Bar.
        • 2.3.7 Choose a unique app name, assign keywords that accurately describe your app, and don’t try to pack any of your metadata with trademarked terms, popular app names, or other irrelevant phrases just to game the system. App names must be limited to 5030 characters and should not include prices, terms, or descriptions that are not the name of the app. App subtitles are a great way to provide additional context for your app; they must follow our standard metadata rules and should not include inappropriate content, reference other apps, or make unverifiable product claims. Apple may modify inappropriate keywords at any time.
        • 2.3.8 Metadata should be appropriate for all audiences, so make sure your app and in-app purchase icons, screenshots, and previews adhere to a 4+ age rating even if your app is rated higher. For example, if your app is a game that includes violence, select images that don’t depict a gruesome death or a gun pointed at a specific character. Use of terms like “For Kids” and “For Children” in app names is reserved for the Kids Category. Remember to ensure your metadata, including app name and icons (small, large, Apple Watch app, etc.), are similar to avoid creating confusion.
      • 2.5 Software Requirements
        • 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.
        • 2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other iOS, watchOS, macOS, or tvOS apps. Apps designed to teach, develop, or test executable code may, in limited circumstances, download code provided that such code is not used for other purposes. Such apps must make the source code provided by the Application completely viewable and editable by the user.
        • 2.5.9 Apps that alter or disable the functions of standard switches, such as the Volume Up/Down and Ring/Silent switches, or other native user interface elements or behaviors will be rejected. For example, apps should not block links out to other apps or other features that users would expect to work a certain way. Learn more about proper handling of links.
        • 2.5.11 SiriKit
          • (ii) Ensure that the vocabulary and phrases in your plist pertains to your app and the SiriKit functionality of the intents the app has registered for. Aliases must relate directly to your app or company name and should not be generic terms or include third party app names or services.
        • 2.5.12 Apps using CallKit or including an SMS Fraud Extension should only block phone numbers that are confirmed spam. Apps that include call-, SMS-, and MMS- blocking functionality or spam identification must clearly identify these features in their marketing text and explain the criteria for their blocked and spam lists. You may not use the data accessed via these tools for any purpose not directly related to operating or improving your app or extension (e.g. you may not use, share, or sell it for tracking purposes, creating user profiles, etc.)
      • 3.1 Payments
        • 3.1.1 In-App Purchase:
          • If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may use in-app purchase currencies to enable customers to “tip” digital content providers in the app. Apps may not include buttons, external links, or other calls to action that direct customers to purchasing mechanisms other than IAP.
          • Any credits or in-game currencies purchased via IAP must be consumed within the app and may not expire, and you should make sure you have a restore mechanism for any restorable in-app purchases.
        • 3.1.2(a) Permissible uses: If you offer an auto-renewing subscription, you must provide ongoing value to the customer, and the subscription period must last at least seven days and be available across all of the user’s devices.
        • 3.1.3 Content-based “Reader” Apps: Apps may allow a user to access previously purchased content or content subscriptions (specifically: magazines, newspapers, books, audio, music, video, access to professional databases, VoIP, cloud storage, and approved services such as educational apps that manage student grades and schedules), as well as consumable items in multi-platform games, provided the app doesthat you agree not directto directly or indirectly target iOS users to use a purchasing mechanismmethod other than IAP, and your general communications about other purchasing methods are not designed to discourage use of IAP.
      • 3.2 Other Business Model Issues
        • 3.2.1 Acceptable
          • (vi) Approved nonprofits may fundraise directly within their own apps usingor third-party apps, provided those fundraising campaigns adhere to all App Review Guidelines and offer Apple Pay, provided those fundraising campaigns adhere to all App Review Guidelines support. These apps must disclose how the funds will be used, abide by all required local and federal laws, and makeensure appropriate tax receipts are available to donors. Additional information shall be provided to App Review upon request. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
        • 3.2.2 Unacceptable
          • (iv) Unless you are an approved nonprofit or otherwise permitted under Section 3.2.1 (vi) above, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
          • (vi) Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc. Apps should not forcerequire users to rate the app, review the app, watch videos, download other apps, tap on advertisements, or take other similar actions in order to access functionality, content, or use of the app, or receive monetary or other compensation.
          • (vii) Artificially manipulating a user’s visibility, status, or rank on other services unless permitted by that service’s Terms and Conditions
          • (viii) Apps that facilitate binary options trading are not permitted on the App Store. Consider a web app instead.
      • 4.2 Minimum Functionality
        • 4.2.2 Other than catalogs, which have a dedicated category, apps shouldn’t primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.
        • 4.2.6 Apps created from a commercialized template or app generation service will be rejected.
      • 4.4 Extensions
        • 4.4.1 Keyboard extensions have some additional rules.

          They must:

          • Follow Sticker guidelines if the keyboard includes images or emojis
          • Remain functional without full network access and without requiring full access;
      • 4.5 Apple Sites and Services
        • 4.5.2 The Apple Music API lets
          • (i) The MusicKit APIs let customers access their subscription while using your app. They are intended for simple music playback by Apple Music subscribers. Users must initiate the playback of an Apple Music stream and be able to navigate playback using standard media controls such as “play,” “pause,” and “skip;. apps may not automate these actions. Moreover, your app may not require payment or indirectly monetize access to the Apple Music service (e.g. in-app purchase, advertising, requesting user info, etc.). Do not download, upload, or enable sharing of music files sourced from the MusicKit APIs, except as explicitly permitted in MusicKit documentation.
          • (ii) Using the MusicKit APIs is not a replacement for securing the licenses you might need for a deeper or more complex music integration. For example, if you want your app to play a specific song at a particular moment, or to create audio or video files that can be shared to social media, you’ll need to contact rights-holders directly to get their permission (e.g. synchronization or adaptation rights) and assets. Cover art and other metadata may only be used in connection with music playback or playlists (including App Store screenshots displaying your app’s functionality), and should not be used in any marketing or advertising without getting specific authorization from rights-holders. Make sure to follow the Apple Music Identity Guidelines when integrating Apple Music services in your app.
          • (iii) Apps that access Apple Music user data, such as playlists and favorites, must clearly disclose this access in the purpose string. Any data collected may not be shared with third parties for any purpose other than supporting or improving the app experience. This data may not be used to identify users or devices, or to target advertising.
      • 4.6 Alternate App Icons

        Apps may display customized icons, for example, to reflect a sports team preference, provided that each change is initiated by the user and the app includes settings to revert to the original icon. All icon variants must relate to the content of the app and changes should be consistent across all system assets, so that the icons displayed in Settings, Notifications, etc. match the new springboard icon. This feature may not be used for dynamic, automatic, or serial changes, such as to reflect up-to-date weather information, calendar notifications, etc.

      • 4.7 Third-Party Software

        Apps may contain or run code provided by third party developers (e.g. HTML5-based games), as long as the code is not offered in a store or store-like interface, and provided that the software (1) is free or purchased using in-app purchase; (2) only uses capabilities available in a standard WebKit view; your app must use WebKit and JavaScript Core to run third party software and should not attempt to extend or expose native platform APIs to third party software; (3) is offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; and (4) adheres to the terms of these App Review Guidelines (e.g. does not include objectionable content; uses IAP to unlock features and functionality). You must provide an index of third party software and metadata available in your app upon request.

      • 5.1 Privacy
        • 5.1.1 Data Collection and Storage
          • (i) Apps that collect user or usage data must have a privacy policy and secure user consent for the collection. This includes—but isn’t limited to—apps that implement HealthKit or other health/medical technologies, HomeKit, Keyboard extensions, Apple Pay, Stickers and iMessage extensions, include a login, or access user data from the device. Your app description should let people know what types of access (e.g. location, contacts, calendar, etc.) are requested by your app, and what aspects of the app won’t work if the user doesn’t grant permission.
        • 5.1.2 Data Use and Sharing
          • (i) Apps cannotYou may not attempt, facilitate, or encourage others to identify users or reconstruct user profiles based on data that you say has been collected in an “anonymized,” “aggregated,” or otherwise non-identifiable way. You may not use or transmit someone’s personal data without first obtaining their permission and providing access to information about how and where the data will be used.
      • 5.2 Intellectual Property
        • 5.2.1 Generally: Don’t use protected third party material such as trademarks, copyrighted works, or patented ideas in your app without permission, and don’t include misleading, false, or copycat representations, names, or metadata in your app bundle or developer name. Apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights and is responsible for offering any services provided by the app.
        • 5.2.5 Apple Products: Don’t create an app that appears confusingly similar to an existing Apple product, interface (e.g. Finder), app (such as the App Store, iTunes Store, or Messages) or advertising theme, and don’t misspell Apple product names (i.e., GPS for Iphone, iTunz). Apps and extensions, including third party keyboards and Sticker packs, may not include Apple emoji. iTunes music previews may not be used for their entertainment value (e.g. as the background music to a photo collage or the soundtrack to a game) or in any other unauthorized manner. If your app displays Activity rings, do not modify the look and feel of the rings themselves or the data they represent. The Human Interface Guidelines have more information on how to use Activity rings.

      November 14, 2016

      Added nonprofit payment exception

      With this minor update to the App Store Review Guidelines Apple added a subsection saying that approved nonprofits may fundraise directly within their app using Apple Pay. There is also a link to a new page about how to become an approved nonprofit.

      The change followed an official press release from Apple that details the new program allowing Apple Pay donations to nonprofits.

      This change also included Apple renaming Mac OS X to its new name macOS in several places.

    • 3.2 Other Business Model Issues
      • 3.2.1 Acceptable
        • (vi) Approved nonprofits may fundraise directly within their own apps using Apple Pay, provided those fundraising campaigns adhere to all App Review Guidelines. These apps must disclose how the funds will be used, abide by all required local and federal laws, and make appropriate tax receipts available to donors. Nonprofit platforms that connect donors to other nonprofits must ensure that every nonprofit listed in the app has also gone through the nonprofit approval process. Learn more about becoming an approved nonprofit.
      • 3.2.2 Unacceptable
        • (iv) CollectingUnless you are an approved nonprofit, collecting funds within the app for charities and fundraisers. Apps that seek to raise money for such causes must be free on the App Store and may only collect funds outside of the app, such as via Safari or SMS.
    • September 01, 2016

      Updated subscription rules, SiriKit, Stickers and more

      This update to the App Store Review Guidelines is mostly about the new iOS features SiriKit and Stickers, but also includes the previously promised new rules for subscription based apps. The full diff is listed below, but a few interesting new bits include:

      App names must be limited to 50 characters and should not include terms or descriptions that are not the name of the app.

      This was also mentioned in the “App Store Improvements” email sent to developers on September 1st and will be enforced for new apps and app updates.

      Section 3.2.2 has a new point that I think is worth to notice:

      Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc. Apps should not force users to rate the app, review the app, download other apps, or take other similar actions in order to access functionality, content, or use of the app.

      Seems to me that many apps and games currently encourage users to rate the app by offering rewards like free coins or similar for doing so. It will be interesting to see if Apple enforce this rule in a way that also prohibits this behavior where users are not forced, but gets rewarded.

      And remember that even after your app has been approved, you should update your app to ensure it remains functional and engaging to new and existing customers. Apps that stop working or offer a degraded experience may be removed from the App Store at any time.

      Yes Apple will finally start to remove abandoned apps from the App Store. This should be a win for everyone.

    • 2.3 Accurate Metadata
      • 2.3.4 Previews are a great way for customers to see what your app looks like and what it does. To ensure people understand what they’ll be getting with your app, previews may only use video screen captures of the app itself. Stickers and iMessage extensions may show the user experience in the Messages app. You can add narration and video or textual overlays to help explain anything that isn’t clear from the video alone.
      • 2.3.7 Choose a unique app name, assign keywords that accurately describe your app, and don’t try to pack any of your metadata with trademarked terms, popular app names, or other irrelevant phrases just to game the system. App names must be limited to 50 characters and should not include terms or descriptions that are not the name of the app. Apple may modify inappropriate keywords at any time.
    • 2.5 Software Requirements
      • 2.5.11 SiriKit
        • (i) Apps integrating SiriKit should only sign up for intents they can handle without the support of an additional app and that users would expect from the stated functionality. For example, if your app is a meal planning app, you should not incorporate an intent to start a workout, even if the app shares integration with a fitness app.
        • (ii) Ensure that the vocabulary and phrases in your plist pertains to your app and the SiriKit functionality of the intents the app has registered for.
        • (iii) Resolve the Siri request in the most direct way possible and do not insert ads or other marketing between the request and its fulfillment. Only present interstitial UI when required to complete the task (e.g. asking the user to specify a particular type of workout).
    • 3.1 Payments
      • 3.1.2 Subscriptions: Subscriptions: AutoApps may offer auto-renewing subscriptions should only be offered using in-app purchase andsubscriptions, regardless of category on the App Store. When incorporating auto-renewable subscriptions into your app, be sure to follow the guidelines below.
      • Note: We will update these guidelines in the coming weeks for the subscription changes launching this fall
      • 3.1.2(a) Permissible uses: If you offer an auto-renewing subscription, you must provide ongoing value to the customer. While the following list is not exhaustive, examples of appropriate subscriptions include: new game levels; episodic content; multi-player support; apps that offer consistent, substantive updates; access to large collections of, or continually updated, media content; software as a service (“SAAS”); and cloud support. In addition:
        • Subscriptions may only be used for periodicalsbe offered alongside a la carte offerings (e.g. newspapersyou may offer a subscription to an entire library of films as well the purchase or rental of a single movie).
        • You may offer a single subscription that is shared across your own apps, magazines)but these subscriptions may not extend to third party apps or services. Subscriptions must work on all of the user’s devices where the app is available. Learn more about sharing a subscription across your apps.
        • Apps must not force users to rate the app, businessreview the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.
        • As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc.
        • Subscriptions may not include consumable credits, gems, in-game currencies, etc., even when combined with other offerings, but you may offer subscriptions that include access to discounted consumable goods (e.g. enterprise, productivity, professional creative, cloud storage), media apps (e.g. video, audio, voice, photo sharing), and other approved services (e.g. dating, dieting, weathera platinum membership that exposes gem-packs for a reduced price). These subscriptions must last a minimum of 7 days and be accessible from all of the user’s devices where the
        • If you are changing your existing app is availableto a subscription-based business model, you should not take away the primary functionality existing users have already paid for. You may offer subscriptions that are shared acrossFor example, let customers who have already purchased a “full game unlock” continue to access the full game after you introduce a subscription model for new customers.
      • 3.1.2(b) Upgrades and Downgrades: Users should have a seamless upgrade/downgrade experience and should not be able to inadvertently subscribe to multiple variations of the same thing. Review best practices on managing your subscription upgrade and downgrade options.
      • 3.1.2(c) Subscription Information: Before asking a customer to subscribe, you should clearly describe what the user will get for the price. How many issues per month? How much cloud storage? What kind of access to your service? Also ensure you clearly communicate the requirements described in Schedule 2 of your agreement in Agreements, Tax, and Banking.
    • 3.2 Other Business Model Issues
      • 3.2.2 Unacceptable
        • (vi) Apps should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc. Apps should not force users to rate the app, review the app, download other apps, or take other similar actions in order to access functionality, content, or use of the app.

      4. Design

      Apple customers place a high value on products that are simple, refined, innovative, and easy to use, and that’s what we want to see on the App Store. Coming up with a great design is up to you, but the following are minimum standards for approval to the App Store. And remember that even after your app has been approved, you should update your app to ensure it remains functional and engaging to new and existing customers. Apps that stop working or offer a degraded experience may be removed from the App Store at any time.

    • 4.4 Extensions
      • 4.4.1 Keyboard extensions have some additional rules.

        They must:

        • Provide keyboard input functionality (e.g. typed characters);
        • Provide a method for progressing to the next keyboard;
        • Remain functional without full network access;
        • Provide Number and Decimal keyboard types as described in the App Extension Programming Guide;
        • Have a primary category of Utilities when the keyboard is the main point of the app; and
        • Collect user activity only to enhance the functionality of the user’s keyboard extension on the iOS device.

        They must not:

        • Include marketing, advertising, or in-app purchases;
        • Launch other apps besides Settings; or
        • Repurpose keyboard buttons for other behaviors (e.g. holding down the “return” key to launch the camera.
      • 4.4.2 Safari extensions must run on the current version of Safari on OS X. They may not interfere with System or Safari UI elements and must never include malicious or misleading content or code. Violating this rule will lead to removal from the Developer Program. Safari extensions should not claim access to more websites than strictly necessary to function.
      • 4.4.3 Stickers

        Stickers are a great way to make Messages more dynamic and fun, letting people express themselves in clever, funny, meaningful ways. Whether your app contains a sticker extension or you’re creating free-standing sticker packs, its content shouldn’t offend users, create a negative experience, or violate the law.

        • (i) In general, if it wouldn’t be suitable for the App Store, it doesn’t belong in a sticker.
        • (ii) Consider regional sensitivities, and do not make your sticker pack available in a country where it could be poorly received or violate local law.
        • (iii) If we don’t understand what your stickers mean, include a clear explanation in your review notes to avoid any delays in the review process.
        • (iv) Ensure your stickers have relevance beyond your friends and family; they should not be specific to personal events, groups, or relationships.
        • (v) You must have all the necessary copyright, trademark, publicity rights, and permissions for the content in your stickers, and shouldn’t submit anything unless you’re authorized to do so. Keep in mind that you must be able to provide verifiable documentation upon request. Apps with sticker content you don’t have rights to use will be removed from the App Store and repeat offenders will be removed from the Developer Program. If you believe your content has been infringed by another provider, submit a claim here.
    • 5.1 Privacy
      • 5.1.1 Data Collection and Storage
        • (i) Apps that collect user or usage data must have a privacy policy and secure user consent for the collection. This includes—but isn’t limited to—apps that implement HealthKit or other health/medical technologies, HomeKit, Keyboard extensions, Apple Pay, Stickers and iMessage extensions, include a login, or access user data from the device (e.g. location, contacts, calendar, etc.).
        • (ii) If your app doesn’t include significant account-based features, let people use it without a log-in. Apps may not require users to enter personal information to function, except when directly relevant to the core functionality of the app or required by law. If your core app functionality is not related to a specific social network (e.g. Facebook, WeChat, Weibo, Twitter, etc.), you must provide access without a login or via another mechanism. Pulling basic profile information, sharing to the social network, or inviting friends to use the app are not considered core app functionality.
        • (iii) Developers that use their apps to surreptitiously discover passwords or other private data will be removed from the Developer Program.
        • (iv)SafariViewContoller must be used to visibly present information to users; the controller may not be hidden or obscured by other views or layers. Additionally, an app may not use SafariViewController to track users without their knowledge and consent.
    • June 13, 2016

      Totally rewritten after WWDC keynote

      What a keynote! Apple announced significant updates for their 4 big platforms: iOS, macOS, watchOS, and tvOS. And right after the keynote ended the App Store Review Guidelines were also updated. But not just updated… Totally rewritten! The previous 30 sections have been reduce to only 5 sections but the word count has gone up from around 5000 words to over 6000 words.

      This post will not include a diff showing what changed since the last update in April since basically everything changed.

      From the introduction:

      The guiding principle of the App Store is simple - we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful. We have updated the App Review Guidelines with that principle in mind. The guidelines themselves haven’t changed, but they are better organized and provide more context. On the following pages you will find guidelines arranged into five clear sections: Safety, Performance, Business, Design, and Legal.

      Last week when Apple told journalists that App Store Subscription Pricing would no longer be limited to apps with media content and services there was much uncertainty to what that really meant. The new guidelines actually elaborates on that:

      Auto-renewing subscriptions should only be offered using in-app purchase and may only be used for periodicals (e.g. newspapers, magazines), business apps (e.g. enterprise, productivity, professional creative, cloud storage), media apps (e.g. video, audio, voice, photo sharing), and other approved services (e.g. dating, dieting, weather)

      So I guess that means Apple have a whitelist of what kinds of apps will be allowed to use Subscription Pricing.

      Basically you should read the new guidelines from start to end. If you stumble upon new rules that were not mentioned before, then please let us know so we can update this post.

      April 19, 2016

      New Apple Music API section, CareKit and other updates

      Today Apple once again updated the App Store Review Guidelines. It’s been 6 months since the last update, and the recent iOS 9.3 release added several new developer APIs; so this update was not unexpected.

      Most significant is perhaps the new section 10.8 that states apps using background location services must provide a reason for doing so. What Apple considers a fair reason is not really clear although the HIG is mentioned.

      Another significant addition is the new section 30 about the Apple Music API that was introduced in iOS 9.3. As described in the iOS 9.3 release note the new API allows 3rd party apps to add music to a user’s Apple Music library and play it.

      The update did also include some minor additions mentioning new Apple products such as CareKit and Apple Music in various sections. Additions are highlighted in green below.

      4. Location

      • 4.5

        Apps using background location services must provide a reason that clarifies the purpose of the use, using mechanisms described in the Human Interface Guidelines

      8. Content and Intellectual Property Rights

      • 8.6

        Apps that include the ability to save or download music or video content from third party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc) without explicit authorization from those sources will be rejected

      10. User interface

      • 10.8

        Apps displaying Activity rings may not modify the rings or the data they represent

      11. Purchasing and currencies

      • 11.8

        Apps that use IAP to purchase access to built-in capabilities provided by iOS, watchOS, and tvOS, such as the camera or the gyroscope, or Apple-branded peripherals, such as Apple Pencil or Apple Keyboard, or Apple services, such as Apple Music access or iCloud storage, will be rejected

      25. Extensions

      • 25.7

        Apps offering Keyboard extensions must provide keyboard functionality (e.g. typed characters), have a primary category of Utilities and a privacy policy or they will be rejected

      27. HealthKit, CareKit, and Human Subject Research

      • 27.1

        Apps using the HealthKit frameworkor CareKit frameworks or conducting human subject research for health purposes, such as through the use of ResearchKit, must comply with applicable law for each Territory in which the App is made available, as well as Sections 3.3.28 and 3.3.39 of the iOS Developer Program License Agreement

      • 27.2

        Apps that write false or inaccurate data into HealthKit or CareKit will be rejected

      • 27.4

        Apps may not use or disclose to third parties user data gathered from the HealthKit APIor CareKit APIs or from health-related human subject research for advertising or other use-based data mining purposes other than improving health, or for the purpose of health research

      • 27.5

        Apps that share user data acquired via the HealthKit APIor CareKit APIs with third parties without user consent will be rejected

      • 27.6

        Apps using the HealthKit frameworkor CareKit frameworks must indicate integration with the Health app in their marketing text and must clearly identify the HealthKit and CareKit functionality in the app’s user interface

      • 27.7

        Apps using the HealthKit frameworkor CareKit frameworks or conducting human subject research must provide a privacy policy or they will be rejected

      30. Apple Music API

      • 30.1

        Apps using the Apple Music API that trigger playback without explicit user action will be rejected

      • 30.2

        Apps using the Apple Music API must expose and respect standard media controls such as “play,” pause,” and “skip”

      • 30.3

        Apps using the Apple Music API may not require payment or otherwise monetize access to the Apple Music service (eg. in-app purchase, advertising, requesting user info)

      October 21, 2015

      Guidelines updated for tvOS apps

      Along with other releases (iOS 9.1, watchOS 2.0.1 and tvOS GM) Apple silently updated the App Store Review Guidelines today. The changes listed below are mostly related to the release of the new Apple TV, but the new Apple Pencil also gets a mention.

      The new section 2.27 is rather confusing in its mention of the new Siri remote without explaining that the section only applies to tvOS apps (which we assume).

      The updated section 3.6 now says that tvOS top shelf extensions must only show content that adhere to the 4+ age rating. This basically means that we should be very careful with using any user generated content for the top shelf.

      2. Functionality

      • 2.27

        If your app’s core functionality doesn’t work with the Siri remote it will be rejected. The app may, however, provide enhanced functionality in connection with a game controller or other peripheral

      3. Metadata (name, descriptions, ratings, rankings, etc.)

      • 3.6

        Apps with App icons, screenshots, and previews, and images displayed when an Apple TV app is in the top shelf of the Apple TV home screen that do not adhere to the 4+ age rating will be rejected

      • 3.17

        App previews and screenshots that include content played or streamed via the app (e.g. iTunes playlistmusic, YouTube streaming video, and related cover art) that is not licensed for use in the preview or screenshots will be rejected

      10. User interface

      11. Purchasing and currencies

      • 11.8

        Apps that use IAP to purchase access to built-in capabilities provided by iOS, watchOS, and tvOS, such as the camera or the gyroscope, or Apple-branded peripherals, such as Apple Pencil or Apple Keyboard, will be rejected

      September 16, 2015

      After releasing iOS 9 Apple just renames Passbook and make no other changes

      With the release of iOS 9 we expected Apple to make a bunch of changes to the App Store Review Guidelines like they did last year. But this time the only change is that Passbook has been renamed to Wallet.

      23. PassbookWallet

      • 23.1

        Passbook PassesWallet passes can be used to make or receive payments, transmit offers, or offer identification (such as movie tickets, airline tickets, coupons and reward offers). Other uses may result in the rejection of the App and the revocation of PassbookWallet credentials

      • 23.2

        Passes must include valid contact information from the issuer of the pass or the App will be rejected and PassbookWallet credentials may be revoked

      • 23.3

        Passes must be signed by the entity that will be distributing the pass under its own name, trademark, or brand or the App will be rejected and PassbookWallet credentials may be revoked

      April 28, 2015

      Watch apps for telling time and Human Subject Research

      Shortly after customers begin to receive their Apple Watches and Apple boasts over 3,500 Watch apps are available, Apple made two small changes to the App Store Review Guidelines. The new section 10.7 states that watch apps must do more than just telling time. Also a new requirement on Human Subject Research says that the research should have approval from an independant ethics review board.

      10. User interface

      • 10.2

        Apps that look similar to Apps bundled on the iPhoneiOS or Watch OS devices, including the App Store, iTunes Store, and iBooks Store, will be rejected

      • 10.7

        Watch Apps whose primary function is telling time will be rejected

      27. HealthKit and Human Subject Research

      • 27.10

        Apps conducting health-related human subject research must secure approval from an independent ethics review board. Proof of such approval must be provided upon request.

      March 12, 2015

      Research Kit, Apple Pay recurring payments, SoundCloud downloads

      After the Spring Forward media event earlier this week Apple has updated the App Store Review Guidelines with a few changes to the HealthKit so that it also mentions ResearchKit and there is a new paragraph on Apple Pay recurring payments. Finally there is a new paragraph stating that apps downloading media from online services such as YouTube, SoundCloud, and Vimeo etc. must obtain permission from those companies before doing so.

      8. Content and Intellectual Property Rights

      • 8.6

        Apps that include the ability to download music or video content from third party sources (e.g. YouTube, SoundCloud, Vimeo, etc) without explicit authorization from those sources will be rejected

      9. Media content

      • 9.4

        Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64192 kbps or lower HTTP Live stream

      27. HealthKit and Human Subject Research

      • 27.1

        Apps using the HealthKit framework or conducting human subject research for health purposes, such as through the use of ResearchKit, must comply with applicable law for each Territory in which the App is made available, as well as Sections 3.3.28 and 3.3.39 of the iOS Developer Program License Agreement

      • 27.4

        Apps may not use or disclose to third parties user data gathered from the HealthKit API or from health-related human subject research for advertising or other use-based data mining purposes other than improving health, medical, and fitness management, or for the purpose of medicalhealth research

      • 27.7

        Apps using the HealthKit framework or conducting human subject research must provide a privacy policy or they will be rejected

      • 27.9

        Apps conducting health-related human subject research must obtain consent from participants or, in the case of minors, their parent or guardian. Such consent must include the (a) nature, purpose, and duration of the research; (b) procedures, risks, and benefits to the participant; (c) information about confidentiality and handling of data (including any sharing with third parties); (d) a point of contact for participant questions; and (e) the withdrawal process

      29. Apple Pay

      • 29.1

        Apps using Apple Pay must provide all material purchase information to the user prior to sale of any good or service or they will be rejected; Apps using Apple Pay to offer recurring payments must, at a minimum, disclose the length of the renewal term and the fact that it will continue until canceled, what will be provided during each period, the charges that will be billed to the customer, and how to cancel.

      • 29.2

        Apps using Apple Pay must use Apple Pay branding and user interface elements correctly and as described in the Apple Pay Human InterfaceIdentity Guidelines or they will be rejected

      September 11, 2014

      Apple Pay Changes

      Only a week after the last revision Apple again updates the App Store Review Guidelines with a new section 29 on Apple Pay.

      29. Apple Pay

      • 29.1

        Apps using Apple Pay must provide all material purchase information to the user prior to sale of any good or service or they will be rejected

      • 29.2

        Apps using Apple Pay must use Apple Pay branding and user interface elements correctly and as described in the Apple Pay Human Interface Guidelines or they will be rejected

      • 29.3

        Apps using Apple Pay as a purchasing mechanism may not offer goods or services that violate the law of any territory in which the good or service will be delivered and may not be used for any illegal purpose

      • 29.4

        Apps using Apple Pay must provide a privacy policy or they will be rejected

      • 29.5

        Apps using Apple Pay may only share user data acquired via Apple Pay with third parties when provided to facilitate or improve delivery of goods and services or to comply with legal requirements

      September 03, 2014

      Introducing Previews, Flagging, Privacy Policy, Extensions, HomeKit, Healtkit and TestFlight

      Together with the iOS 8 release Apple updated the App Store Review Guidelines with new sections on Extensions, HomeKit, HealtKit and Testflight. Some rules on the new app previews (videos) were also introduce along with a requirement to have a privacy policy and a flagging feature if the app has user generated content.

      2. Functionality

      • 2.9

        Apps that are "beta", "demo", "trial", or "test" versions will be rejected. Beta Apps may only be submitted through TestFlight and must follow the TestFlight guidelines

      • 2.25

        Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected, unless designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or which provide significant added value for a specific group of customers

      3. Metadata (name, descriptions, ratings, rankings, etc.)

      • 3.3

        Apps with names, descriptions, or screenshots , or previews not relevant to the content and functionality of the App will be rejected

      • 3.6

        Apps with App icons, screenshots, and previews that do not adhere to the 4+ age rating will be rejected

      • 3.13

        Apps with screenshots, previews, and marketing text that do not clearly identify supplemental content or items that must be purchased separately (e.g. using IAP) will be rejected

      • 3.14

        App previews may only use video screen captures of the app, voice-overs, and textual and design overlays, or the app will be rejected

      • 3.15

        Apps with previews that display personal information of a real person without permission will be rejected/span>

      • 3.16

        App previews may only include music that is licensed for that purpose in all selected territories

      • 3.17

        App previews that include content played or streamed via the app (e.g. iTunes playlist, YouTube streaming video) that is not licensed for use in the preview will be rejected

      14. Personal attacks

      • 14.3

        Apps that display user generated content must include a method for filtering objectionable material, a mechanism for users to flag offensive content, and the ability to block abusive users from the service

      17. Privacy

      • 17.5

        Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected

      • 22.10

        Apps that use iTunes music previews in an unauthorized manner will be rejected

      25. Extensions

      • 25.1

        Apps hosting extensions must comply with the App Extension Programming Guide

      • 25.2

        Apps hosting extensions must provide some functionality (help screens, additional settings) or they will be rejected

      • 25.3

        Apps hosting extensions that include marketing, advertising, or in-app purchases in their extension view will be rejected

      • 25.4

        Keyboard extensions must provide a method for progressing to the next keyboard

      • 25.5

        Keyboard extensions must remain functional with no network access or they will be rejected

      • 25.6

        Keyboard extensions must provide Number and Decimal keyboard types as described in the App Extension Programming Guide or they will be rejected

      • 25.7

        Apps offering Keyboard extensions must have a primary category of Utilities and a privacy policy or they will be rejected

      • 25.8

        Apps offering Keyboard extensions may only collect user activity to enhance the functionality of their keyboard extension on the iOS device or they may be rejected

      26. HomeKit

      • 26.1

        Apps using the HomeKit framework must have a primary purpose of providing home automation services

      • 26.2

        Apps using the HomeKit framework must indicate this usage in their marketing text and they must provide a privacy policy or they will be rejected

      • 26.3

        Apps must not use data gathered from the HomeKit APIs for advertising or other use-based data mining

      • 26.4

        Apps using data gathered from the HomeKit API for purposes other than improving the user experience or hardware/software performance in providing home automation functionality will be rejected

      27. HealthKit

      • 27.1

        Apps using the HealthKit framework must comply with applicable law for each Territory in which the App is made available, as well as Sections 3.3.28 and 3.39 of the iOS Developer Program License Agreement

      • 27.2

        Apps that write false or inaccurate data into HealthKit will be rejected

      • 27.3

        Apps using the HealthKit framework that store users’ health information in iCloud will be rejected

      • 27.4

        Apps may not use user data gathered from the HealthKit API for advertising or other use-based data mining purposes other than improving health, medical, and fitness management, or for the purpose of medical research

      • 27.5

        Apps that share user data acquired via the HealthKit API with third parties without user consent will be rejected

      • 27.6

        Apps using the HealthKit framework must indicate integration with the Health app in their marketing text and must clearly identify the HealthKit functionality in the app’s user interface

      • 27.7

        Apps using the HealthKit framework must provide a privacy policy or they will be rejected

      • 27.8

        Apps that provide diagnoses, treatment advice, or control hardware designed to diagnose or treat medical conditions that do not provide written regulatory approval upon request will be rejected

      28. TestFlight

      • 28.1

        Apps may only use TestFlight to beta test apps intended for public distribution and must comply with the full App Review Guidelines

      • 28.2

        Apps using TestFlight must be submitted for review whenever a build contains material changes to content or functionality

      • 28.3

        Apps using TestFlight may not be distributed to testers in exchange for compensation of any kind

      August 09, 2014

      Apple Allows Recommending Related Apps and Bitcoin Apps.

      Most notably in this set of changes of the App Store Review Guidelines, Apple now allows apps to show a collection of other apps that don’t have to be your own if they form a collection in a way Apple approves. Apps are now also allowed to facilitate transmission of approved virtual currencies. In other words Bitcoin apps are now officially allowed.

      2. Functionality

      • 2.25

        Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected, unless designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or which provide significant added value for a specific group of customers

      • 2.26

        Apps may display and recommend apps other than your own only if the collection is designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or provides significant added value for a specific group of customers, or they will be rejected

      3. Metadata (name, descriptions, ratings, rankings, etc.)

      • 3.13

        Apps with screenshots and marketing text that do not clearly identify supplemental content or items that must be purchased separately (e.g. using IAP) will be rejected

      8. Trademarks and trade dressContent and Intellectual Property Rights

      • 8.3

        Apps that appear confusingly similar to an existing Apple product, interface, or advertising theme will be rejected

      11. Purchasing and currencies

      • 11.9

        Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)

      • 11.17

        Apps may facilitate transmission of approved virtual currencies provided that they do so in compliance with all state and federal laws for the territories in which the app functions

      20. Contests, sweepstakes, lotteries, raffles, and gambling

      • 20.4

        Apps that allow a user to directly purchase a lottery or raffle ticket in the App will be rejected

      • 20.5

        Apps that offer real money gaming (e.g. sports betting, poker, casino games, horse racing) or lotteries must have necessary licensing and permissions in the locations where the App is used, must be restricted to those locations, and must be free on the App Store

      24. Kids Category

      • 24.1

        Apps primarily intended for use by kidsin the Kids Category must include a privacy policy and must comply with applicable children's privacy statutes

      • 24.2

        Apps primarily intended for use by kidsin the Kids Category may not include behavioral advertising (e.g. the advertiser may not serve ads based on the user's activity within the App), and any contextual ads presented in the App must be appropriate for kids

      • 24.3

        Apps primarily intended forin the Kids Category must get parental permission or use by kids must geta parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce

      March 30, 2014

      Cellular Download Limit and Kids Category

      A few general changes were introduced in this revision of the App Store Review Guidelines. The limit for downloading apps over 3G cellular were raised from 50 MB to 100 MB the iBookstore was renamed to iBooks Store. Section 24 “Kids Apps” was renamed to “Kids Category” along with the introduction of the new special App Store category.

      2. Functionality

      • 2.15

        Apps larger than 50MB100MB in size will not download over cellular networks (this is automatically prohibited by the App Store)

      • 2.21

        Apps that are simply a song or movie should be submitted to the iTunes store. Apps that are simply a book should be submitted to the iBookstoreiBooks Store

      • 2.25

        Apps that display Apps other than your own for purchase or promotion in a manner similar to or confusing with the App Store will be rejected, unless designed for a specific approved need (e.g. health management, aviation, accessibility, etc.) or which provide significant added value for a specific group of customers

      3. Metadata (name, descriptions, ratings, rankings, etc.)

      • 3.3

        Apps with names, descriptions, or screenshots not relevant to the App content and functionality will be rejected

      4. Location

      • 4.3

        Apps that use location-based APIs for dispatch, fleet management, or emergency services will be rejected

      5. Push Notifications

      • 5.3

        Apps that send Push Notifications without first obtaining user consent, as well as apps that require Push Notifications to function, will be rejected

      9. Media content

      • 9.4

        Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 64 kbps audio-only HTTP Live stream

      10. User interface

      • 10.2

        Apps that look similar to Apps bundled on the iPhone, including the App Store, iTunes Store, and iBookstoreiBooks Store, will be rejected

      11. Purchasing and currencies

      • 11.9

        Apps containing "rental" content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs)

      17. Privacy

      • 17.4

        Apps that collect, transmit, or have the capability to share personal information (e.g. name, address, email, location, photos, videos, drawings, persistent identifiers, the ability to chat, or other personal data, or persistent identifiers used in combination with any of the above) from a minor must comply with applicable children's privacy statutes

      21. Charities and contributions

      • 21.2

        The collection of charitable donations must be done via a web site in Safari or an SMS

      24. Kids AppsCategory

      • 24.1

        Apps primarily intended for use by kids under 13 must include a privacy policy and must comply with applicable children's privacy statutes

      • 24.2

        Apps primarily intended for use by kids under 13 may not include behavioral advertising (e.g. the advertiser may not serve ads based on the user's activity within the App), and any contextual ads presented in the App must be appropriate for kids

      • 24.3

        Apps primarily intended for use by kids under 13 must get parental permission or use a parental gate before allowing the user to link out of the app or engage in commerce