Forem: Cathy Lai

I Thought My One Sentence Is Creating a Perfect GPT Image; Until I Realized It Had Been Learning My "Taste" All Along

Cathy Lai — Tue, 26 May 2026 10:57:20 +0000

When I first started experimenting with GPT image generation for my Garden Visualizer project, I honestly thought the workflow would be simple:

Upload image
Write one good prompt
Receive perfect result

A prompt like:

“Add low-maintenance shrubs to this Auckland backyard.”

And it works?

Not exactly!…

After weeks of experimenting with ChatGPT app with staging photos, gardens, landscaping concepts, and “future visualizations”, I slowly realized something surprising:

The impressive results I was getting were not coming from a single prompt at all. They were coming from hidden context that ChatGPT had been accumulating throughout the conversation.

The Strange Thing I Noticed

At some point, I could type something incredibly vague like:

“Show after 3 years.”

…and GPT somehow knew:

Which shrubs I meant
Where the lemon tree it was
That I disliked overcrowded gardens
That I preferred realistic suburban styling
That I wanted sparse planting
That I preferred low-maintenance layouts

That was the moment I realized: The “prompt” was not the whole product. The conversation itself had become part of the generation engine.

My Wrong Assumption About the Image Edit API

Initially, I assumed the Image Edit API worked similarly to ChatGPT conversations.

I thought:

the model would somehow “remember”
the AI would learn over time
previous generations would influence future ones automatically

But API calls are usually stateless - which means every request is effectively isolated unless you manually resend the context.

So this:

{
  "users_image": "messy_backyard.jpg",
  "prompt": "plz generate a nicely layout idea for this garden"
}

…actually contains almost no useful information.

The model has no idea:

How dense should be the plants
What realism level
What maintenance standard
What climate
What style direction
Budget constraints

The API is not “remembering”. MY app has to carry the memory.

How About Using Reference Images?

Then I got curious. Instead sending the original image and a pure text prompt, what if I also include example images I liked?

Suddenly the AI had a visual target. Not exact copying — but guidance. The reference image could influence:

density
lighting mood
realism
staging style
color palette
suburban vs luxury feel

And honestly, this may become one of the most important patterns in AI apps going forward.

Not:

“Here is my magic prompt.”

But:

“Here is the style, taste, realism, and emotional direction I want you to follow.”

Final Thought

I started this project thinking:

“The better the prompt, the better the image.”

Now I think a more accurate statement is:

“The better the accumulated context, the better the direction.”

And that subtle difference completely changed how I think about building AI products.

How Putting Faces (Literally) to My AI Garden Images Gave It a Personality

Cathy Lai — Mon, 25 May 2026 06:42:30 +0000

Pure Illustrations

To display rotating images during the long Image Edit API calls to transform users' messy backyards, I have started to create educational gardening tips. At first, they were purely about the landscape itself, like something out of a gardening textbook.

I made before-and-after images like:

Lighting vs no lighting

Technically, the images were useful. But something felt missing.

Then I realized: I wasn’t actually showing who the app was for. Then I tried adding characters into the scenes. Instead of a blank garden, I showed this instead:

Suddenly, the images stopped looking like generic landscaping diagrams and started feeling like lifestyle outcomes.

Who Specifically Am I Helping?

I realized my target users were probably not hardcore gardeners. They are more likely:

Busy professionals in their 30s
First-time homeowners
People with decent income but limited time
People who want a beautiful space without spending every weekend doing hard labor

The garden itself is not really the product.

The product is:

Less stress
Pride in the home
A relaxing lifestyle
Confidence inviting friends over
Avoiding expensive gardening mistakes years later

Adding characters with expressions — stressed, tired, peaceful, proud — made the consequences emotionally obvious within seconds.

Ironically, this lesson had almost nothing to do with programming. But it may end up being one of the most important product decisions I’ve made so far.

The Empathetic App Builder

Because once I truly understand who I'm building for, everything becomes clearer:

The design style
The wording
The examples
The onboarding
Which features matter and which do not

Because instead of building for a vague audience, I was helping one specific person solve real problems in their everyday life.

How I Got Users to Willingly Wait 1 Minute for an API Call (Without Over-Engineering)

Cathy Lai — Sun, 24 May 2026 04:43:34 +0000

AI is Great, But It Takes Time

One of the most awkward parts of building my AI garden visualizer was not actually the AI itself — it was the waiting time.

The image generation API I used could take close to a minute to return a result. From a developer’s perspective, the obvious solutions might be

A loading spinner.
Parallel processing
Try to get the API to return progress during the wait
Experiment with 3 different other models to see which one is the fastest
Simplify the prompt, just show trivia changes
Other clever solutions...??

But none of these is ideal - some of them require days of work and research. But - I haven't even got any users for the app!

Is There Another Way?

Most homeowners using this app are not garden experts. Many feel overwhelmed by messy backyards, overgrown plants, drainage issues, or simply not knowing where to begin. They do not necessarily want to study gardening for weeks. They want quick, practical guidance that helps them feel more confident immediately.

So instead of trying to “hide” the waiting time, I decided to use it.

Rotating Tips

