How Indie Apps Avoid Apple's 30% Commission With Web Paywalls

Apple takes 30% of every dollar that flows through in-app purchases. If you qualify for the Small Business Program (under $1M in annual revenue, which covers most indie developers), that drops to 15%. Either way, it is a significant chunk of revenue that goes to a platform for the privilege of processing a payment.

For a bootstrapped indie app at $10,000 MRR, Apple's commission is $1,500 to $3,000 per month. At $50,000 MRR, you are sending $7,500 to $15,000 per month to Apple. That is money that could fund a contractor, cover your marketing budget for the quarter, or simply be profit.

Since 2024, Apple allows apps in the US to include a link to external payment options, following the court ruling in the Epic v. Apple case. But the practical question for indie developers is not whether it is technically allowed -- it is how real apps are actually doing it, what works, and what risks you need to understand before making the shift.

This post covers two proven strategies used by real apps, the financial math behind each, and the critical mistakes that can get your app pulled from the store.

Strategy 1: Web-First Funnel

The most effective approach is also the most straightforward: never send paying users through the App Store at all.

How It Works

Instead of running ads that link to your App Store listing, you send traffic to your website. The full user journey happens on the web:

1. User sees your ad on Facebook, Instagram, Google, or TikTok
2. Ad links to your website (not your App Store page)
3. User goes through onboarding on the web -- account creation, preferences, quiz, whatever your flow requires
4. User hits your web paywall and subscribes via Stripe or another web payment processor
5. User downloads your app from the App Store
6. User logs in with the account they just created and gets full access

Apple never touches the transaction. Your payment processor (typically Stripe) takes roughly 2.9% + $0.30 per transaction. You keep the rest.

Style DNA: A Real Example

Style DNA, a fashion and style recommendation app, uses this exact pattern. Their Facebook ad campaigns drive traffic to their website, not the App Store. Users complete a style quiz on the web, receive personalized recommendations, and hit a paywall for the full experience. Payment happens through Stripe on the website. Only after subscribing does the user download the iOS app and log into their paid account.

The key to making this work is the web experience. Your website needs to do enough to convince the user to pay before they ever open the App Store. That means:

• A compelling landing page that communicates value clearly
• Web onboarding that personalizes the experience (quizzes, preference selection, or initial setup)
• A conversion-optimized paywall with clear pricing and benefits
• Seamless web-to-app handoff so the user does not feel friction when transitioning

This requires more upfront engineering than simply integrating StoreKit, but the financial return makes it worthwhile at almost any scale. Building a web onboarding flow and Stripe integration is a one-time cost. The 27% savings on every transaction is permanent.

What You Need to Build

The technical requirements are not trivial but are well within reach for any indie developer who can ship an iOS app:

• Landing page + onboarding flow: Can be a simple Next.js or static site. The onboarding does not need to be complex -- even a 3-step quiz that collects user preferences is enough to justify account creation.
• Stripe integration: Stripe Checkout is the simplest path. A single API call creates a hosted checkout page. You do not need to build your own payment form.
• Account system: Users need to create an account on the web and log into the same account in your app. Email + password, or magic links, or Sign in with Apple (which works on the web too).
• Entitlement sync: Your backend needs to know which accounts have active subscriptions and communicate that to your app. A simple API endpoint that checks subscription status on app launch is sufficient.

Strategy 2: Link in Bio

If you have an existing audience on social media, you already have a channel that bypasses the App Store entirely.

How It Works

Instead of directing followers to your App Store listing, your social media bio links to your website. Users who discover your app through social content follow this path:

1. User discovers your content on Instagram, TikTok, YouTube, or Twitter
2. User taps the link in your bio
3. Link goes to your website (not the App Store)
4. User onboards and subscribes on the web
5. User downloads the app and logs in

Learna AI: A Real Example

Learna AI is an English learning app with over 215,000 Instagram followers. Their link in bio directs to their website, not the App Store. Users who discover the app through Instagram content -- educational reels, vocabulary tips, learning challenges -- land on the website where they can sign up and subscribe.

This strategy works especially well when:

• You already produce content that attracts your target audience
• Your social followers are warm leads who understand what your app does
• The website conversion funnel is shorter because users already trust you from your content

The critical advantage of link-in-bio over the web-first ad funnel is that the traffic is free. You are not paying for Facebook ads. Your content does the acquisition work, and the web paywall captures the revenue without Apple's commission.

Building Social as a Channel

If you do not have a social following yet, this strategy requires an upfront investment in content. But for many app categories, building a social presence is valuable beyond just commission avoidance:

• Fitness apps: Workout tips, form videos, transformation stories
• Productivity apps: Workflow demonstrations, efficiency tips, system breakdowns
• Learning apps: Bite-sized lessons, quizzes, cultural content
• Finance apps: Money tips, budgeting frameworks, market commentary

The social content serves double duty: it builds your audience for the web paywall funnel AND it provides social proof that drives organic App Store downloads. Users who see your content and then search for your app on the App Store are higher-intent users who convert at better rates.

The Math: How Much You Actually Save

The numbers make the case more clearly than any argument.

At $5,000 MRR

