How to Build and Test iOS Apps on a Physical Phone: Sending Updates (Part 5/5)

Now that we have our app on TestFlight, and gotten the testers feedback (in Part 4), we can now send the fixes!

The best way to do this is to use Over The Air (OTA) updates, which bypasses Apple’s Reviewing system so the users get instant changes.

Limitations

Using EAS update is good for JS updates, but not for native code changes. So, if something does not require a new Build (eg eas build), then we can send the new code using this method.

Tip: Apple’s guidelines allow OTA updates for bug fixes/minor features, but using it to significantly change the app's purpose can get an account banned.

How the Phone Receives the Updates

Unlike a website, where the updates can be patched onto the server for the users to receive them; the app is a binary already compiled and only lives on users’ phones. Therefore, a few things we need to check:

• What is the version of the user’s binary? (i.e. “runtime version”)?
• What “channel” is this binary? We can only send the updates if it’s the correct channel

Note that the users will need to relaunch the app to receive the updates.

So here are the config files setup:

eas.json

"build": {
     "production": {
      "autoIncrement": true, 
      "distribution":  "store", 
      "channel": "production"   // <--- this is the channel
    }
  }

  app.json

  "expo" {
      "runtimeVersion": {      // <--- this is the runtime version
          "policy": "appVersion"   // <--- use app version (eg 1.0.1) 
    },
  }

Tip: if using appVersion as the policy, we must increment the version number in app.json for every new store build, or the updates might not link correctly.

EAS “branch” feature

EAS allows for an easy way to switch between different versions of the updates using “branches”. This is handy for

⚡ Instant rollback

⚡ Gradual rollouts

⚡ A/B testing

⚡ Switching update streams

All without rebuilding the app.

We can think of our user’s phone as a receiver like a TV and its frequency:

TV Concept	Expo / EAS Concept	Meaning
TV	Installed mobile app build	The binary installed on the user's phone
Channel frequency	Branch / Channel	Which stream of updates the app listens to
Broadcast format	Runtime version	Is the update compatible with the binary?
TV broadcast	OTA update	The code pushed to users
No signal	Update not received	Build ignores incompatible update

Practical Steps

Now that we understand the concepts, the process should be easy.

Step 1

Check the app.json and eas.json are set up properly (see above) on the channel and run time version policy.

Step 2

Make changes to our RN codebase - make sure no native modules - and push it to GitHub

git push origin main

Step 3

Install and configure eas-update

npx expo install expo-updates

eas update:configure

Step 4

Make sure the “channel“ of our build maps to the correct EAS update “branch”

Channel = compiled into our build, and listens to whatever is connected to it

Branch = can be mapped into a channel. This can be changed even when app has already launched - to test new features, etc without needing the users to re-download the app, eg for A/B Testing.

To match production channel to a production branch:

eas channel:edit production --branch production. 

Step 5

Send the updates (optional msg)

eas update --branch production --message "small paragraph" 

Step 6

Check the app again by relaunching it.

Live Demo

Watch this 3 mins video as I demo all the steps and see the instant changes on the phone!