One Codebase, Many Platforms
Today, Crunch has an App in the form of a Progressive Web App (PWA). This offers a wider reach with more capabilities and compatibility than a ‘Native’ App.
PWAs can be pinned to your phone’s home screen and behave like a Native App. However, as PWAs aren’t available in Apple’s App Store at this time we have no presence within the App Store or Google’s Play Store.
Why does that matter? There are three reasons for us looking to distribute our software via the App stores: market reach, client preference, client convenience.
Market reach
Currently, our clients’ primary route to discovering our software is B2B Referrals and through Google.
However, there’s another pool of potential users we’ve yet to reach, App Store enthusiasts. This persona will search the Stores for “Bookkeeping” or “Accounting” (akin to how others use Google) and install Apps having never visited the publishers website or scrutinised their software offering.
A good rating, description, and a slick sign-up process may be enough to entice a potential user to install the app and see first-hand how comprehensive it is.
Client preference
Despite our PWA offering a fantastic experience on devices, mobile usage only accounts for 7% of our traffic. We believe this to be a result of our ‘typical’ client profile being in the digital sector, therefore likely to be on a desktop throughout the day.
However, the recent introduction of our Free software has brought a huge surge of new Sole Trader users who are less likely to spend the day in an office environment.
In theory, offering the choice of multiple platforms will support our client base which is growing in diversity.
Client convenience
Our Minimum Viable Product will provide the functionality we deem most valuable ‘on-the-go’. From day one the Native App will include Expenses, Invoicing and Banking which should feel like a complete product to new users onboarded via the App Store, whilst existing PWA users (accustomed to a fuller feature set) will find these three domains satisfy their basic needs whilst away from the office - complementing the PWA.
How are we going to do this?
Thanks to emerging technology, options exist today that weren’t conceivable at the point we last attempted to offer our product on multiple platforms.
Today, a tool called Capacitor will allow us to build our PWA into a Native App suitable for all App stores. Their solution works by extending a Web View with additional functionality and indirect access to full native functionality. In essence they’ve created a runtime for Web Apps allowing us to remain focused on our single codebase and simply have it ‘built’ to suit different platforms.
“Capacitor […] makes it easy to build Web App’s that run on iOS, Android, Desktop, and on the web as Progressive Web App’s — all powered by a single codebase. Capacitor connects the web to Native, enabling the best of both worlds by providing the tooling and runtime that make it possible to take any modern PWA and deploy it Natively to all the platforms you care about.” — Reference
Our modular architecture means we can easily switch on, swap, or modify features for the Native App design to exclude functionality not desired for an ‘on-the-go’ version. This includes migrating the Front end API calls from our internal API to our Public API. This is needed to enforce security, but has the added cathartic benefit of making us a client of our own Public API ensuring the service we offer the developer community is outstanding.
Capacitor is downloaded nearly 200,000 times per week, and is currently powering major production enterprise Apps with hundreds of millions of users such as NBC, Microsoft and GE.
Will this put extra strain on our team?
In terms of Development, prior to our adoption of microservices we tried to build duplicate areas of our software to form new (but similar) commercial products, however we simply didn’t have the team size or headspace to make them loveable. For this reason we ruled out building a new App from scratch using libraries such as React Native.
One of the guiding principles of this initiative is to ‘maintain one single codebase meaning no frustrating or costly duplication of dev effort’, and that ‘we must not reduce focus on our flagship PWA’. Our research has suggested the Capacitor approach allows us to achieve both.
Our PWA already puts mobile users front and centre due to following a Mobile First approach, therefore the output of a Capacitor build should provide great mobile UX out of the box without the need to rethink, redesign, or redevelop. From a back end perspective, we have some prerequisites to tackle (discussed shortly) but nothing we’d consider as ‘going out of our way’ specifically for this initiative.
In terms of Deployment, we will require some additional process to get it right. In the past we’ve seen first-hand that a lack of efficient deployment flow has led to products going stale; ultimately leading to negative reviews in the App Store which distorts our reputation.
Updating a Native App relies on three parties. Us (Crunch), the App store and the client. The new version needs to be submitted to the Store for review and Approval each time. Once Approved, the user needs to update the App in order to use the latest version. The client can potentially be behind by several versions.
We can use tools to automate the process as much as possible. To release an update we’ll synchronise with the PWA and use App Flow to automate the App store submission. App Flow is a CI / CD platform for Capacitor Apps enabling us to easily deploy updates and hotfixes, keeping our App fresh.
Our Prerequisites
Public API coverage
To evolve the Native Apps functionality beyond Invoicing, Banking and Expenses we have a dependency of expanding the coverage of our Public API.
A potential workaround maybe a hybrid approach of including Nav links within the Native App that opens the devices web browser and loads the PWA. Depending on the device this transition from Native App to PWA may not be subtle, and we may need to invest in a mechanism to prevent the user needing to authenticate again. Neither are great from a client experience perspective.
Mindset change
Today, our backend microservices do not get ‘versioned’ robustly — meaning the front end of our software doesn’t subscribe to a specific version of an endpoint. This affords us the ability to develop rapidly but can bring some instability and requires good communication between developers.
A Native App must subscribe to a set version of an API Endpoint because the front end will be frozen, and although we’ll be able to deploy updates quickly, we’ll have no control over when the update will be applied. Developers will need to remain vigilant when making any significant API changes as they’ll need to increment the API version or ensure backwards compatibility.
We’ll therefore need to start thinking about the API as a Product in its own right with a client persona that’s also new to us — external developers. This will be essential to accomplishing our goal of having a bustling marketplace of external integrations within the next year.
Conclusion
There’s likely to be some oversights or idiosyncrasies to address as a result of the PWA being converted. We’d love to hear your experience in using Capacitor or a tool like it.
As a first milestone we’ll aim to prototype a thin slice of what v1.0 will look like. This might involve producing an App containing only Expenses functionality, but hosted within the App Store, available to an internal audience. Taking the thin slice all the way to Production will ensure we’re confronting all challenges and risks early within the project e.g. conversion, CX, authentication, device compatibility, versioning, App Store approval, or internal awareness.
Beyond the MVP feature set we’ll look to evolve the Native App as User Feedback dictates. This could be adding more features that are currently available in the PWA — or a new set of features specifically targeted at ‘on-the-go’ users such as incorporating receipt photo-capture, push notifications, offline mode, geo-based machine learning for transaction creation etc.
Watch out for marketing comms on a launch later this year!
Written by Jamie Hollis (Head of Engineering at Crunch), with huge Kudos to Ben Herbert, the Technical Mastermind behind this exciting plan!