Annual savings vs. 30% tier: $16,200 Annual savings vs. 15% SBP tier: $7,200

At $20,000 MRR

Annual savings vs. 30% tier: $64,800 Annual savings vs. 15% SBP tier: $28,800

At $50,000 MRR

Annual savings vs. 30% tier: $162,000 Annual savings vs. 15% SBP tier: $72,000

At $20K MRR, the web paywall saves you enough annually to hire a part-time developer or fund a full year of paid advertising. The ROI on building the web funnel is clear at almost any revenue level above $2,000 MRR.

The Warning: What Not to Do

This section matters more than the rest of the post combined. The strategies above work because they route external traffic through the web. They do not interfere with users who discover your app through the App Store itself. That distinction is critical.

What Will Get You in Trouble

Directing in-app users to your website for payment. If a user is already inside your app and you push them to a web page to avoid the commission, Apple will notice. This is the fastest way to get your app rejected or removed. The in-app experience should include a standard in-app purchase option for users who found you through the store.

Actively discouraging in-app purchase. Showing a message like "Save 30% by subscribing on our website" inside your app is a direct violation of Apple's guidelines. You are explicitly steering users away from Apple's payment system, and Apple treats this as hostile behavior.

Making in-app purchase intentionally worse. Offering a higher price in-app than on the web (to account for the commission), showing fewer plan options in-app, or adding friction to the in-app purchase flow -- all of these are variations of discouraging in-app purchase and all of them put your app at risk.

Removing in-app purchase entirely. If your app offers premium features, Apple expects an in-app purchase path to exist for users who want it. Removing all in-app purchase options while clearly having a subscription product is a red flag.

What Apple Actually Allows

The nuance is important. Apple's position, post-Epic ruling, is:

• You can accept payment on the web
• You can link to external payment from within your app (in the US, with specific disclosures)
• You cannot actively discourage in-app purchase
• You cannot make the in-app purchase experience intentionally worse than the web experience

The smart approach: keep in-app purchase as a fully functional option for users who find you through the App Store. Use the web funnel exclusively for users who come from external channels -- ads, social media, email lists, your website. These users never saw your App Store page first. They came through your door, not Apple's.

Keep it subtle. Keep it smart. Save thousands.

When This Makes Sense (And When It Does Not)

The web paywall strategy is not universally applicable. It depends entirely on where your users come from.

This strategy works when:

• You run paid ads. If you are spending money on Facebook, Instagram, TikTok, or Google ads, you control where the click goes. Send it to your website instead of the App Store. You are already paying for the traffic -- might as well keep the revenue.
• You have a social media following. If users discover your app through your content, your bio link controls their entry point. Direct them to the web.
• You have an email list or newsletter. Same principle. You own the relationship. Send subscribers to your web paywall.
• You have a website with organic traffic. If people find your app through Google search, blog posts, or landing pages, the web-to-app flow is natural.

This strategy does not work when:

• All your users come from App Store search. If organic App Store search is your primary acquisition channel, those users are already inside Apple's ecosystem. They expect to pay with Face ID and their Apple ID. Redirecting them to a website adds friction and reduces conversion. For these users, in-app purchase is the right choice.
• Your app has no web presence. Building a web funnel requires, at minimum, a landing page and a payment integration. If you have neither and your entire distribution is organic App Store discovery, the investment may not make sense at your current scale.
• Your MRR is under $1,000. At very low revenue, the absolute savings are small ($70-150/month at 15% SBP). Your time might be better spent improving the app and growing downloads rather than building payment infrastructure.

Your App Store Listing Still Matters

Here is the part that indie developers sometimes miss when they get excited about web paywalls: even if you route all your paid traffic and social traffic through a web funnel, organic App Store search still drives the majority of downloads for most apps. Over 65% of all App Store downloads come from search. Those users will never see your web paywall. They will see your App Store listing first.

That means your screenshots, your title and subtitle, your ratings, and your overall ASO still matter as much as ever. The web funnel captures revenue from users you bring to the table. ASO captures revenue from users Apple brings to the table. You need both.

The best approach is not "web paywall OR App Store optimization" -- it is both, working in parallel. Optimize your listing so organic users convert at the highest possible rate with in-app purchase. Build a web funnel so external traffic converts without the commission. Two revenue streams, two optimization surfaces, maximum revenue capture.

Getting Started

If you are convinced the math works for your situation, here is the minimum viable implementation:

1. Build a landing page with your value proposition and a clear call to action. A single-page Next.js site or even a Carrd page is enough to start.
2. Add Stripe Checkout. One API call creates a hosted checkout page. You do not need a custom payment form on day one.
3. Implement account creation on both web and app. Email + password is the simplest starting point.
4. Add a subscription status check in your app that queries your backend on launch. If the account has an active Stripe subscription, unlock premium features.
5. Keep StoreKit in-app purchase working. Do not remove it. Let users who find you through the App Store pay through Apple. Let users who come from your website pay through Stripe.
6. Route your ads and social links to the website. This is where the savings start.

The entire setup can be built in a weekend if you keep it simple. The savings start from the first web subscriber and compound forever.