SwiftPatch is the deployment platform for React Native — like Vercel, but for mobile. Ship deploys instantly, skip the App Store, roll back in under 3 seconds, and monitor every deployment. Works with any CI pipeline (GitHub Actions, Bitrise, Codemagic). With 98% smaller deploys and enterprise security, SwiftPatch is the modern CodePush replacement.

Is SwiftPatch better than CodePush?

Yes. CodePush was deprecated in March 2025 when Microsoft shut down App Center. SwiftPatch is the modern mobile deployment platform with 98% smaller differential deploys, automatic rollback in under 3 seconds, Ed25519 bundle signing, staged rollouts, real-time analytics, and CI/CD integrations — features CodePush never had.

How does SwiftPatch compare to React Native Stallion?

SwiftPatch is a full mobile deployment platform, not just an OTA tool. It offers 98% smaller deploys through binary-level diffing, automatic rollback in under 3 seconds, enterprise on-premise deployment, Ed25519 bundle signing, CI/CD integrations, and a free tier with 5,000 deploys/month. Stallion is an OTA library; SwiftPatch is the deployment layer.

How fast can I deploy React Native updates with SwiftPatch?

SwiftPatch deploys in under 60 seconds — just like Vercel deploys web apps. Your users receive updates instantly without waiting for App Store or Play Store review. One command, any CI pipeline.

Is SwiftPatch compliant with Apple and Google policies?

Yes. SwiftPatch is 100% compliant with Apple App Store Guidelines Section 3.3.2 and Google Play Store policies. You can only update JavaScript bundles and assets — native code changes still require a store submission.

What happens if a deployment crashes my app?

SwiftPatch automatically detects crashes and rolls back to the last stable deploy in under 3 seconds. Your users never experience prolonged downtime thanks to built-in automatic rollback protection.

How do I migrate from CodePush to SwiftPatch?

Migration takes under 10 minutes. Run npx swiftpatch migrate and follow the prompts. SwiftPatch automatically converts your CodePush configuration. You get a full deployment platform — not just an OTA replacement.

What is differential patching in mobile deployment?

Differential patching deploys only the changed bytes between versions, not the entire bundle. SwiftPatch achieves 98% smaller deploys using binary-level diffing, reducing a typical 20MB bundle to just 200KB — saving bandwidth and making deploys near-instant.

Yes. SwiftPatch offers a free Starter plan with 5,000 deploys/month and 2 apps. No credit card required. Pro plans start at $49/month for growing teams with 100,000 deploys/month.

Can I self-host SwiftPatch on-premise?

Yes. SwiftPatch offers enterprise-grade on-premise and private cloud deployment infrastructure. Your deploys never leave your environment with end-to-end encryption, Ed25519 bundle signing, and audit trails to meet SOC 2 and GDPR requirements.

How does SwiftPatch compare to Expo Updates and EAS Update?

Unlike Expo Updates, SwiftPatch is a full deployment platform that works with any React Native project and any CI pipeline — no Expo lock-in. SwiftPatch provides 98% smaller deploys through differential deployment, while Expo sends full bundles. Plus on-premise hosting, Ed25519 bundle signing, and advanced rollback controls.

Does SwiftPatch support React Native New Architecture?

Yes. SwiftPatch fully supports React Native New Architecture (Fabric and TurboModules) from version 0.69 and above, ensuring compatibility with the latest React Native apps.

Expo EAS Update Pricing: Cost, Bandwidth & What It Really Costs at Scale

Name: SwiftPatch
Brand: SwiftPatch
Availability: InStock
Rating: 4.9 (48 reviews)

How Expo EAS Update Pricing Works

Expo bills EAS Update based on two things: monthly active users (MAUs) and CDN bandwidth. Each plan includes some of both, and you pay overages when you exceed either limit.

A MAU is a unique user who downloads at least one OTA update that month. If a user downloads three updates in January, they count as one MAU. If they download zero updates, they don't count.

Here's the thing: every OTA update sends the entire JavaScript bundle again. A 12MB bundle means 12MB downloaded, even if you only changed one line of code. There's no differential updates, no patches—just full bundles every time.

Typical Expo Plans

Free: ~1,000 MAUs, ~100 GB CDN bandwidth
Starter (~$19/mo): ~3,000 MAUs, ~100 GB bandwidth
Production (~$99/mo): ~50,000 MAUs, ~1 TB (1,000 GB) bandwidth
Enterprise (custom, often ~$1,000–$2,000+/mo): Larger MAU + bandwidth buckets, still usage-based beyond that

Once you exceed plan limits, you pay per additional MAU and per GB of CDN bandwidth. MAU overages slightly increase your included bandwidth, but once that's exhausted, pure bandwidth billing applies. The per-GB rate varies, but the point is: bandwidth adds up fast when every update is a full bundle.

Real-World Cost Math

Let's look at three scenarios. These aren't edge cases—they're what happens as apps grow.

Small App

10 MB bundle
10,000 users
4 releases/month

Bandwidth per release: 10,000 users × 10 MB = 100 GB

Monthly bandwidth: 100 GB × 4 releases = 400 GB

This fits within the Production plan's 1 TB limit, but you're already at 40% of your bandwidth allocation. If you ship one more release or add a few thousand users, you're into overage territory.

Growing App

