Apple App Store Guidelines Update

This adds a consequence for apps that do not implement appropriate safeguards or do not remediate identified violations after being notified. Such failures can now be treated as violations of the Developer Code of Conduct, which goes beyond a normal app rejection. Developers should respond promptly to notices, since account-level consequences are now possible.

This new language sets the enforcement consequence for violating the hidden-features rule. Trying to conceal undocumented functionality in the app binary, through code obfuscation or other methods, is grounds for removal from the App Store and termination of the developer account. Developers using obfuscation tools should make sure they hide only code, never undisclosed functionality.

Developers must now provide the required documentation when an app or feature depends on regulatory approval, such as in health, finance, or other regulated areas. Without it, review may stall or the app may be rejected. If your app operates in a regulated category, gather licenses and approvals before submitting.

The old rule only said authorities would be notified in extreme cases. The updated rule adds that such apps will also be removed from the App Store and blocked from alternative distribution. This extends the consequences beyond the App Store to alternative marketplaces and web distribution. It affects only apps involved in these severe violations, but it shows Apple's enforcement reaches beyond its own storefront.

The old intro referred narrowly to apps with user-generated content. The new rule covers apps that enable users to create, generate, upload, share, or otherwise contribute content. It also explicitly lists nonconsensual intimate imagery as a risk alongside IP infringement and anonymous bullying. This widens the set of apps that need moderation safeguards and may affect apps that previously did not consider themselves UGC apps.

The new sentence names social media, user-generated content platforms, and AI content creation apps as in scope. AI apps that generate content should expect to be reviewed against the filtering, reporting, blocking, and contact-info requirements. Developers of generative AI features should verify they have these safeguards in place.

Apps with media such as films, music, or games must now comply with local requirements for displaying content ratings or warnings in each territory where they are offered. Previously this was not stated in this section. If you distribute media internationally, check territory-specific rating rules, since non-compliance could lead to rejection or removal.

Creative assets are prohibited from containing inappropriate content, references to other apps meant to mislead, unverifiable product claims, or specific or discounted pricing. Check any promotional art for price callouts or superlative claims you can't substantiate, as these could cause rejection.

New guideline 2.5.19 prohibits hidden, dormant, or undocumented features in apps. Previously there was no dedicated rule for this. Every feature should be visible and explained to users and App Review, so check for feature-flagged, dormant, or remotely activated code that reviewers cannot see or that you haven't documented in review notes.

The rule previously referred to FOREX trading apps needing licenses in all jurisdictions where they are available. It now names contracts for difference (CFDs) and other derivatives, with FOREX as one example. If your app facilitates CFD or derivatives trading, confirm you hold proper licenses in every region where the app is available, or risk rejection.

The rule says apps must not facilitate illegal file sharing or let users save, convert, or download media from services like Apple Music, YouTube, SoundCloud, or Vimeo without explicit authorization from those sources. If your app includes media downloaders, converters, or ripping features, it risks rejection unless you hold permission from the source. Review any such features and document your authorization.

The old text said to enable live backend services during review, explain non-obvious features and in-app purchases in the review notes with supporting documentation, and check other documentation (SwiftUI, UIKit, AppKit, App extensions, iCloud Backup, APFS, App Store Connect Help). The fragment was removed in this restructuring. The review notes and documentation-check items are no longer in the removed text, and only the backend item is shown re-added. Check the current guidelines to see whether you still need to document non-obvious features and in-app purchases.

A new reference points developers to resources on testing apps on compatible devices and setting up In-App Purchases for review. It adds guidance rather than a new rule. It's useful if your app has IAPs that reviewers must be able to exercise.

A new reference points to guidance on what information to provide for a complete review. It adds a resource rather than a new requirement. It helps you prepare review notes and access details.

Apple now explicitly tells developers to explain non-obvious features and in-app purchases in the App Review notes, and to attach supporting documentation where it helps. Reviewers who can't find or understand a feature may reject the app or delay review. If your app has hidden, gated, or complex functionality, add clear notes before you submit.

Developers are now told to check their app against a broad set of other Apple resources. These include developer documentation for frameworks, iCloud backup and file system guidance, App Store Connect and App Review help, the Human Interface Guidelines, and brand, marketing, and trademark guidelines. It is a pointer rather than a new rule, but violations of those documents can still lead to rejection. Review the relevant ones, especially for marketing assets and Apple trademark use.

The old text named apps with user-generated content or social networking services as needing filtering, reporting, blocking, and published contact info. The new text refers to 'such apps', which ties into the broader scope defined in the new introductory sentence. The required safeguards are unchanged, and the list of disallowed primary uses (pornographic content, Chatroulette-style experiences, random or anonymous chat, objectification of real people) is carried over. Developers should check whether the broader scope now covers their app.