During the AI processing phase, the app now displays simple illustrated garden tips every few seconds — almost like a lightweight PowerPoint presentation. Each screen is designed to be scannable within 7–10 seconds:

Why mulch matters
How tree drip lines work
Why plants fail when planted too close together
Simple before/after landscape ideas

Something like this,

Then use setInterval to display them


    // use setInterval() to display an garden tip every 7 seconds
    window.setInterval(() => {
      setTipVisible(false);

      // use setTimeout to fade in/out 
      timeoutId = window.setTimeout(() => {
        setTipIndex((prevIndex) => getRandomTipIndex(prevIndex));
        setTipVisible(true);
      }, 500);
    }, 7000);

The interesting thing is that users no longer feel like they are waiting. They are learning.

Making the App More Helpful

And I think this taught me an important lesson about software development: sometimes the best solution is not deeper engineering complexity, but changing perspective. Instead of asking, “How do I technically eliminate the delay?”, I started asking, “What would make this minute genuinely useful for the user?”

That shift completely changed the experience of the app.

Ironically, the long API call became an opportunity to strengthen the product’s identity. The app stopped feeling like a simple image generator and started feeling more like a helpful gardening companion.

AI Assisted GUI Took Seconds

Cathy Lai — Fri, 22 May 2026 07:13:38 +0000

One of the biggest surprises in this project so far wasn’t the image generation itself — it was how quickly the UI came together.

Imagine the GUI

Once I've got the command line script working, I wanted to imagine what the actual user experience of the app would look like. Normally, this is the stage where projects slow down. You spend hours adjusting spacing, choosing colors, moving buttons around, trying to make things “feel right,” or waiting for design ideas to form. But this time, using Cursor together with GPT, the process felt completely different.

Just Describe the Atmosphere!..

I simplified the goal down to the absolute minimum: a clean interface with a single upload button. Then I described the atmosphere I wanted — modern, calm, visually polished, and easy for non-technical users to understand. Within seconds, the AI generated the page structure, title, subtitle, layout, styling, background, and even a surprisingly polished upload component. The spacing felt balanced. The typography matched the mood. The visual hierarchy made sense immediately.

Prototype of the app. Before uploading:

After uploading

Momentum to Just Keep Going

What amazed me most wasn’t just the speed, but the momentum it created. Instead of spending days stuck in “design paralysis,” trying to make the app look acceptable before continuing, I suddenly had something that already felt close to finished. That psychological effect is huge. Once the interface looked real, it became much easier to focus on the actual functionality and backend logic.

I’m starting to understand why AI-assisted development feels so powerful for solo developers. It removes a lot of the friction between idea and execution. You no longer need to perfectly visualize every design decision in your head before starting. You can iterate rapidly, react to what you see, and improve from there. It doesn’t replace good design thinking entirely, but it dramatically lowers the barrier to creating interfaces that feel polished enough to build upon.

Did AI "Replaced" the Developers?

The interesting part is that this project is gradually becoming less about “AI replacing developers” and more about AI removing bottlenecks that used to slow developers down. In this case, the UI stopped being a multi-day obstacle and became a 10-second starting point — which meant I could move almost immediately into building the real product.

I will write a backend service with Next.js to call the OpenAI APIs. Excited about what this could become! 😀

"Hello World" OpenAI API Script for Image Edit

Cathy Lai — Mon, 18 May 2026 06:48:09 +0000

Goal

On the day 1 of my garden transformation project, my goal was simple: write a one-file plain JavaScript script that sends a “before” garden photo to the OpenAI Image API, adds a prompt, and generates an “after” photo. I wanted to get this working first as a command-line script before turning it into a proper front-end and back-end app.

A Bump in the Road...

In reality, the first day was less about garden design and more about getting the API call to work at all. I kept running into errors: the wrong image model, input image format (need png), rate limits, and a requirement to verify my identity before using certain models. The documentation was not immediately clear to me about which models required verification, so I had to go through the identity verification process (need Driver's License, and to turn my head up and down and around in front of the laptop camera) and top up my account with $5 USD before I could continue testing.

How About Just a Hello World?

Because of that, I simplified the problem even further. Instead of trying to edit a garden photo straight away, I wrote the smallest possible script: just call the API with a simplest one-line prompt. No uploaded image. No garden transformation yet. Just prove that my local JavaScript setup, API key, model name, and response handling were working.

Finally, I got the simplest version working - just add a cat in the garden using the most basic image model "gpt-image-1.5".

It really just the simplest script

node test_garden.js

If you're curious, here's my GitHub. Please note that OpenAPI API Key will be different for each person and I have mine in a private .env file.

pscientist / garden-ai

Ez Garden Visualisation - Command Line version

garden-ai

Ez Garden Visualisation - Command Line version

View on GitHub

Result

Before

With the prompt "Please add a cat walking in the garden.", I've got

Happy with the Progress

So Day 1 of the garden transformation script was really about reducing the problem until it became solvable. Before building the full app, I needed to confirm the smallest moving part: can JavaScript call the OpenAI Image API and return an image? Now that the answer is yes, the next step is to write a proper app and to use real prompts.

Another advantage of having this simple command line script is that experiments of the API calls is now easier - I can now play with different image models, prompts, and see which ones will return the best result in ths shortest amount of time.

I will start drafting up a Next.js app to build a frontend so that the shape of the app will become clearer in my head:) I planned to write my own RESTful APIs to make calls to OpenAPI services!

