Forem: Cathy Lai

A New Way to Look at “Failures”

Cathy Lai — Mon, 30 Mar 2026 09:57:08 +0000

Pursuing Correctness as Developers

As developers, we are trained from school to prioritize correctness. We focus on logic, clean architecture, and passing tests because, in code, being "right" leads to success while being "wrong" leads to failure. Over time, this conditioning causes us to tie our self-worth to being correct, which can become a major hurdle when we transition into building products for the real world.

When we start creating content or apps, the predictable link between effort and results often disappears. We might build something technically perfect that nobody uses, or write something insightful that nobody reads. This feels like a failure in the traditional sense, but in the market, "errors" aren't signs of being wrong—they are simply data points.

A World with no Predefinded Correctness

High-performing developers often fall into a trap where they view a lack of traction as a personal flaw. In programming, a bug is a mistake to be fixed, but in entrepreneurship, being wrong is the primary way you learn. It is important to shift our mindset from "I failed" to "That experiment didn't land," recognizing that frequent failure is a necessary part of the process.

This requires a new definition of confidence. True confidence isn't the belief that you will always succeed; it’s being okay regardless of the outcome. While developers are used to seeing output as validation, we must learn to see it as an experiment. You can care deeply about the work without letting the market's reaction judge your personal worth.

A Billion Dollar Product Emerges from Failures

A classic example of this is the origin of Twitch. Justin Kan initially launched Justin.tv to stream his life 24/7, which didn't succeed as a mainstream concept. However, instead of taking it as a personal failure, he noticed users were interested in the streaming technology itself—specifically for gaming. By viewing the "failed" project as market feedback rather than a dead end, he was able to pivot into a billion-dollar company.

Mindset Shift

Ultimately, we must undergo an identity shift: we are no longer someone who proves value by being right, but someone who creates value by running experiments. This means shipping imperfect things and accepting that we will be ignored or wrong often. By launching/publishing often and observing, we turn failures into data points that fuel long-term growth.

Why Can’t Apple Just Accept a Pull Request for My iOS App? (Top Over-The-Air Update Questions Answered:)

Cathy Lai — Tue, 24 Mar 2026 18:57:50 +0000

App Store, EAS Builds, OTA Updates — Explained

Over the Air Update - Concept

OTA allows us to update our app without rebuilding and resubmitting a new version to the App Store or Play Store.

The app fetches updated code/content from a server
The update will be applied on launch (or in the background)
Users won't need to click "Update".

Questions & Answers

❓ “Why can’t I just deploy the updates like Vercel?”

Because mobile apps don’t run on the servers.

On the web:

Code lives on the server
Users always get the latest version

On mobile:

Code is compiled into a binary
It lives on the user’s phone
Users may stay on old versions forever

❓ “Why does Apple/Google need to review my app?”

Because an app runs on the user’s device and can access: camera, photos, contacts & payments. Apple/Google isn’t reviewing the code like a PR. They’re reviewing:

“Is this app safe and trustworthy for users?”

❓ “Why not just review the code like GitHub?”

Because code doesn’t fully represent behaviour. An app can:

Fetch remote data
Enable features dynamically
Change UI based on config

👉 Apple/Google reviews what users experience, not just static code.

❓ “Why is mobile deployment so slow?”

Because mistakes are expensive.

On web:

Bug → redeploy → fixed instantly

On mobile:

Bug → shipped to thousands of devices
Some users never update

👉 Bugs are persistent, not temporary

❓ “So what problem does OTA (Over-The-Air updates) solve?”

OTA lets us update parts of our app without resubmitting to the App Store.

Instead of:

rebuild → resubmit → wait

We can:

push update → users get it on next app open

👉 It brings mobile a bit closer to web-like iteration speed

❓ “What is the limitation of OTA?”

OTA updates cannot change the native layer. If we add a new native library (e.g., a new camera plugin or a Bluetooth library), we must submit a new build to the App Store.

❓ “Does OTA bypass App Review?”

No.

OTA works within the boundaries of what Apple already approved.

✅ Allowed:

Bug fixes
UI tweaks
Text/content changes

❌ Not allowed:

New core features
Changing app purpose

❓ “So Apple/Google still controls everything?”

Yes — but selectively. Think of it like:

