The goal of textreceipts.com is to have zero friction and zero barrier to entry.
It’s an app you can use without installing an app (you can literally use the app via sms, email (work in progress), or a web browser. It’s actually so easy it may confuse users!
Under the hood, textreceipts is a responsive web app that looks and behaves like a native app (and also interacts via text and email). But it needs “native” apps for all kinds of good reasons, so how to accomplish this while providing the best possible user experience and leveraging my engineering team’s — that is to say my — limited time?
Originally, I figured I’d use Apache Cordova (with which I have some experience) to wrap the web app. At first it seemed like it would be easy. But, I’m relying heavily of Google’s Firebase and those libraries do not behave nicely inside Cordova. You need to use specific Cordova extensions wrapped around them, and so I set it aside figuring I would deal with it later.
Today, I wondered “how hard would it be to just create a native app, put a webview in it, and load the site?” (and how well would this work?).
Well my first effort consisted of firing up XCode, creating an app, and trying to replace the “Hello world” label with a webview using autocomplete. Unfortunately, I could not guess my way to the right constructor because I hadn’t actually imported it. 5 minutes wasted!
So I googled “SwiftUI adding a webview”, found this helpful article, and modified the 20loc or so of example code to suit my needs and I have a fully-functional “native” app.
Obviously, this app won’t handle being completely offline gracefully (at least, until it has had a change to load once, so a slightly more sophisticated version would, say, display an offline warning instead of the webview when appropriate. I’ll worry about that later.
What about accessing functionality not exposed by the web browser or ensuring the web app has the right permissions? In simple terms, textreceipts doesn’t currently rely on access to any functionality it can’t get at from standard web APIs, but in any event, based on what I’ve seen, it would be easier to simply handle that stuff natively (on both iOS and Android) than deal with Cordova’s peculiarities (or, these days, Electron’s). That way, everything that is core to the app can be built on one code base.