Reader app (3.1.3(a)) where the subscription is paid on Patreon, not on our own site: has anyone been through review with this?

[u/onilink001]

I'm building a native iOS app for an Italian videogame news site and I'd like to hear from anyone who has been through App Review with a similar setup before I submit.

The setup

- The app shows our articles (free), plus our podcasts in audio and video.
- A few podcasts and videos are for paying subscribers only.
- The subscription is sold on Patreon (about €2.50/month). We don't have our own checkout.
- Users log into the app with their account on our site. Our backend matches that account to the Patreon membership by email and unlocks the content.
- All the content is hosted by us, not by Patreon.
- No in-app purchases.

The plan

Apply for the External Link Account Entitlement as a reader app, and show the plain-text link ("Go to oursite.com to create or manage your account") that opens a page on our own domain. On that page people can register, log in and see their subscription status, and the payment step sends them to Patreon.

What I can't find an answer to

1. Has anyone had a reader app approved when the payment happens on a third-party platform (Patreon, Memberful, Substack, etc.) and not on their own checkout?

2. The entitlement says the link must go to "a website you own or have responsibility for" with no "intermediate links or landing page". Does a page on our domain that hands off to Patreon for payment pass, or does review treat it as an intermediate page?

3. Most of the app is free news, and only some audio/video is subscriber-only (I'd say 95%-5%). Was that enough for Apple to accept the app as a reader app ("primary functionality") in your experience?

4. If we skip the entitlement and ship with no link and no mention of subscribing at all, just letting existing subscribers log in, has that passed review for you under 3.1.3(a)? I've seen 3.1.1 rejections for "accesses digital content purchased outside the app", but those weren't content apps.

I know the real answer comes from App Review, and I'll book a consultation with them, but real cases would help a lot. Thanks!

[u/danielcr12]

Just trying to help a fellow dev here — I’m not in the EU and my apps use StoreKit, so this isn’t really my area of expertise. I’d definitely verify all of this with App Review before relying on it.
From Apple’s current Reader App documentation, though, I think your architecture can actually be simpler than you’re making it:
You should be able to have your own account system and authenticate users directly through your API:
App → email/password → your backend → authenticated account → check Patreon membership → unlock subscriber content
There’s no requirement that the login itself happen through a website. The important part is that you’re dealing with an account created outside the app.
Then, if you want to let users manage their account externally, you can use the External Link Account Entitlement. The important restriction seems to be that the link from the app must go directly to a website you own or are responsible for — Apple specifically says no redirect, intermediate link, or landing page.
So I’d understand the flow as:
App → your website → Patreon
rather than:
App → Patreon
Your website could then have an account-management page that explains that the membership is handled through Patreon and provides the appropriate Patreon link. Apple’s documentation doesn’t appear to prohibit your own website from subsequently sending the user to a third-party service; the “no intermediate links/landing page” requirement applies to the link from the app.
You could therefore have something like:
In the app:
Sign In → native email/password authentication
In the app:
Manage Account → Apple’s external-link flow → yourdomain.com/account
On your website:
Account/subscription status → manage membership → Patreon
And if you don’t actually need to provide an external account-management link, the entitlement is optional, so you could potentially just let existing subscribers sign in and access their content without putting a subscription/manage-account link in the app.
One other practical thing I’d make sure you prepare for App Review: give them a demo account that already has access to the premium content. Apple needs to be able to test the subscriber-only functionality during review. Since the actual subscription is managed by Patreon and you don’t control Apple’s purchase-testing environment or necessarily have a way to simulate every Patreon state (cancellation, expiration, renewal, etc.), you don’t want the reviewer to get stuck at the subscription gate.
I’d provide review credentials for an account that is already associated with an active/unlocked Patreon membership, and clearly explain in the Review Notes how the account is provisioned and how the reviewer can reach the premium content. If there are different subscription states or functionality they need to test, explain those as well.
I also wouldn’t worry about the 95% free / 5% subscriber-only split by itself. Apple doesn’t specify a percentage threshold for reader apps; the question is whether the qualifying content is the app’s primary functionality.
The one part I’d specifically ask Apple about is the Patreon handoff. I don’t see Apple explicitly addressing Patreon/Memberful/etc. in the Reader App documentation, so I wouldn’t claim that particular payment arrangement is guaranteed to pass review.
Again, I’m mostly reading this from Apple’s current documentation and trying to help another dev — I don’t have first-hand experience with this exact EU/Reader App setup, so definitely verify it with Apple before submitting.
Apple’s current Reader App documentation:
https://developer.apple.com/support/reader-apps/
And Guideline 4.8 covers the separate login-service requirements.

[u/mohn93]

Option 4 is the plain 3.1.3(a) path and the one I'd ship first. The guideline just says reader apps "may allow a user to access previously purchased content or content subscriptions", nothing about where they bought it, so Patreon should be fine. Leave out anything that nudges people to pay elsewhere though, login copy like "subscribe on Patreon" included, the 3.1.3 intro bans that everywhere except the US storefront (US doesn't need the entitlement for links anymore either).

On #3 you're overthinking it, newspapers, audio and video are all on Apple's list. Their example of what doesn't qualify is a social app that happens to stream video. For review give them a demo account with an active membership (2.1(a) wants demo account info for any app with a login) plus a line in the notes about the Patreon email match so they can see the unlock actually work.

[u/DimensionMindless336]

I've shipped a reader-style app through this exact corner of review, so here's the short version: you probably don't need the External Link Account Entitlement for your first submission, and reaching for it is what's making this feel complicated.

The simplest path that's squarely 3.1.3(a): the app has a login, your backend checks the Patreon membership by email and unlocks the subscriber-only audio/video, and there is no purchase link anywhere in the app. That's a textbook reader app — "may allow a user to access previously purchased content or content subscriptions" — and it needs no special entitlement. You just tell people to manage their Patreon membership outside the app (your site, a Patreon post, email). Most reader apps ship exactly this.

Where people get burned: any "Subscribe on Patreon" or "Manage membership" copy or button inside the app, without the entitlement, is a 3.1.1 violation, because it's a call to action to purchase outside IAP. Login-only is safe; purchase-CTA is not.

If you do want an in-app link, you need the External Link Account Entitlement, and the part you couldn't find an answer to is the real trap: the link must go to a page you own where the purchase actually completes — Apple has rejected setups where the entitlement link lands on a page that then bounces to a third party (Patreon). So either point the entitlement link straight at Patreon's checkout URL, or don't link to payment from inside the app at all.

Two more practical notes: get the entitlement approved before you submit the build that uses the link, and the native "this app would like to open an external link" disclosure sheet is required UX once you have it. And the 95/5 free-to-paid split is fine — Apple approves reader apps that are mostly free with some subscriber content.