App Store = initial approval of your app’s behavior
OTA = small adjustments within that approved scope

❓ “Why does OTA feel limited?”

Because it was added after the original design. Mobile was only supposed to be:

“build → review → install”

OTA is a layer on top trying to make it more flexible — but the App Store still enforces control.

❓ “Why is Expo so popular for OTA?”

Because it makes OTA simple. Instead of building our own system, Expo gives us:

Hosting
Version control
Compatibility checks
Rollback

👉 Using eas update

❓ “How is this different from Flutter?”

Flutter apps are compiled ahead of time. So instead of OTA:

They rely more on app store updates
and use remote config / feature flags

👉 Less “code updates”, more “data-driven updates”

Note:
While true that Flutter doesn't have an official, first-party OTA solution like Expo Updates, third-party tools (like Shorebird) now exist to bring OTA-style patching to Flutter by modifying the underlying engine.

Comparison with Web's "React Server Component (RSC)"

RSC in web is trying to solve a similar problem, i.e. let server has more control over the code, not the client.

🌐 Web (Next.js)

→ React Server Components

UI generated on server
streamed to browser

📱 Mobile (React Native / Flutter)

→ Server-driven UI + Feature Flags + OTA

sends configs that the app maps to pre-built native components
OTA for small fixes

💡 One-line takeaway

Mobile isn’t slower than web —
it’s optimized for trust and stability, not instant change.

Curious about how Expo OTA Works?

Please watch a short demo below where I added a small paragraph to my entry screen, pushed it the App Store, and confirmed it on a relaunch on my phone.

Step by step notes from the video here.

CI/CD for Mobile Apps Part 1/3 - Know Where Our Code Lives (Web vs Mobile Explained)

Cathy Lai — Thu, 19 Mar 2026 17:41:06 +0000

After a few days of working on CI/CD pipelines for mobile apps enabling OTA ("Over the Air" updates), I realised a few details that feels like just simple settings, but actually are resulted from a complete different underlying model which mobile apps operated under.

Where the Code Resides

Web apps: The Single Source of Truth

For web development, the code lives on the server, with the exception of browser cache where the code did not change from the last time. This means the newer code we pushed will always show up for the users, and every user will have the latest changes.

Mobile apps: Distributed Binaries

Mobile apps, however, the code is compiled into binary and downloaded onto users' phones. The server just hosts the backend services like APIs, user management, and database queries and storage.

When a new update is available (eg layout change, new camera features) the users must "download" it, else they stay on the old version.

The Analogy

So web apps are like electronic billboards. There’s only one version, controlled by us. When we change it, every user sees the update instantly.

Mobile apps, on the other hand, are like printed newsletters. Every user holds their own copy. Some are on last month’s issue, some are on older ones. You can’t "remote delete" the paper in their hands; they have to go out and get the new edition. And if you send them content meant for a newer issue than what they have on hand... it might not make sense (crash).

The "runtime version" Config

This is why we have something like this in our config
app.json

"expo" : {
      "runtimeVersion": {
           "policy": "appVersion" // <--- use app's version (1.0.1)
      },

      "slug": "recipes-collect",

      "version": "1.0.1",  // <--- app version
}

It is telling the update server how to determine which "issue" the user currently has.

There are also other ways to determine this :

    "policy" : "sdkVersion" // <--- Expo SDK version

    "policy" : "fingerprint" // <--- digital signature of the native code

So when we push an Over the Air (OTA) update, the app on a user's phone checks this configuration to decide: "Is this update compatible with the native code I have installed?"

Architecture Diagram

Having this in mind, we will design our pipelines differently from web apps. In Part 2 tomorrow, we will use "EAS Workflow" from Expo to write scripts to automate the deployment.

Challenge: iOS App from Zero to a Friend's Phone in a Different City in 1 Hour

Cathy Lai — Wed, 11 Mar 2026 21:31:59 +0000

I was browsing the Expo website and chanced upon their new product, EAS Launch. It promises a 'one-click' launch to the App Store.

I’ve long thought that someone should build a tool equivalent to Vercel or Netlify for mobile, so I’m very curious to see if it delivers on that promise... ?

The Problem