Reference

The project background story.

From the Concept to Reality: Building "Ez Garden Visualizer" in Stages

Cathy Lai — Wed, 13 May 2026 04:08:52 +0000

So Many Possibilities... So Little Time

When I first thought about building an AI garden visualizer app, the full idea sounded much bigger than a weekend project: upload a garden photo, generate a transformed version, suggest plants, estimate cost, maybe save projects, maybe support users, maybe turn it into a mobile app. That is exciting, but also dangerous, because it is very easy to start building the “final architecture” before proving the core workflow. So I decided to build it in layers: first a tiny command-line prototype, then a simple Next.js app, then cloud functions and storage later.

One Goal for Each Week

For week one, the goal is only to prove the basic AI workflow with a plain JavaScript file. No frontend, login, database, nor a cloud storage. Just one image in, one AI garden concept out. The command line version might look something like this:

node garden-transform.js ./input/backyard.jpg

The pseudocode is intentionally simple:

// garden-transform.js
const imagePath = process.argv[2];
const prompt = `
Transform this garden into a tidy, low-maintenance,
affordable makeover concept.
Keep the original layout and proportions.
Suggest easy-care plants, mulch, edging, and simple seating.
`;
const imageDescription = await describeImage(imagePath);
const gardenPlan = await generateTextPlan({
  imageDescription,
  budget: "$500-$600",
  style: "tidy, homely, achievable"
});
const afterImage = await generateGardenImage({
  originalImage: imagePath,
  gardenPlan
});
saveFile("./output/garden-plan.txt", gardenPlan);
saveImage("./output/garden-after.png", afterImage);

For week two, I would wrap the prototype inside a very small Next.js app. The goal is not to build the whole product yet. It is just to make the prototype usable through a browser: upload a photo, click a button, see a result. The folder structure could stay very minimal:

garden-ai-app/
  app/
    page.tsx
    api/
      transform/
        route.ts
  components/
    ImageUploader.tsx
    ResultPreview.tsx
  lib/
    openai.ts
    prompts.ts
  public/
  package.json

The frontend flow could be as simple as:

// app/page.tsx
export default function HomePage() {
  return (
    <main>
      <h1>AI Garden Makeover</h1>
      <p>Upload a garden photo and get a simple makeover concept.</p>
      <ImageUploader />
      <ResultPreview />
    </main>
  );
}

And the API route could reuse the logic from week one:

// app/api/transform/route.ts
export async function POST(request: Request) {
  const formData = await request.formData();
  const image = formData.get("image");
  const gardenPlan = await generateGardenPlan(image);
  const afterImage = await generateGardenImage(image, gardenPlan);
  return Response.json({
    plan: gardenPlan,
    imageUrl: afterImage
  });
}

What I like about this staged approach is that each week has a clear outcome.

Quick Goals

Week one proves the AI workflow.
Week two proves the user experience.
Week three can then move the image storage and processing into proper cloud services.

The important part is also knowing what not to build yet: no authentication, no payment system, no project dashboard, no plant database, and no perfect architecture. At this stage, the goal is momentum. Build the smallest useful layer, learn from it, then add the next layer only when the previous one works.

Reference

See the app's background story.

Dream Outcome

Here's another inspiring ChatGPT transformation :)

How I Stopped Despairing Over the Backyard Mess and Started an AI Side Project

Cathy Lai — Mon, 11 May 2026 02:21:29 +0000

Back-breaking, Expensive Backyard Clean Up

After spending weeks of labour and money cleaning up areas of the garden that had been poorly planned by the previous owner of the house, I started thinking: there must be a better way. It must feel exciting at first to buy plants for a blank backyard, but a few years down the track, things can become huge, messy, and expensive to maintain. Hundreds or even thousands of dollars may need to be spent just to begin fixing the problem. Some plants even come back more aggressively after being trimmed. With very little expertise in landscaping or garden design, I eventually ran to AI for help...

Could AI Help?

What I did was feed a photo of the space into GPT and ask it to transform the garden — within a reasonable budget — into something tidy, hotel-like, but still warm and homely. What I got back was a very pleasant surprise.

What I didn’t expect was the emotional reaction it triggered: suddenly, I could actually picture this chic, functional outdoor space, and it felt achievable. It’s like what people say — “once you see it, you can’t unsee it.”

What If I Write an App from This Idea?!

With the sense of adventure, I've decided to write an app which uses this ChatGPT functionality. I can see so many uses of such ideas: not just landscaping, but also house renovations, room decors, shopping help, etc...

The simplest version of the tool will be: someone uploads a garden photo, describes the style or maintenance level they want, and receives both a visual concept and practical planting suggestions. This article is entry #0 — discovering the problem and realizing there may be a useful solution here. In the next few days, I’ll start experimenting with the OpenAI API tools and learning how to generate these visual transformations programmatically!

See Day 1 of my development journey!

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!