The old text said apps that facilitate objectification through 'hot-or-not' voting, make physical threats, or bully do not belong on the App Store and may be removed without notice. This fragment was removed in this diff, and the surrounding text was restructured. Developers should confirm in the full guideline how these prohibitions and the removal-without-notice language are now handled.

The old text opened a rule for apps with media needing content ratings or warnings, such as films, music, and games. That lead-in was removed in this diff. Developers of media apps should check whether the requirement still appears elsewhere before assuming it was dropped.

The old rule made developers responsible for complying with local content rating or warning requirements in every territory where the app is available, for media such as films, music, and games. This sentence was removed. Developers of media apps should still follow local laws, but should check whether the requirement is now covered elsewhere in the guidelines.

Creative assets are a new type of App Store metadata that let you highlight your app's value differently from app-in-use screenshots and preview videos. They can appear across the App Store, including the product page header and search results. If you plan to use them, they fall under App Review's metadata rules.

Under the new creative assets guideline, assets must relate to your app's content, functionality, or overarching brand. They must also follow standard metadata guidelines and be appropriate for all audiences. Assets that don't meet these criteria risk rejection.

The text about apps that facilitate trading in contracts for difference or other derivatives was removed, with the 'e.g.' fragment left over. It may be re-added elsewhere in the section, but this diff alone does not show it. Until confirmed, finance developers should treat the restriction as potentially still in force and check the current guideline text.

The rule still requires approval from another developer before you use their icon, brand, or product name in your app's icon or name. The new text adds a pointer to resources on avoiding copycat and impersonation rejections. Review that material if your branding resembles another app's.

The guideline already said apps playing specific songs at certain moments, or creating shareable audio or video, need permission from rights-holders. It now names synchronization or adaptation rights and assets as examples of what to obtain. If your app pairs music with moments or generates shareable media, make sure you have those licenses.

The old rule allowed use of approved Apple RSS feeds, such as the iTunes Store RSS feed, while prohibiting scraping information from Apple sites. Its removal from this section may mean it was moved or reworded. Avoid scraping Apple sites regardless, and check whether the rule appears elsewhere before relying on it.

The scraping and rankings restriction now sits under its own numbered guideline, 4.5.1. It permits approved Apple RSS feeds, such as the iTunes Store RSS feed. It forbids scraping information from Apple sites like apple.com, the App Store, App Store Connect, or the developer portal, and forbids creating rankings from that data. Apps that pull Apple data should confirm they use only approved feeds.

The old rule said apps should not facilitate illegal file sharing or let users save, convert, or download media from third-party sources such as Apple Music, YouTube, SoundCloud, or Vimeo without authorization. This entry shows only the first half being removed, likely because of text restructuring. Check the current published guideline before assuming the rule has been dropped; if your app downloads third-party media, treat it as still applying.

The old text required explicit authorization from sources like Apple Music, YouTube, SoundCloud, and Vimeo before an app could save, convert, or download their media. This entry covers the removal of that second half. It may be a restructuring artifact, so confirm the current wording. Apps that handle third-party media should still secure authorization.

The old text included 5.2.4 on Apple endorsements and 5.2.5, which prohibits apps that look confusingly similar to existing Apple products or interfaces. This entry shows it removed, probably because of restructuring. Confirm the current published guidelines; avoid imitating Apple products or implying Apple endorsement until you do.

The rule already required an active demo account or fully-featured demo mode, plus any hardware or resources needed for review. The sentence is now completed with concrete examples (login credentials or a sample QR code) in place of a truncated 'e.g.'. The requirement is unchanged, but the examples make clear what reviewers may need from you.

The old rule listed four items in one paragraph: test for crashes and bugs, keep metadata complete and accurate, update contact information, and give App Review full access. This block was removed because the items are now listed separately. The expectations are unchanged, so no new action is needed.

The 'Make sure you' list now begins with its own item telling you to test for crashes and bugs. This was already expected under the old combined list. Crashes and bugs remain a common cause of rejection, so test before submitting.

This is now its own checklist item. It restates the earlier requirement that metadata be complete and accurate. Incomplete or misleading metadata can still lead to rejection.

This is now a standalone item that repeats the previous expectation to keep your contact details current. If reviewers can't reach you with questions, your review can stall or be rejected.

This is now its own item, restating the earlier requirement to give reviewers full access to your app. Make sure demo credentials, hardware, and gated features are accessible, or the review may fail.

This is now a standalone checklist item, restating that backend services must be live and reachable during review. If your servers are down or restricted, reviewers can't test your app and may reject it.

The old rule said that in extreme cases, such as apps facilitating human trafficking or child exploitation, authorities would be notified. This version was removed and replaced by an expanded one (see the next change). On its own, the removal changes nothing for compliant developers.