Traditionally, getting an app on a friend's phone meant: Buying a Mac -> Installing 40GB of Xcode -> Wrestling with Provisioning Profiles -> Understand Build Configs -> Self Doubt ->... Is it working now??

The Solution

Using Expo Launch (EAS) to handle all of the above.

The Goal

Start from scratch using "create-expo-app" npm package, ask Cursor to make a sample app, and end with a Apple invite email on a friend's device for them to install and run.

The Pre-Flight Checklist (Minutes 0–5)

To hit the sub-one-hour mark, I need these ready:

A GitHub account
An Apple Developer Program membership ($99/year).
An Expo account, preferably paid to get in the priority queue ($20 USD per month).
Cursor with minimum AI coding tools
Node.js, bun and relevant libraries installed locally.

NB. No need for a Mac nor XCode

Phase 1: The App Creation (Minutes 5–15)

Run the command:

bunx create-expo-app@latest recipes-collect --template blank

Open in Cursor and create a page by asking it something like:

Please make a nice index screen and put the title on "Recipes Collect". give it a friendly, warm theme, orange based colour scheme.

And to add a nice icon for additional touch.

Plz make a new app icon to replace the default one

The result:

Git Init & Push: Push this to a public GitHub repository.

Phase 2: The Expo Launch Magic (Minutes 15–30)

Navigate to launch.expo.dev.
Copy and Paste the new GitHub link.

Phase 3: The "Coffee Break" Build (Minutes 30–50)

Hit "Launch to App Store."
Wait for the spinners and progress bars.

Phase 4: The Moment of Truth (Minutes 50–60)

App created on App Store (pending for review mode)
Add the friend's email address as the "Internal Tester" of the app.
The email arrives. "Accept" first before the second TestFlight email will be sent.

Install it and have it shown on the phone

Verdict: Did we make it under 60 minutes? Yes, verified!

Conclusion

It certainly is magical, to have the whole process so quick and easy! Almost no code, except for typing a few GitHub commands.

Of course, the use case is limited - one can not have very complicated app (eg requires native build tools, backend services, APIs, etc). And the GitHub repo would need to be configured to allow for EAS access or stay public. But, for rapid prototyping, look and feel, market validation, it seems a good choice.

I will definitely research into it a bit more - and share my findings here!

Video of the whole process

References

EAS Launch : launch.expo.dev
Apple App Store: How to add Internal Testers

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

Cathy Lai — Fri, 06 Mar 2026 02:25:15 +0000

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!

How to Build and Test iOS Apps on a Physical Phone: Adding External Testers (Part 4/5)

Cathy Lai — Mon, 02 Mar 2026 22:08:11 +0000

In Part 3, we invited close friends and colleagues to test on their phones (internal testers). Now it's time to invite the wider audience (clients, investors, etc.)!

External Testers

This is reasonably straightforward. Just go to the TestFlight section, find the Add Group button.

The scroll to the bottom of the page, find the list of Builds. Add the Group to a Build.

Notice that the Status will become "Waiting for Review".

For each new Version, Apple will need a Beta App Review which will usually take 1-2 days. The Builds under a Version, however, won't need the review, provided no significant changes were made to the app's metadata or permissions.

If we make a new Build, we can enabled "automatic distribution" for emails to be sent out. Otherwise we will need to invite the (External Testers) Group every single time. We can set this up at the time we add a Build to our new Group. Refer to App Store Connect Invite External Testers section

Process Flow of External Testers

[ 1. EAS SUBMIT ] -------> (Run 'eas submit -p ios')
   |                     (Sends build to App Store Connect)
   v
[ 2. APPLE PROCESSING ] -> (Wait 5-20 mins for Apple to "process")
   |
   v
[ 3. TESTFLIGHT TAB ] ----> (Create "External Group")
   |
   v
[ 4. ADD TEST GROUP ] ---------> (External Testers to EAS build)
   | 
   v
[ 5. (EACH VER) BETA REVIEW ] -------> (Apple takes 24-48 hours to approve for each version)
   |
   v
[ 6. TESTFLIGHT App ] ------> (Testers get notified via Email)

We will learn to send "updates" (code changes) in our final part!

Prefer to Watch a Video?

Follow me as I walk thru this config process, plus a demo when a user receives an email to use TestFlight - how to download, install, and use our beta app.

