EAS update pricing

With the new pricing scheme charging for eas update per user, how do I determine how many active users I have? I have a free app with around 10k users that I update a lot, and am not looking forward to paying $50+ per update. I’d like to know the price before I run the update. Will old apps have the old pricing scheme grandfathered in?Thanks!

hey there! if you sign up for the production plan ($99/mo) this will cover you for updates to up to 20,000 monthly active users, in addition to priority on builds and other benefits. no charges on top of that. scroll down to the “save with eas plans” section on Expo Application Services (EAS) Pricing

Hi @marchingband, I’ll try to answer your questions. We currently show how many active updaters you have on your Usage page but don’t yet have a way to see how many active users you have. We’re planning to show both updaters and users so you can predict your usage ahead of time and aren’t quite there yet since EAS Update is still a brand new service.

Updaters vs users: an “updater” is a device that not only checked for an update but actually downloaded one, while a “user” is a device that might have only checked for an update. This is an important distinction because with EAS Update you pay for updaters – only for users who received an update.

Example: you have 10k users who already got your latest update last month and you don’t publish any updates this month so none of your users download an update. In this case you’d have 10k users but 0 updaters and your cost would be zero.

Pricing: I also wanted to reaffirm that the pricing is based on updaters, not the number of updates. If you have 10k users who receive updates, your total cost would be $45/mo plus extra bandwidth/storage if you use more than the included allotment.

The Free tier comes with 1k updaters/mo, 100 GiB/mo of bandwidth, and 20 GiB of storage. An extra 9k updaters would cost $45/mo and come with an extra 351 GiB/mo of bandwidth.

We designed this pricing this way to encourage developers to publish many times and eventually get web-like CI/CD for mobile.

Predictability: you bring up a great point that you want to know the price before you use the service. I mentioned that EAS Update is still very new and we’re working on improving charts and giving you more visibility, predictability, and control over your usage. Especially while the service is still new if you are a making a hobby app and your usage spikes overnight because your app got unexpectedly popular for a hot minute, tell us so we can work with you and figure out a bill that feels fair and reasonable.

Prior pricing: I’m not sure the pricing you’re referring to so I’ll give this answer my best shot. During the EAS Update preview (before general availability, the official launch), we didn’t charge for usage since the pricing was still under development and customers didn’t have a way preview their invoices. The current pricing on Expo Application Services (EAS) Pricing is the first official pricing we have for EAS Update and there isn’t legacy pricing for EAS Update for any customer.

Separately, there’s the Classic Update service (expo publish), which is separate from EAS Update and uses an older updates protocol. This service had no charges and is a different product from EAS Update.

I think the above implies the following, but it doesn’t seem to be stated explicitly: I assume that it doesn’t matter how many times you publish an update during a single month (as long as you stay within the bandwidth/storage limits). i.e. If you have < 1000 updaters updating once a month or 100 times a month, it will be covered by the free plan.

1 Like

Separately, there’s the Classic Update service (expo publish ), which is separate from EAS Update and uses an older updates protocol. This service had no charges and is a different product from EAS Update.

Hi! But we will not be able to use expo publish after January 4th 2023, right? I live in a third world country and there is not way I can pay $100 for each OTA update. I sometimes publish once or twice a week.
I guess I will be building and uploading to the store from now on then.
Thanks.

As far as I understand it, no. I believe you’re thinking of expo build which is separate from expo publish. I can’t find it now, but I believe one of the Expo team members posted recently to say that they do not currently have any plans to decommission expo publish, and that they would give ample warning before doing so.

Also, with a bit of work you can implement your own update service using Expo’s code as long as you don’t try to sell that service to other people. If you do this you would not have to pay Expo for the updates. However, you’d need a place to host this service.

Hi @wodin thanks for getting back to me

So, I can use eas build + expo publish, right?

I got this email back in May:

Eight months left to migrate from
expo build to eas build

If you’re currently using expo build (the Classic Build service) to build your apps, you’ll need to make some changes this year. Last November, we announced the timeline for expo build’s final year in this post. Many developers have already updated their apps to use eas build, which supports custom native code, can create apps up to 10x smaller, and is the service the Expo team will be working on moving forward.

