"over the air" updates for universal enterpriseProvisioning situation

Expo Application Services (EAS)
1

I have a question about over the air updates with eas. I am doing a build for our internal organization app like so:

eas build --profile new --platform all

    "new": {
      "channel": "next",
      "android": {
        "buildType": "apk"
      },
      ios: {
        "enterpriseProvisioning": "universal",
        resourceClass: "m1-medium"
      }
    }

When done building we load up these two install files (apk and ipa) as links on our internal company website, allowing users to download the app. This works as expected and users are able to download, install, and run the app without issue for both iOS and Android. To be clear, we are not on either app store.

The question I have is around “over the air” updates. My understanding was that with expo build, all subsequent builds that only included changes in local JavaScript (i.e. no library changes or updates) would be sent to users’ phones. And that after two cycles of logging in the latest updates would be applied.

So my question is: after making minor JavaScript changes within the app, will running eas build --profile new --platform all again, after the users’ have already downloaded the app, push changes to users’ phones, without requiring them to re-download the install file, or is something else required? Or am I misunderstanding something about the process? Is this a case where I need to use eas update – even though we’re not on the app stores? How can I ensure users get minor updates to the app without them having to download the entire file again from our company website? Thanks!

2

Hi @darrenbrett

The classic expo build used to do an automatic expo publish before building which would have the side effect of making an OTA update available to other apps that were compiled with the same SDK version.

The new EAS Build does not do an automatic eas update, so just building a new app will not make an OTA update available to existing apps. Also, because you can include native code and also because EAS Build does not include the whole Expo SDK in every app and you might have added something in the new build, you can’t blindly rely on the SDK version to know whether an OTA update will be compatible. See Runtime versions and updates

Also, OTA updates are not linked to the App/Play stores.

So yes, you will need to eas update in order to get minor updates deployed to the existing apps.

This behaviour is the default, but if you want to you can have the app check for updates manually. e.g. you can run a check when the app comes to the foreground to see if an update is available, and if so you can download it. Then you can show a “Restart” button to restart the app with the new update. If you do this you might want to keep track of when the last “check for updates” was run and only check again if enough time has passed instead of doing it every time the app comes to the foreground.

1 Like
3

Thanks for the info! And to clarify, do I specify the channel or profile as part of the eas update command? In other words, if my initial build was triggered with this command: eas build --profile new --platform all, what would a subsequent eas update command look like if I want to target that same build config? Thanks!

4

You can specify the channel and branch, but not the profile.

Check the output of eas update --help

I am still more familiar with expo publish than EAS Update, but I think the following should help: Deployment patterns

1 Like
5

Thanks, from what I understand then, this should work based on my config in eas.json (listed above) and based on my initial build command (listed above):

eas update --channel next --platform all

6

I think so. I think it would be best to test it out on a test app. You should be able to do this with an ad-hoc distribution build if you don’t want to use Enterprise distribution for the test app.

1 Like
7

Sorry, as per wkozyra’s message on your other thread, I think you’ll need something like this rather:
eas update --branch next --platform all

Note: wkozyra is an Expo team member, so if what he says contradicts something I said, you should rather believe him :slight_smile:

I’m just reading through How EAS Update works again and I understand it like this:

  • When you build an app, you assign it to a channel. When it checks for updates it fetches them from that channel. You cannot later change which channel the app fetches updates from (The platform and runtime version of the app also take part in determining whether an update will be made available to the app.)
  • When you run eas update you are pushing the changes to a particular branch
  • By default the channel will be linked to a branch of the same name, but you can change the channel to point to a different branch

The explanation in Matching updates and builds explains the default linking between channels and branches where you always have a channel pointing to the branch of the same name. It also explains another possibility where your branches are called version1, version2, version3 and you point the “production” channel at the “version1” branch. Later you point the “production” channel at the “version2” branch, etc.

It takes a bit of re-reading to wrap one’s brain around this :sweat_smile:

1 Like
8

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