How to Build and Test iOS Apps on a Physical Phone: Adding Internal Testers (Part 3/5)

Cathy Lai — Wed, 25 Feb 2026 23:44:38 +0000

Now we have submitted our app to the App Store in Step 2, now it's time to invite friends and family to use it!

Testers Setup

Everyone with an Apple ID can be invited now to test on their phones. The phones' UUIDs don't need to be registered with Apple.

There are two different types of Testers: Internal and External.

Internal Testing

These are usually colleagues in the same company. For sole/indie developers, they can be anyone we wish to invite every time you make a new build during the testing phase. They don't have to have the same email domain as ours.

Step 1: Add as a New User
Add the friend in https://appstoreconnect.apple.com/access/users

Fill up the details and then Invite.

The friend will receive an email from the App Store.

Step 2: Accept via the Email
When they receive an email, Accept the invitation.

Step 3: Add to the Internal Testers Group
If it's the first build, developers must go to the build's Test Information to provide a "What To Test" description.

Go back to our App section, under TestFlight tab and scroll to the top:

Create a New Internal Group:

Then add Testers:

You can check this in the iOS TestFlight Build tab:

Next, we will add External Testers in Part 4!

Video

Here's a video of the walk through.

How I Published My First Tutorial Video in 2 Days instead of 5 Years

Cathy Lai — Tue, 17 Feb 2026 18:30:39 +0000

It has always been in my heart to create video tutorials like those ones I follow on YouTube. But for years, I would: open YouTube Studio, check microphone reviews, compare cameras, and analyze the works of top-tier creators. Then I’d close the tabs, create a large todo list, and produce zero videos.

Everything changed when I shifted to a Minimum Viable Output mindset. I stopped optimizing for ideal production and started optimizing for clarity and speed. Instead of a fancy camera and complex live command execution, I

Used mic and screencast functions on MacBook
Used Notion as my "PowerPoint"
Edited out word gaps with an online tool Gling
Swapped risky live CLI demos for clear screenshots of completed steps
Used no music, no transitions — just teaching.
Made a quick thumbnail with Nano Banana
Only spent the longest time making sure the info are well researched and is verified a couple of times.

Perfectionist vs. Creator Mindset

Feature	The Perfectionist Mindset	The Creator Mindset
Primary Goal	Earning peer respect & looking "senior."	Delivering immediate value to the learner.
Technical Setup	Professional mics, 4K cameras, and lighting.	Notion/Docs, screen recording, and clear audio.
Handling Code	Risky live coding and CLI builds.	Screenshots and pre-recorded, verified snippets.
View of Imperfections	A failure of professional standards.	A natural part of the iterative learning process.
Post-Production	Cinematic intros and complex transitions.	Focus on pacing and information density.
Output Velocity	5 years of "researching" and 0 videos.	2 days of "shipping" and 1 live tutorial.
The Outcome	High standards with zero impact.	Functional clarity with maximum momentum.

The Result

Once I “forced” myself to publish, I felt the new door has now opened for me. I now know where to improve (eg thumbnail, SEO, length, speed, and clarity), instead of guessing. I have clear next steps, and I know I will contiguously make improvements. Nobody laughed, instead everybody applauded me for just getting started:)

The Video

If you’re interested, here’s the result of the video!

How to Build and Test iOS Apps on a Physical Phone: Expo EAS and Apple TestFlight (Part 2/5)

Cathy Lai — Mon, 16 Feb 2026 00:52:45 +0000

In Part 1, we've checked in the React Native code on the GitHub. Now we will build the binary with Expo EAS (Expo Application Service) service.

EAS Build

Production (store-signed) binary

eas build --platform ios --profile production

When prompted, let EAS manage:

certificates
provisioning profiles
signing

This produces an App Store–signed IPA.

Resolved "production" environment for the build. Learn more: https://docs.expo.dev/eas/environment-variables/#setting-the-environment-for-your-builds
....

✔ Incremented buildNumber from x to y.

✔ Using remote iOS credentials (Expo server)

If you provide your Apple account credentials we will be able to generate all necessary build credentials and fully validate them.
...
✔ Do you want to log in to your Apple account? … yes

