Cross-platform mobile apps

Features land on the web first.

The Android build catches up later, or it does not; within a year the two products disagree about what a user account is and which of them is right.

Divergence is rarely dramatic. It shows up as a field the web form validates and the mobile form does not, or a permission the Android build asks for and the web build has never heard of.

Each is small. Together they are the reason a bug report has to be answered with a question about which of the two apps the person was actually holding at the time.

The usual answer is to build the thing twice: a web team and an Android team, two codebases and two release cycles. For a small company that is not a staffing problem. It is a maintenance bill that arrives every time anything changes, and it arrives twice.

No iOS.

That limit belongs at the top of this page rather than the bottom. There is no Apple Developer account here, so nothing I build has gone to the App Store; a portfolio that claims a platform it has not shipped to is the first thing a client finds out about.

Android and the web are the surfaces I can take through to release. It is a shorter list than some, and it is the list I can stand behind.

The second constraint shapes the code rather than the platform list. One codebase, one person, and no server kept alive behind it. My name is Ahsan Mahmood, and the person who writes the web screen is the person who packages the Android build and answers the store reviewer.

Capacitor is what makes that work. The React and TypeScript that draws the web app is packaged as an Android application, and native capability arrives as a plugin rather than as a second product.

What is included does not change from project to project.

One codebase, web plus Android. Native capability through Capacitor plugins. Offline behaviour and reconciliation, so a form filled on a train is still there when the signal returns.

Play Store submission material, including the permission justifications and the answers a reviewer asks for. And over-the-air updates, so a fix reaches installed devices without a store round trip.

HabitForge, PregnancyPal, 2FA Studio, CallVault and SMS Mobile App are mobile applications of this shape, and each has its own page on this site.

Offline is the part that gets skipped and then rebuilt. A phone loses signal in a lift, on a train, in a basement car park, and the honest question is what the app does with the half-finished thing in front of the user. The write is queued and reconciled when the connection returns, rather than discarded with an apology.

A queued write needs a rule for what happens when it lands late and the row has moved underneath it. That rule is a product decision rather than a technical one, so it gets made on the call and written down.

Every native branch goes at the call site rather than inside a helper that quietly falls back, and every native plugin sits behind a dynamic import so the web bundle carries none of it. A helper that degrades silently is a defect you meet on a device, in a week when nobody is looking for one.

The cost of one codebase is that every native capability is a second path through the same feature. A camera permission behaves differently on a phone than in a browser tab, and the version that works on the web is not evidence about the one on the device. The device is the only witness.

So the screen gets walked twice.

The second cost is the store. A submission is a queue somebody else owns. The permission set a reviewer reads is the one in the merged manifest rather than the one you wrote, and a plugin can add a permission you never asked for.

Finding that at submission is expensive. Gradle also skips the merge task when it decides nothing has changed. It hands back the previous manifest, which reads exactly like a fresh one, so that file gets re-read with the task forced rather than trusted.

Over-the-air updates take the sting out of small fixes, because the web layer can be replaced without a release. Anything reaching into the native project still goes through the store. The rest waits.

Two limits, stated here rather than discovered later. There is no iOS build, and there will not be one until an Apple Developer account exists behind it. It is a hard limit. Visual design as a standalone deliverable is not offered either, and the third-party subscriptions the finished app needs to run are yours rather than mine.

Thirty days of bug fixes at no charge, and after that nothing is automatic.

The store's review queue is the one date on this page I cannot give you.