One codebase, three apps: web, iPhone and Android

What the client needed

My client needed a customer area on the web and, at the same time, an app in the stores for iPhone and Android. The web app already existed: it had been built on Lovable. Behind it was the client's company system, with responses and authentication all of its own.

Why the traditional route didn't pay off

The traditional route leads to three products: the website and two native apps. That means three codebases, three release cycles and features that sooner or later stop matching.

On top of that, each version would have had to talk to the company system on its own and deal with its formats and its slow moments.

How the same web app reached the stores

I published the web app as an iOS and Android app with Capacitor and put a Laravel backend between the apps and the company system.

• The same web app, in the stores too. I published the web app as an iOS and Android app with Capacitor: one codebase for three channels.
• A layer in front of the company system. A Laravel backend talks to the client's system on the app's behalf and always returns responses in the same format.
• Fault tolerance. If a call fails, the layer retries; if the system doesn't respond, it protects itself instead of piling up errors.
• Queued synchronisations. Synchronisations go into a queue, so the app doesn't get stuck, and failed ones are recovered.
• Notifications and payments in the backend. The sensitive parts live on the server, away from the app installed on the phone.
• A check on mobile builds. A store build pointing to the wrong environment is blocked before it goes out.

What has changed

• Web and the iPhone and Android apps come from the same code.
• The apps are in the stores and in use.
• All calls to the company system go through a single point, which speaks for all three versions.

What you can take away

• Before writing a native app, ask yourself whether your web app is already enough.
• If the app talks to a system you don't control, put a layer in front of it that standardises the responses and handles its difficult moments.
• Payments and notifications are better off on the server than on the phone.
• A configuration error is better prevented with an automatic check than by relying on people paying attention.

Details have been changed to protect the client's confidentiality.