› Log in to your Apple Developer account to continue
✔ Apple ID: … cathy.xxxx@xxxxx.com
› Restoring session /Users/cathy/.app-store/auth/cathy.xxxx@xxxxx.com/cookie
› Session expired Local session
› Using password for cathy.xxxx@xxxxx.com from your local Keychain
  Learn more: https://docs.expo.dev/distribution/security#keychain
✔ Logged in New session
› Team Cathy Lai (XXXXXX)
› Provider Cathy Lai (xxxxxxxx)
✔ Bundle identifier registered com.cathyapp1234.oauthpro2
✔ Synced capabilities: No updates
✔ Synced capability identifiers: No updates
✔ Fetched Apple distribution certificates
✔ Fetched Apple provisioning profiles

Again the bundle identifier is unique in the App Store.

Project Credentials Configuration

Project                   @cathyapp1234/oauth-pro2
Bundle Identifier         com.cathyapp1234.oauthpro2

Distribution Certificate and Provisioning Profiles are auto generated. It is the "permission slip" from Apple to allow the binary to run on the specific phones.

In the Apple ecosystem, we can’t just drag and drop an app file onto an iPhone like we can with a .exe on a PC. Apple requires a strict chain of trust to ensure that the app is legitimate, created by a verified developer, and running on an authorized device.

App Store Configuration   

Distribution Certificate  
Serial Number             XXXXXXXDA97EA34FFC3B28C8BA6C44
Expiration Date           Tue, 04 Aug 2026 05:10:17 GMT+1200
Apple Team                XXXXXX (Cathy Lai (Individual))
Updated                   6 months ago

Provisioning Profile      
Developer Portal ID       XxXXXXXXXX
Status                    active
Expiration                Tue, 04 Aug 2026 05:10:17 GMT+1200
Apple Team                XXXXXXXXXX (Cathy Lai (Individual))
Updated                   17 days ago

All credentials are ready to build @cathyapp1234/oauth-pro2 (com.cathyapp1234.oauthpro2)

Compressing project files and uploading to EAS Build. Learn more: https://expo.fyi/eas-build-archive
✔ Uploaded to EAS 1s
✔ Computed project fingerprint

See logs: https://expo.dev/accounts/cathyapp1234/projects/oauth-pro2/builds/xxxxxxx

Waiting for build to complete. You can press Ctrl+C to exit.
  Build queued...

Waiting in priority queue
|■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■| 

✔ Build finished
🍏 iOS app:
https://expo.dev/artifacts/eas/xxxxxxxxx.ipa

EAS submit

Then we submit to the same profile.

eas submit --profile production

Follow the prompts to select the correct configs (platforms, etc) :

✔ Select platform › iOS

✔ What would you like to submit? › Select a build from EAS
✔ Which build would you like to submit? › - ID: 5841b2f1-b3c1-4b4b-93d2-b3b587744843 (11 days ago)
Ensuring your app exists on App Store Connect. This step can be skipped by providing ascAppId in the
submit profile. Learn more: https://expo.fyi/asc-app-id

› Log in to your Apple Developer account to continue
✔ Apple ID: … cathyl.apple@gmail.com
› Restoring session /Users/cathy/.app-store/auth/cathyl.apple@gmail.com/cookie
› Session expired Local session
› Using password for cathyl.apple@gmail.com from your local Keychain
  Learn more: https://docs.expo.dev/distribution/security#keychain
✔ Logged in, verify your Apple account to continue
Two-factor Authentication (6 digit code) is enabled for cathyl.apple@gmail.com. Learn more: https://support.apple.com/en-us/HT204915

✔ How do you want to validate your account? … device / sms
✔ Please enter the 6 digit code … 429798
✔ Valid code
✔ Logged in and verified
› Team Cathy Lai (VJ2LKA46QZ)
› Provider Cathy Lai (124547644)

✔ Bundle identifier registered com.cathyapp1234.oauthpro2
✔ Prepared App Store Connect for oauth-pro2 com.cathyapp1234.oauthpro2
Looking up credentials configuration for com.cathyapp1234.oauthpro2...
✔ App Store Connect API Key already set up.
Using Api Key ID: VWQTD6L5L3 ([Expo] EAS Submit MnT3S3wHKr)

