DEV Community

Cathy Lai
Cathy Lai

Posted on

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

#cicd #mobile #ota #devops

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
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Or

    "policy" : "fingerprint" // <--- digital signature of the native code
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)