The Classic Build service will continue to run through January 4, 2023, after which only EAS Build will be active. Please see this blog post for more info on EAS (Expo Application Services).

In the meantime, Classic Builds will work on projects that use SDK 44 (latest), SDK 45 (coming soon), and 46 (planned for summer), but not on projects built with future SDKs. Projects that use SDK 47 or higher will need to do one of the following:

  • “prebuild” Android Studio and Xcode projects and compile them locally,
  • migrate to EAS Build, or
  • use EAS Build’s local runner (eas build --local),

depending on which option works best for you and your team. Please contact us with any questions or concerns as you plan for this change.

Happy developing!

— The Expo Team

Yes, I believe so. I am sure it worked when I tried it not long ago.

Yes, that’s specifically about expo build and is not about expo publish.

If you run expo-cli publish it will probably warn that you should switch to eas update, but you can ignore that.

1 Like

The Classic Build service, which was invoked with the old Expo CLI’s expo build command, will stop working after January 4th, 2023. This was communicated in this post, which has lots more details. EAS Build is one of several options that replace Classic Builds.

The Classic Update service, which was invoked with the old Expo CLI’s expo publish command, will still continue to work past January 4th. We have not yet finalized what maintenance mode will look like for Classic Updates. Existing apps in the stores will continue to work, of course. For new app builds, EAS Update is one option that replaces Classic Updates.

EAS Update’s pricing is per device that receives updates during a billing period. The cost to publish one update per month to your end users is the same as the cost to publish one update a day to the same number of users, provided your updates fit in the amount of bandwidth that EAS Update automatically includes for you. In other words, pricing is per device, not per update.

Understood. Will check the post.

Ok, but I think that certain constants and values like releaseChannel are lost when compiling with EAS but are back when publishing with EXPO. I have to do more tests, but it seems that, in my case at least, certain things break because a few values are undefined. Is this possible?

Ok, so every month I will have to pay the same as long as each update reaches the same amount of devices. If a I publish to 10.000 devices 2 times or 10 times, it will be the same costos, unless bandwidth, etc. Ok, good to know.

Thanks for your response. The only remaining problem for me is the abilitiy to access manifest and channel in both cases.

I compile my app for different customers, with a different name and logo, by setting custom props in app.config.js, these values should always be accessible. But now I also have the eas.json file. Is there any guide on how to merge this? I need to eas build and expo publish being able to access those values in both cases. Thanks!

EDIT: sorry, maybe I should have created a new post.

EDIT2: Environment variables and secrets in EAS Build - Expo Documentation

Constants: Most of the fields that are in classic update manifests are present with modern updates. Make sure you are using Constants.expoConfig instead of Constants.manifest.

Channels: Classic Updates’ release channels are replaced with a more flexible pair of concepts, namely, channels and the more advanced concept of branches. The two of these together support a wide set of deployment patterns explained here: Deployment patterns - Expo Documentation

eas.json: This file configures how you use EAS Build, Submit, and Update. It doesn’t configure your app itself. Configuration that affects your actual app goes in app.json or app.config.json, so there’s no need to merge eas.json into your app (nor should you, since it is meant to configure how you use EAS).

Ok thanks for clarifying!

Is eas.json the place to specify the name of the Entitlements group name? After eas building, the secureStore is not accessible (or it’s empty, maybe a new one).
It might be related to the app not knowing how to name the Entitlements group? It used to be ExpoKitApp.app/ReverseDomain (being ReverseDomain me reversed bundle id). But now it’s the name of my app instead of ExpoKitApp.
Thanks!

I think you accidentally replied to the wrong thread. I assume you meant to respond here:

About the entitlements: I don’t know too much about them, but I suppose they’re specified in app.json if necessary:

See also: iOS Capabilities - Expo Documentation

Hi, I tried replying here just in case there was something missing on the eas.json file that was preventing the app from accessing the secureStore.
Thanks!

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.