The After You Submit section now points developers to guidance on tracking the review status of a submission. It adds no new requirement. It is a helpful reference if you're waiting on review and want to understand status changes.

The After You Submit section now links to guidance on expediting requests. It introduces no new rule. Check it if you have a time-sensitive release and need to know when and how to ask for faster review.

The After You Submit section now links to guidance on contacting App Review about a submission. It sets no new requirement. It's useful if your submission is stuck or you need clarification on a review decision.

The After You Submit section now points to guidance on submitting complete appeals and suggesting changes to the guidelines. No new rule is imposed. If you plan to contest a rejection, read it first so your appeal includes everything needed.

The After You Submit section now links to information on accepting Bug Fix Submission offers. It adds no new requirement. It's relevant if your app is approved with a chance to fix minor issues, so you know how to respond to the offer.

The old sentence said user-generated content apps raise challenges from IP infringement to anonymous bullying. It has been replaced by a rewritten and broader introduction. Developers should read the new wording to see how the scope has changed.

The sentence on previews and screenshots now opens with the permission for text and image overlays, such as animated touch points or Apple Pencil, and showing extended functionality like Touch Bar. This appears to be a restructuring that merges with a removed fragment, with 'e.g.' changed to 'for example'. The permitted uses appear unchanged, so most developers are unaffected.

The old fragment introducing text and image overlays was removed because the same wording now appears in the rewritten sentence. The rule on overlays is unchanged in substance, so no action is needed.

The old text told developers to restart pre-order sales after material changes, such as a business model change, and was split across two entries. The sentence is removed here and re-added in reworded form in the same section. The expectation appears unchanged, so most apps are unaffected.

This is the remainder of the earlier guidance to restart pre-order sales after material changes such as a business model change. It is removed and replaced by a reworded version in the same section. Developers with pre-order apps should still restart pre-orders after material changes.

Section 2.3 now includes a link-style reference to more information on showing the app in use in screenshots. It adds no new requirement by itself, but it highlights that screenshots should show actual app use. Review your screenshots against that guidance.

The guidance still says to restart pre-order sales if you make material changes, now giving 'changing business models' as the example instead of a broader 'e.g.' list. The substance is essentially unchanged. Developers running pre-orders should keep following it.

The guidelines now point developers to App Store asset best practices for detailed guidance on what is acceptable in creative assets. It adds no new rule itself, but it's a useful resource before submitting assets.

The rule that apps should run on the currently shipping OS and avoid deprecated or optionally installed technologies is unchanged, but the example is now explicitly 'Java'. Previously the example was an 'e.g.' that was cut off. Apps relying on Java or similar technologies should be aware this is a stated example.

The exception allowing apps to unlock hardware-dependent features without in-app purchase is unchanged. The astronomy and telescope example was moved into the same sentence, and 'e.g.' became 'such as'. This appears to be a formatting and wording cleanup with no new requirement. Whether it is purely cosmetic is uncertain, so it is flagged as non-cosmetic.

The astronomy app example that previously appeared as a separate fragment was removed from its old location. It now appears within the main sentence, so the rule's meaning is unchanged. Developers need no action, since the hardware-dependent unlock exception works as before.

The rule allowing apps to display or recommend collections of third-party apps for a specific approved need is unchanged. The examples (health management, aviation, accessibility) were merged into the same sentence with 'such as' replacing 'e.g.'. This is a wording cleanup and does not change what is allowed.

The fragment listing health management, aviation, and accessibility was removed from its old location because it now sits in the main sentence. The rule's scope is unchanged, so no developer action is needed.

The original text allowing apps to disable access to approved rental content was removed in this diff. It is replaced by a reworded version in a separate change. The policy remains the same, so rental apps need no changes.

The fragment about films, TV programs, music and books, and the rule that other items and services may not expire, was removed from its old split location. The same content is re-added in a unified sentence, so the requirement that only rental content may expire remains.

The rule still lets apps disable access to approved rental content after the rental period ends, and still says all other items and services may not expire. The text was merged into one sentence and 'e.g.' became 'such as'. Developers need no changes.

The old text, a fragment of the rule requiring trading apps to be licensed in every jurisdiction where they are offered, was removed. It is replaced by a complete sentence (see the related addition). The licensing requirement itself is unchanged for apps that facilitate FOREX trading, so no action is needed unless the new scope applies to you.

The guideline still permits apps to incentivize specific in-app actions, such as completing a level or watching an ad. Only the phrasing of the examples changed, from an abbreviation-based example to a "such as" construction. No change is needed in your app.

The old sentence prohibited using another developer's icon, brand, or product name in your app's icon or name without their approval. It was removed as part of a replacement that keeps the rule and adds a reference link. The restriction itself stays in place.

