What OTA updates actually cost at scale: MAUs, bandwidth, and the bill nobody models

Nobody reads an OTA pricing page and does the multiplication. Then the app grows, the team starts shipping weekly, and finance asks why the update bill has a comma in it. The math is genuinely simple — three numbers — so let's actually do it.

Numbers below reflect published pricing as of mid-2026 and will drift. The point is the method, not the snapshot — rerun it with current figures before deciding anything.

The three numbers

• Active users — how many devices check for and download updates in a month.
• Update size — what a device actually downloads per update. Full bundles for React Native apps commonly run several megabytes to tens of megabytes; diffed or patch-based updates can be a tenth of that or less.
• Release cadence — how many updates a typical user downloads per month.

Monthly bandwidth is just the product of the three. A 50,000-user app shipping four 5 MB updates a month moves roughly a terabyte. The same app with 500 KB diffs moves about 100 GB. That order-of-magnitude difference is why every vendor suddenly markets diffing.

How MAU billing works, using EAS Update as the example

Expo bills EAS Update on two metrics: monthly active users and global edge bandwidth. A user counts once per billing period if they download at least one update; users who only check but download nothing do not count. Each plan includes an allowance of both, and extra MAUs and bandwidth can incur usage-based charges. Check Expo's current pricing page before using any dollar figure in a forecast.

The important property of the MAU part is what it correlates with: your audience, not your activity. A user who downloads one update and one who downloads twenty still count once for MAU, but every additional download can add bandwidth. So daily and monthly shipping can have the same MAU charge while producing very different total bills once bandwidth approaches or exceeds the included allocation. That is great for teams that ship constantly with small updates and rough on teams with a big install base, large bundles, or both.

Three worked profiles

• Side project, 2,000 users, ships weekly. Every model is effectively free or near-free here. Choose on workflow fit, not price.
• Growing consumer app, 80,000 users, ships twice a month. This is where MAU tiers jump: you've cleared the mid tier and are into enterprise-ish territory on audience alone, while your actual bandwidth (80k × 2 × a 1 MB diff ≈ 160 GB) is modest. You are paying for headcount, not traffic.
• Agency running 15 small client apps. Per-app or per-organization tier structures dominate the bill; the per-user math barely matters. Ask vendors directly how multi-app accounts are priced — this is the profile pricing pages describe worst.

The costs that aren't on the pricing page

• Update size discipline. Bandwidth overages are a function of your bundle habits. An accidental 4 MB image in an update, shipped to half a million devices, is a real line item. (How big can a bundle get before it hurts?)
• Failed adoption. Updates that download but never apply still cost bandwidth. If a chunk of your fleet is silently stuck — a surprisingly common condition — you pay for delivery without getting the fix.
• Self-hosting's fake zero. Running your own update server makes the SaaS line item disappear and replaces it with engineer time and on-call. We priced that out separately in the self-hosting cost breakdown.

Where we stand

BetterCodePush is free during the public beta, so the honest disclosure is that we haven't published final pricing yet. The position we're building toward is that cost should track what the service does for you — delivering updates — rather than taxing audience size. When we publish numbers, this post's arithmetic is exactly how we'd suggest you evaluate them, and us against anyone else. Run your own three numbers first; the right vendor falls out of the multiplication more often than out of the feature matrix.