ASC App ID:                 6758167617
Project ID:                 a31c0453-d16e-4818-aa19-d380a5bfc5d4
App Store Connect API Key:  
    Key Name  :  [Expo] EAS Submit MnT3S3wHKr
    Key ID    :  VWQTD6L5L3
    Key Source:  EAS servers
Build:                      
    Build ID    :  5841b2f1-b3c1-4b4b-93d2-b3b587744843
    Build Date  :  13/02/2026, 8:36:43 am
    App Version :  1.0.0
    Build number:  7

Then EAS will schedule the submission:

✔ Scheduled iOS submission

Submission details: xxxx
Waiting for submission to complete. You can press Ctrl+C to exit.
⠼

Expo will auto-create the app in App Store Connect

App record created
Bundle ID registered
Build uploaded
Appears in TestFlight

We will add some testers (via emails) in Part 3so they can be notified and get a link to TestFlight to access our app.

Join Me

Watch me build my prototype app and submit it to the App Store!

How to Build and Test iOS Apps on a Physical Phone: Expo EAS and Apple TestFlight (Part 1/5)

Cathy Lai — Tue, 10 Feb 2026 00:53:54 +0000

So you have turned a bright idea into a release-ready iOS app, time to test it properly by friends and family on their physical phones!

This 5-part article will explain how we can go from an app created on our PC/laptop to the Apple App Store, via an app called TestFlight which enables external testers to use the preview version of our app.

The analogy (from this article)

We (the developers): The brand owners
Our app: The product
EAS (Expo Application Service): The manufacturer + logistics company
Apple App Store: The supermarket
TestFlight: supermarket's tasting room. The product (our app) must be "registered" first before it can be entered in this room

Part 1 — Identity & Setup

This part connects your local project, Expo, and Apple so they all agree on your app’s identity.

Step 1/7 : Install and log in to EAS

npm i -g eas-cli
eas login

Step 2/7 : Initialize EAS in your project

eas init

This links your repo to an Expo project.

Step 3/7 : Verify `app.json` (or `app.config.*`)

Make sure these two things are correct:

ios.bundleIdentifier This must match what you’ll use in App Store Connect.

"expo": {
    "name": "oauth-pro2",
    "ios": {
        "bundleIdentifier": "com.cathyapp1234.oauthpro2",
     },
}

extra.eas.projectId This links your local project to Expo EAS.

  "expo": {
     "extra" : {
        "eas": {
           "projectId": "a31c0453-d16e-4818-aa19-d380a5bfc5d4"
        }
      }
  }

Step 4/7: Define build Profiles in `eas.json`

Regardless of a build profile (eg "preview" or "production"), there are two types of builds:

Ad Hoc Build, binary is on Expo :

 "distribution": "internal"

Signed and is permitted to be on the App Store

 "distribution": "store"

We are building the latter so we can download it via TestFlight.

Also, it is useful to auto increment the build number with every EAS build

 "autoIncrement": true,

The eas.json:

{
  "build": {
    "preview": {
      "distribution": "store", 
      "channel": "preview",     
      "autoIncrement": true,
    },

  }
}

The convention is to use EAS remote build number instead of keeping tracks of it ourselves:

{
  "cli": {
    "appVersionSource": "remote"
  }
},

In this system, build number is a single counter tied to your Project ID and Platform (iOS), not to a specific build profile. This means, both

eas build --profile preview

and

eas build --profile production

will both increase the same build number.

Step 5/7: Add the Corresponding submit Profiles

Make sure the entries are available, even if empty. Otherwise the build will give errors.

{
  "submit": {
    "production": {},
    "preview": {}
  }
}

Final eas.json can be found in this GitHub repository.

Step 6/7: Channels and OTA (Over the Air Updates)

Since we have specify different channels for each build profile, we can send code updates (bug fixes, small changes) over the air (OTA) via the channels to phones that already have the app installed, without having to resubmit to the App Store.
You can choose to skip this step, but EAS will give a warning.

Run the followings for this function

npx expo install expo-updates
eas update:configure

Step 7/7: Check into remote GitHub

git push origin main

Next, we are ready to build the binary in Part 2!

Prefer to Watch a Video?

I Lost 2 Hours to an AI Search Answer — Here’s What I Learned About Context Engineering