The list of what keyboard extensions must do (provide input functionality, follow Sticker guidelines for images or emoji, offer a way to switch keyboards, work without full network or full access, and collect activity data only to enhance the keyboard) is the same. The text now begins with "They must:" and uses "such as" instead of an abbreviation. Existing compliant keyboards are unaffected.

Keyboard extensions still must not launch apps other than Settings or repurpose keyboard buttons, for example holding "return" to launch the camera. Only the example phrasing changed. No action is needed.

The removed text was the start of the list of keyboard extension requirements. It was folded into the reworded version in the same section. The requirements themselves remain unchanged.

The old text barred scraping Apple sites such as apple.com, the App Store, and App Store Connect, and barred building rankings from that data. This fragment was removed here because the rule now appears as numbered guideline 4.5.1. The restriction itself appears unchanged, so developers need no action beyond knowing where it lives.

The removed text was the end of an earlier rule about rights and assets, and it no longer appears in this section. The change reflects section 4.5 being reorganized, and it is unclear whether the underlying requirement was dropped or moved elsewhere. Developers who use Apple-related content or assets should re-read the current 4.5 text to confirm their usage is still allowed.

A new line links to guidance on writing clear purpose strings, the permission-prompt text shown when an app requests access to user data. It adds no new requirement, but it signals that vague or unclear purpose strings may draw review scrutiny. Developers should check that their permission descriptions explain clearly why data is needed.

The old text began mid-sentence because the opening clause sat in a separate entry. The new text is one complete sentence: apps may not require users to enable system functionalities such as push notifications, location services, or tracking to access features, content, or compensation like gift cards. The rule itself is unchanged, so no action is needed if you already comply.

The opening fragment 'Your app may not require users to enable system functionalities (e.g.' was a separate entry. It now appears inside the full sentence of the updated 5.1.2(i). The restriction on forcing users to enable system permissions is unchanged, so this has no practical effect on developers.

The old text used the abbreviation 'e.g.' and split the example question into a separate line. The new text spells out 'for example' and includes 'What will the message say?' inline. The requirement is the same: show users a clear description of how a message will appear to the recipient before sending it.

This question was a separate entry after a sentence split. It now sits inside the updated 5.1.2(v) text. The requirement to describe message content to users before sending is unchanged, so developers need to do nothing.

The fragment 'Moreover, apps in the Kids Category or those that collect, transmit, or have the capability to share personal information (e.g.' was dropped as a separate entry. The full sentence is re-added in the new text. The rule is unchanged.

The old text listed the personal data types (name, address, email, location, photos, and so on) after 'e.g.'. It is replaced by a single complete sentence. Apps in the Kids Category, or apps that collect or can share minors' personal information, still need a privacy policy and must comply with children's privacy laws.

The sentence is consolidated and 'e.g.' becomes 'such as'. The requirement is the same: Kids Category apps, and apps that collect, transmit, or can share minors' personal information, must include a privacy policy and comply with children's privacy laws. The change is editorial and doesn't alter what counts as personal information.

The old text ended a sentence about not creating apps that look like Apple interfaces, apps (App Store, iTunes Store, Messages) or advertising themes. The same wording reappears in a new 5.2 entry, so this looks like a relocation rather than a policy change. Developers should not expect new restrictions from this removal alone.

The old text barred using iTunes and Apple Music previews for entertainment value. An equivalent sentence is added back elsewhere in 5.2, so the restriction itself continues. This is a reorganization and requires no action if you already comply.

The removed text gave examples (background music for a photo collage, game soundtrack) and banned other unauthorized uses of previews. The same content is re-added in a new entry, so the rule persists. Developers using Apple Music or iTunes previews should keep avoiding these uses.

The text forbids apps that look confusingly similar to Apple products, interfaces like Finder, apps like the App Store, iTunes Store or Messages, or Apple advertising themes. The content largely matches the earlier rule, but it now sits under new section numbers, with the headings appearing combined. Developers should check that their UI and branding do not imitate Apple's.

Apps still may not use iTunes and Apple Music previews for entertainment value, such as background music for a photo collage or a game soundtrack, or in any other unauthorized way. The wording changed slightly from the old text ("e.g." became "such as"), but the meaning is the same. No new obligations arise for compliant apps.

The requirements are unchanged: apps offering real-money gaming or lotteries need licensing and permissions in each location of use, must geo-restrict to those locations, and must be free on the App Store. The change moves the 5.3.4 label into this text block and swaps "e.g." for "such as". Gambling apps need no new action.

The removed fragment was the start of the real-money gaming guideline. The full rule, with its licensing, geo-restriction, and free-app requirements, is restated in a modified entry. This is a restructuring and doesn't change what gambling apps must do.