DEV Community: Cathy Lai

Spending Hours Designing the UI? Or Just Telling AI the Pain Story

Cathy Lai — Sun, 31 May 2026 05:21:45 +0000

Now that I get my backend API services in place, it's time to design a frontend! Just describe the mood to AI, right? I did, and it looked... fine. But it didn't feel right. It didn't match the soul of why I was building it.

So, instead of looking at font pairing blogs for three hours, I sat down and told Gemini the personal story and frustration behind the app.

Outdated Garden Styles

I explained that as a busy professional, I felt completely alienated by the gardening world. Every time I looked up gardening advice on YouTube or blogs to fix up my yard, I was met with slow acoustic country music, rambling lectures full of jargons, and an aesthetic that felt like a grandmother giving advice.

It felt old fashioned, inefficient, and totally out of touch with how my peers and I live. For example:

❌ Old fashion garden style

We don't want a chaotic cottagecore wildflower patch that takes six hours a week to prune. Our design references are the sleek tech offices we work in, the boutique hotels we visit, or the trendy cafes with clean gravel, square lawns, structural plants, and warm outdoor lighting. We just want a beautiful, low-maintenance outdoor lounge where we can turn on some music, host a weekend barbecue, and have drinks with friends on a summer evening.

✔ Modern outdoor courtyard

I told Gemini: “I built a tool that takes a messy yard and instantly visualizes that clean, hotel-grade hosting space. Help me pick a font system that talks to these busy professionals, not their grandmothers.”

10 Seconds to the Right Font...!

Main title font "Fraunces"

Subtitle and body text "Inter"

Tailwind Changes

Load Fraunces from Fontshare in global.css

@import url("https://api.fontshare.com/v2/css?f[]=fraunces@500,600,700&display=swap");

  --font-inter: var(--font-inter-family), ui-sans-serif, system-ui, sans-serif;
  --font-fraunces: "Fraunces", ui-serif, Georgia, serif

Apply it on the page title (page.tsx)

            <h1 className="font-fraunces text-5xl leading-[0.95] font-semibold tracking-tight text-[#1f321d] sm:text-6xl">
              GardenViz
            </h1>
            <p className="font-inter mt-2 text-lg font-medium tracking-tight text-[#3a4f35] sm:text-xl">
              Garden Design Visualizer for Busy Homeowners
            </p>

The result

I think it looks quite good! :)

AI as a Collaborator

By treating the AI as a creative collaborator and feeding it the context of a real human frustration rather than just a technical prompt, I got a design system that feels incredibly intentional.

Garden Visualizer - Would Results Improve Using Example Images? (Screenshots Included)

Cathy Lai — Thu, 28 May 2026 04:17:38 +0000

Perfect Prompts Needed?

In creating a garden visualizer to help home owners with their landscape decisions, I assumed that I needed to "program" the text prompt perfectly in order to give good results. So spending time tweaking the text descriptions seems natural.

However, after a few days learning about context engineering, I realised I could just send example images and describe what I like or dislike about them. That makes it a lot easier!! Both for me and for GPT!

"Before" Image

Text prompt

Could you give me an idea of how I could transform this area of the property to have a nicer garden?
Please don't change any of the layout and proportions nor points of view.
Please don't add extra buildings or structures either.

Result

Conclusion: it looks very nice, but quite unrealistic... home owners probably won't be able to know where to start to achieve it!

Prompt with 2 Images as Positive and Negative Examples

Positive example image

Use it as a style guide, eg the realism style, the lawns (restricted and tidy), the sunlight, the homeliness, and simple yet elegant furniture. Not expensive. And not gardening magazine fantasy.

Negative example image

Do not match its unrealistic look, expensive furniture, perfect edges, storybook-like texture.

With 2 images as part of the parameters, I got a more achievable, yet still inspiring image:

I think it has picked up from the positive example: lawns, lighting, realism, and the simple furniture. From the negative, it got rid of the large qualities of flowers, and exclude expensive furniture.

Reference

To easily test different variations, I have a test script

test-image-edit.mjs

// And run it like so:
npm run test:image-edit -- -i public/images/messy_garden2.png --positive public/images/positive.jpeg --negative public/images/too_perfect.jpg -o scripts/output/test_output

This enables me to add images as parameters, so in the future I can play with different variations easily, without changing the source code constantly!

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 Adding People to My AI Garden Images Gave It a Personality (and Attracting the Right Users)

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.