Cathy Lai — Mon, 02 Feb 2026 04:01:59 +0000

The Issue

Last week, I tried to use Perplexity AI to teach me about EAS Builds. I got thrown off everywhere was confused for a long time! Here're the sequence of questions I asked:

Then

It's all well and good, within the context of EAS Build variations.

Problematic follow-up question

I assumed the below is also within the context of the conversations above, but it gave me a surprising answer:

And the first reference returned was a 2019 article talked about unrelated structure - preview, production and testing branching of the source code on GitHub, not EAS Build config.

What I thought I asked

I’m talking about eas.json
EAS build profiles (development, preview, production)
distribution: "store"
TestFlight vs App Store release

This is a binary signing & distribution question.

What Perplexity answered (what it assumed)

Perplexity cited this article:

How to manage staging and production environments in a React Native app

At first glance, it sounds relevant:

staging vs production
React Native
real-world apps

But that article is about:

environment variables
API base URLs
runtime configuration
feature flags

👉 It has nothing to do with EAS Build, TestFlight, App Store Connect, or signing.

Why Perplexity didn’t “infer” my earlier context

This was the key realization:

Perplexity does not reliably carry context across separate queries.

Each question is treated as a fresh retrieval task:

interpret keywords
fetch high-ranking related pages
synthesize an answer

If most indexed content around “staging vs production” is about environment variables, that’s what it will pull — even if you meant EAS build profiles.

The fix: anchoring the context (aka context engineering)

What actually works is pinning the domain so the AI can’t drift.
Things that help a lot:

naming concrete artifacts: eas.json
naming commands: eas build, eas submit
naming platforms: TestFlight, App Store Connect
explicitly excluding irrelevant meanings

Example of a much better prompt:

I am using Expo EAS. In eas.json, I have build profiles like development, preview, and production.

Explain the difference between a preview build and a production build in terms of signing and distribution (TestFlight vs App Store).

Ignore articles about staging/production environment variables.

Even better: paste a snippet of the eas.json.

Conclusion

There is still some technical details to learn about AI tools, even though it uses plain English and feels "easy" to use! I definitely need to learn more for it to be useful in solving my everyday issues.

Ways to Run Your Expo iOS App on a Physical Phone (Dev, Preview & TestFlight Explained)

Cathy Lai — Tue, 27 Jan 2026 16:11:02 +0000

Introduction

So you have your app running on the iOS Simulator. What to do next to test, preview, and go live on the Apple App Store?

Even though React Native makes mobile development feels like writing JavaScript, the deployment process is nothing like web deployment (one click publishing)! Below is a mental model I found helpful when I published my PlanetFam Quiz app last year.

App Store, EAS, TestFlight, different Builds - an supermarket analogy

The parties involved

We (the developers): The brand owners
Our app: The product
EAS (Expo Application Service): The manufacturer + logistics company
Apple App Store: The supermarket
- TestFlight: supermarket's tasting room. The product (our app) must be "registered" first before it can be entered in this room

The different app builds

To run a React Native app on a physical iPhone without a Metro server, you must package the JavaScript code into an binary (best using EAS)

Build type	Mental model	Runs on	Who is it for?	Typical command
Expo Go	🧪 Prototyping in the lab	Simulator + physical phone	Fast experimentation & learning	`npx expo start`
Development build	🍳 Internal test kitchen	Simulator + physical phone	Real-device testing during development	`eas build --profile development`
Preview build	🧾 Samples / staff or VIP - only stock	Physical phone (via TestFlight)	QA, stakeholders, real-world testing	`eas build --profile preview`
Production build	🏪 Retail-ready packaged goods	App Store / TestFlight	Public users	`eas build --profile production`

Technical requirements

Build type	Expo Go required?	Phone registered with Apple (UUID)?	Local Metro server needed?	Source code in GitHub?
Expo Go	✅ Yes	❌ No	✅ Yes	❌ No
Development build	❌ No	✅ Yes	✅ Yes	❌ No
Preview build	❌ No	No if via TestFlight, Yes if via Ad Hoc Build*	❌ No	✅ Yes
Production build	❌ No	❌ No	❌ No	✅ Yes

Ad Hoc = installing a file directly; TestFlight = installing via Apple’s testing app."

