A reader app is six content types and one test your app either passes or not.
Apple defines a reader app as an app that provides one or more of six digital content types as the primary functionality of the app: magazines, newspapers, books, audio, music, or video. That is the whole list. The phrase primary functionality is the part that decides most cases, and Apple says an app that merely lets people reach music or video is not a reader app. What the status buys is narrow and useful: a signed-in customer may use content or subscriptions they bought on your website, without buying them again through in-app purchase. Reader status is one of the monetisation routes Apple carves out, not a general exemption from its payment rules.
Every rule, field name and date below comes from Apple's own reader apps page and the App Review Guidelines, read on 10 October 2026. What follows is the definition and who fails it, what a reader app may do that other apps may not, when the External Link Account Entitlement is actually required, and the link rules that send a submission back. The thing people miss is at the end of the first section: App Review decides whether you are a reader app, and the entitlement form does not.
Start hereThe short version
Six content types, and primary functionality is the test.
Apple's own page puts it in one sentence. Reader apps provide one or more of the following digital content types as the primary functionality of the app: magazines, newspapers, books, audio, music, or video. Nothing else is on that list. Not games, not fitness, not productivity, and not a social app with a video tab. App Store categories are a separate system, so there is no Reader Apps category to select, and choosing Magazines and Newspapers in App Store Connect does not make an app a reader app.
What the status gives you sits in guideline 3.1.3(a). Apps may allow a user to access previously purchased content or content subscriptions, and reader apps may offer account creation for free tiers plus account management functionality for existing customers. Selling a paid tier inside the app is a different thing, and digital content sold inside an app means in-app purchase. Putting a link in the app to your own site, so someone can create or manage that account, is the piece that needs the External Link Account Entitlement, and Apple states that entitlement is optional.
Which apps count as reader apps in Apple's definition?
The definition is a content list plus a functional test, and most wrong answers skip the second half. The content list has six entries: magazines, newspapers, books, audio, music, or video. Guideline 3.1.3(a) names the same six in brackets. The functional test is the phrase primary functionality, and Apple spells out what failing it looks like. Apps that let people access digital content such as music or video, but not as the primary functionality, are not considered reader apps and are not eligible for the entitlement. The example Apple gives is a social networking app that lets people stream audiovisual content.
Five eligibility requirements are published for the entitlement, and together they describe the shape of a reader app better than the one-line definition does. Your app provides one or more of those six content types as its primary functionality. It lets people sign in to an account. It lets a signed-in person reach content or services previously purchased outside the app, such as on your website. It does not offer in-app purchases on iOS, iPadOS, or tvOS while using the entitlement. And it does not facilitate real-time, person-to-person services, for which Apple's examples are tutoring, medical consultations, real estate tours and fitness training.
Two consequences catch people out. The first is that nobody pre-approves your reading of the definition. The entitlement request is a form, and App Review is a separate gate: Apple states that if your app is found during submission not to qualify as a reader app, it will not be approved as long as it includes the entitlement. Holding it and failing the test is worse than never asking. The second is about existing apps. Asked whether a published app can become a reader app, Apple says it depends, accepts that a business model may change over time, and warns that an update which significantly changes the app's primary functionality is not appropriate. For a new concept it recommends a new app record and a new binary.
Apple, distributing reader apps with a link to your website, read 10 October 2026
Try it
Is your app a reader app?
What the app is mainly for
Does it sell anything by in-app purchase on Apple platforms?
Pick what the app is for, and whether it sells through in-app purchase. Every answer is read out of Apple's own reader apps page and the App Review Guidelines on 10 October 2026, not out of a summary of them.
What can a reader app do that other apps cannot?
One thing, precisely. It can let a signed-in customer use content or content subscriptions bought somewhere else, without that purchase running through in-app purchase. Guideline 3.1.3(a) lists the content in brackets, magazines, newspapers, books, audio, music, and video, then adds the two account powers: account creation for free tiers, and account management functionality for existing customers. Read the word free in that sentence carefully. A paid tier created inside the app is a sale of digital content inside an app, which means it belongs to in-app purchase and to subscriptions rather than to this exemption.
The restriction that travels with it is in the preamble to 3.1.3 and applies to every carve-out in the section. Apps in it cannot, within the app, encourage users to use a purchasing method other than in-app purchase, with the exceptions Apple names: apps on the United States storefront, and what 3.1.1(a) and 3.1.3(a) themselves permit. Outside the app nothing changes. Apple states that developers can send communications outside of the app to their user base about purchasing methods other than in-app purchase, so the email you send your own subscribers is not an App Store matter.
Reader status is also not the only exemption in 3.1.3, and picking the wrong one is common. 3.1.3(b) covers multiplatform services, where people may use content acquired on your other platforms or your website, provided those items are also available as in-app purchases within the app. 3.1.3(c) covers enterprise services sold directly to organisations or groups, and says consumer, single user or family sales must use in-app purchase. 3.1.3(d) covers real-time person-to-person services between two individuals, while one-to-few and one-to-many services must use in-app purchase. 3.1.3(e) requires other payment methods for physical goods and services consumed outside the app. 3.1.3(f) covers a free app acting as a stand-alone companion to a paid web based tool, with no purchasing in the app at all.
Apple, App Review Guidelines, section 3.1.3, read 10 October 2026
Do you need the External Link Account Entitlement?
Usually not. Apple's answer to its own question is that the entitlement is optional and only required for reader apps that wish to link out to a website for account creation and management, and that reader apps can keep offering account creation for free tiers and account management for existing customers inside the app under 3.1.3(a). If sign-in and in-app account screens are enough, you need nothing. There is a storefront exception in the guidelines as well: the entitlement is not required for developers to include buttons, external links, or other calls to action in their United States storefront apps, and 3.1.1(a) repeats that sentence for the purchase link entitlements.
The mechanics are per app, not per account. Requests are per bundle ID, and an assigned entitlement can only be used with the single binary associated with that bundle ID, so three reader apps mean three requests. To submit the form you have to be an Account Holder in the Apple Developer Program, answer questions about the app, and agree to the entitlement's terms and conditions. Apple also closes the obvious shortcut. You may not put the account link in your App Store listing metadata, because linking out is allowed only from inside the app, with the entitlement, which Apple describes as a more secure and transparent experience for someone leaving its ecosystem.
Two availability facts, both read on 10 October 2026. The entitlement can be used by approved reader apps distributed in any country or region where the App Store is available, on devices running iOS or iPadOS, or tvOS 16.4 or later. And there is a new EU addition: as of 1 October 2026, reader apps distributed in the EU may promote out-of-app offers for digital goods and services without an actionable link, whether or not they use this entitlement, provided those offers sit on a separate page from any account creation or management link and the app uses the StoreKit External Purchases or Offers Entitlement. Selling rather than account management is a different family of entitlements, and what those links may say differs too: a StoreKit External Purchase Link Entitlement lets you tell people where and how to buy, and that items may be available for a comparatively lower price, while only the Music Streaming Services Entitlements permit naming the price itself. That is the subject of linking out to external payment.
Apple, App Review Guidelines, sections 3.1.1(a) and 3.1.3(a), read 10 October 2026
What gets a reader app link rejected?
Start with the two keys, because the entitlement is configuration before it is anything else. In the entitlements plist file you add com.apple.developer.storekit.external-link.account, type Boolean, value true. In Info.plist you add SKExternalLinkAccount, a dictionary with string values, whose keys are region codes and whose values are the destination URL, and it must contain a key whose string is an asterisk mapping to a default URL. Each URL has to use the https scheme, form a valid absolute URL, contain no query parameters, and run to 1,000 or fewer ASCII characters. Apple also requires that the URLs in Info.plist match the value in the binary you submitted to App Review at all times.
Then the link itself, which is where submissions come back. It must go to a website you own or have responsibility for. It must open a new window in the default browser on the device, and may not open a web view. It must not pass additional parameters in the URL. It must be submitted with the app and resubmitted if the URL changes. It must not include, or be used with, language that includes the price of items available on the website, and Apple's example of acceptable wording is to go to example.com to create or manage your account. It must be formatted like a standard HTML link, which Apple describes as blue underlined text, and contain the domain name of the site. It must appear only once per app page and say the same thing in each instance. It must be statically defined in Info.plist before submission. And it must go directly to your website with no redirect, intermediate link or landing page.
Before the link opens anything, your app has to show an interstitial modal sheet, and it must call canMakePayments and confirm the user has permission to make payments before showing it. On iOS 16 and iPadOS 16 or later, and tvOS 16.4 or later, that sheet is the External Link Account API. Below those versions you reproduce Apple's own modal sheet design and text exactly. Apple requires the API for any entitled app whose minimum is iOS 16, iPadOS 16 or tvOS 16.4, and set 12 October 2022 as the date by which a published app had to ship that update. At submission you confirm the sheet is implemented and tested, the website is fully functional, and screenshots of the screens making the disclosures are attached. An incomplete submission delays review or gets rejected, which puts this among the rejection reasons that bite.
Apple, requesting and implementing the External Link Account Entitlement, read 10 October 2026
What reader status allows, and what the entitlement adds
| What the app wants to do | Reader app, no entitlement | Reader app with the entitlement | Any other app, outside the US storefront |
|---|---|---|---|
| Unlock content or a subscription bought on your website | Yes | Yes | Only under another 3.1.3 carve-out |
| Account creation for a free tier, inside the app | Yes | Yes | Yes |
| Account management for existing customers, inside the app | Yes | Yes | Yes |
| A link in the app to your site to create or manage the account | No | Yes | This entitlement is reader apps only |
| Offer in-app purchases on iOS, iPadOS or tvOS as well | Yes | No | Yes |
| Put that account link in the App Store listing instead | No | No | No |
| Name the price of what is sold on the website | No | No | Music streaming entitlement only |
Where this lands if a builder generated your app
Nothing in the definition changes because an agent wrote the code, and one guideline matters more than usual here. Guideline 4.2.6 says 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. A reader app is the front end to a content business you already run, so you are that provider. You submit it, and you are also the Account Holder who has to request the entitlement and agree to its terms.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps two-way GitHub sync so the code is never trapped. It does not submit to the App Store for you, for the reason above. It is $25 a month, with no free tier. For reader app work the useful part is ownership: the entitlement key and the SKExternalLinkAccount dictionary are native configuration, so you need a project you can open, edit and sign, not a closed preview.
The honest limits. No builder can grant the entitlement, and no builder can make App Review agree that your primary functionality is one of the six content types. Generating a sign-in screen, a library and an account page is the easy half. The half that decides the outcome is whether the business behind the app really is magazines, newspapers, books, audio, music or video, and whether a single line of in-app copy ever drifts into naming a price.
Questions people ask about reader apps
Apple defines a reader app as an app that provides one or more of six digital content types as the primary functionality of the app: magazines, newspapers, books, audio, music, or video. A reader app may let a signed-in person use content or content subscriptions they bought somewhere else, without that purchase going through in-app purchase. Guideline 3.1.3(a) adds that reader apps may offer account creation for free tiers and account management functionality for existing customers. Both the definition and the guideline were read on 10 October 2026.
Describe the reader app, then submit it yourself
Build the sign-in, the library and the account screens, keep every price out of the app, and keep the project in your own hands so the entitlement is a plist edit and a resubmission rather than a support ticket.
Start building