12 MB bundle
100,000 users
4 releases/month

Bandwidth per release: 100,000 users × 12 MB = 1.2 TB

Monthly bandwidth: 1.2 TB × 4 releases = 4.8 TB

You've already blown past the Production plan's 1 TB limit on the first release. You're now paying for 3.8 TB of overage bandwidth every month, plus any MAU overages if you're above 50,000 MAUs. This is where the bills start getting unpredictable.

Large App

15 MB bundle
500,000 users
6 releases/month

Bandwidth per release: 500,000 users × 15 MB = 7.5 TB

Monthly bandwidth: 7.5 TB × 6 releases = 45 TB

At this scale, you're in pure CDN billing territory. Even with an Enterprise plan that includes larger buckets, you're paying per-GB for most of that 45 TB. Every release is expensive. Every hotfix is expensive. The cost scales linearly with users and releases, and there's no way around it with full bundle updates.

Why This Hurts

The billing model creates a few problems that aren't obvious until you're living with them:

Hotfixes are expensive. You ship a critical bug fix. It's a one-line change, but every user downloads the full 12MB bundle again. That's fine at 10k users, painful at 100k, and genuinely expensive at 500k.

Users keep re-downloading the same JS. If a user doesn't update immediately, they'll download the same bundle again on next launch. If they're on a slow connection and the download fails, they'll retry. You're paying for bandwidth even when updates don't complete.

Costs grow with users × releases. Double your users? Double your bandwidth. Ship twice as many releases? Double your bandwidth. There's no efficiency gain as you scale. The math is just: users × bundle size × releases = bandwidth.

The unpredictable part is when you hit overages. You're not just paying for the plan—you're paying per-GB for everything over the limit. One busy month with extra releases, and your bill jumps. It's hard to budget when costs scale directly with usage.

How Patch Updates Change This

Differential updates change the math entirely. Instead of downloading the entire bundle, users download only what changed. Most releases are KBs, not MBs.

That same 12MB bundle? If you changed 200 lines of code, the patch might be 300KB. Instead of 100,000 users downloading 12MB each (1.2 TB), they download 300KB each (30 GB). That's 98% less bandwidth.

The large app scenario we looked at earlier—45 TB monthly with full bundles—drops to maybe 900 GB with patches. Still significant, but manageable. And hotfixes? A one-line change might be 50KB instead of 15MB. The cost difference is real.

SwiftPatch supports patch updates. Same 100,000 users, same 4 releases per month, but 98% less bandwidth. The billing becomes predictable because you're not paying for full bundles every time.

Expo EAS vs SwiftPatch: Cost Comparison

Factor	Expo EAS Update	SwiftPatch
Update Type	Full bundle only	Patch updates (90-98% smaller)
Bandwidth per Release	Users × Bundle Size	Users × Patch Size (~2% of bundle)
Example: 100k users, 12MB bundle	1.2 TB per release	~30 GB per release
Cost Predictability	Usage-based, scales with releases	More predictable, lower bandwidth
Hotfix Cost	Full bundle download	Small patch (often <100KB)

Comparison based on typical usage patterns. Actual costs depend on bundle size, user count, and release frequency.

Who Should Care

This pricing model starts to hurt at different scales depending on your release cadence:

Apps over ~50–100k users: You're likely hitting Production plan limits or paying overages. Every release is expensive, and hotfixes add up.

Teams shipping weekly: If you're releasing frequently, bandwidth scales linearly. Four releases per month means four times the bandwidth cost.

Teams doing hotfixes: Critical bug fixes mean full bundle downloads for all users. At scale, that's expensive even if the fix is tiny.

If you're seeing bandwidth overages, unpredictable monthly bills, or hesitating to ship releases because of cost, the billing model is working against you. Patch updates change that equation.

FAQ

Does Expo charge for every update?

Expo charges based on MAUs (users who download at least one update) and CDN bandwidth. If a user downloads multiple updates in a month, they still count as one MAU, but you pay for the bandwidth of each download. Every update downloads the full bundle, so bandwidth adds up quickly.

What counts as a MAU?

A monthly active user (MAU) is a unique user who downloads at least one OTA update that month. If a user downloads zero updates, they don't count. If they download three updates, they count as one MAU, but you pay for the bandwidth of all three downloads.

Why does bandwidth grow so fast?

Because every update downloads the full bundle. A 12MB bundle means 12MB downloaded, even for tiny changes. The math is simple: users × bundle size × releases = bandwidth. Double any of those, and bandwidth doubles. There's no efficiency gain as you scale.

Can Expo apps use another OTA system?

Yes. Expo apps can use SwiftPatch or other OTA systems. You'll need to configure it properly, but it works with both managed and bare React Native workflows. Many teams switch for cost, patch updates, or more control over the update process.

Are patch updates allowed by Apple and Google?

Yes. Both platforms allow OTA updates for JavaScript code changes, whether they're full bundles or patches. You can't modify native code or app configuration, but JavaScript updates are fine. Patch updates are just more efficient—same rules, less data.

Conclusion

If your Expo EAS Update bills are climbing, or you're hesitating to ship updates because of bandwidth costs, patch updates are the answer. SwiftPatch delivers the same updates at 2% of the bandwidth, making your OTA delivery predictable and affordable no matter how fast you scale.

Get started with SwiftPatch for free →