Common confusions

Why a Production Build (+ submit) is needed

The production build/submit step is not shipping your app to users yet. We are doing one specific thing:

Registering your product with the supermarket

That registration creates:

An App Store record
Distribution certificates
Provisioning profiles
Permission for Apple to host any builds of this app

Without that step:

TestFlight doesn’t know your app exists
Preview builds have nowhere to land
Apple has no legal or technical context for your binary

Why are there two QR codes when I build a development/preview version ?

When we run

eas build --profile development

We get this QR code which is the address of our build

Scan the above QR code to install the app (the app icon will show up).

Then when we run the Metro server

npx expo start

The second (smaller) QR code appears. This is the Metro server address.

Scan this smaller QR code to hot reload the code changes.

QR 1 (The Shell): This is the "house" for your app.
QR 2 (The Furniture): This is the actual code/logic moving into the house.

Ready to Start?

Follow me as I deploy an React Native app from beginning to end, step by step, in 7 mins!

Questions

Please comment below and I will try to explain as much as possible..

Reference

How to Build and Test iOS Apps on a Physical Phone: Expo EAS and Apple TestFlight

Forem: Cathy Lai

A New Way to Look at “Failures”

Pursuing Correctness as Developers

A World with no Predefinded Correctness

A Billion Dollar Product Emerges from Failures

Mindset Shift

Why Can’t Apple Just Accept a Pull Request for My iOS App? (Top Over-The-Air Update Questions Answered:)

Over the Air Update - Concept

Questions & Answers

❓ “Why can’t I just deploy the updates like Vercel?”

❓ “Why does Apple/Google need to review my app?”

❓ “Why not just review the code like GitHub?”

❓ “Why is mobile deployment so slow?”

❓ “So what problem does OTA (Over-The-Air updates) solve?”

❓ “What is the limitation of OTA?”

❓ “Does OTA bypass App Review?”

❓ “So Apple/Google still controls everything?”

❓ “Why does OTA feel limited?”

❓ “Why is Expo so popular for OTA?”

❓ “How is this different from Flutter?”

Comparison with Web's "React Server Component (RSC)"

🌐 Web (Next.js)

📱 Mobile (React Native / Flutter)

💡 One-line takeaway

Curious about how Expo OTA Works?

CI/CD for Mobile Apps Part 1/3 - Know Where Our Code Lives (Web vs Mobile Explained)

Where the Code Resides

Web apps: The Single Source of Truth

Mobile apps: Distributed Binaries

The Analogy

The "runtime version" Config

Architecture Diagram

Challenge: iOS App from Zero to a Friend's Phone in a Different City in 1 Hour

The Problem

The Solution

The Goal

The Pre-Flight Checklist (Minutes 0–5)

Phase 1: The App Creation (Minutes 5–15)

Phase 2: The Expo Launch Magic (Minutes 15–30)

Phase 3: The "Coffee Break" Build (Minutes 30–50)

Phase 4: The Moment of Truth (Minutes 50–60)

Conclusion

Video of the whole process

References

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

Limitations

How the Phone Receives the Updates

EAS “branch” feature

Practical Steps

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Live Demo

How to Build and Test iOS Apps on a Physical Phone: Adding External Testers (Part 4/5)

External Testers

Process Flow of External Testers

Next

Prefer to Watch a Video?

How to Build and Test iOS Apps on a Physical Phone: Adding Internal Testers (Part 3/5)

Testers Setup

Internal Testing

Video

How I Published My First Tutorial Video in 2 Days instead of 5 Years

Perfectionist vs. Creator Mindset

The Result

The Video

How to Build and Test iOS Apps on a Physical Phone: Expo EAS and Apple TestFlight (Part 2/5)

EAS Build

EAS submit

Next

Join Me

How to Build and Test iOS Apps on a Physical Phone: Expo EAS and Apple TestFlight (Part 1/5)

Part 1 — Identity & Setup

Step 1/7 : Install and log in to EAS

Step 2/7 : Initialize EAS in your project

Step 3/7 : Verify app.json (or app.config.*)

Step 4/7: Define build Profiles in eas.json

Step 3/7 : Verify `app.json` (or `app.config.*`)

Step 4/7: Define build Profiles in `eas.json`