Turning Mobile App Into Progressive Web App (PWA)
This is a blog post I originally wrote on Medium on How Ushahidi Turned TenFour Mobile App Into Progressive Web App (PWA).
The TenFour team replaced their legacy Angular 1 frontend with a PWA reusing their existing Ionic Framework mobile app, providing a single code base for the web frontend, iOS app and Android app. As a result, there’s less code to maintain. The transition greatly increased the speed of development. We’ve streamlined the design process and now have a faster more responsive product. Boom!
TenFour is a new emergency check-in system for teams brought to you by Ushahidi. It allows you to broadcast a question and collect back responses across many channels including in-app, Slack, email, SMS and voice. It was created following the Westgate Mall attack in Kenya where fellow Ushahidi team members and friends were trapped in the mall. During a crisis, communication can become difficult so TenFour aims to solve that problem by simplifying how messages flow between people.
PWA stands for progressive web app, a “new way to offer incredible mobile app experiences that are highly optimized, reliable, and accessible completely on the web.” Wow, that sounds pretty awesome! Well, it isOur Legacy Client
At our team retreat in May 2018, we made it our mission at that team retreat to see whether it was possible to rework our existing Ionic mobile app and publish it as a PWA. Amazingly, after an afternoon of hacking, we had our mobile app running as a PWA on a server. Our reaction, “Holy s***, this might actually work!”
How to Transition to PWA
Following the retreat, we spent the next two sprints refactoring our mobile app. Like most Ionic mobile apps, it’s common to make use of native plugins such as camera or GPS in your pages. This is fine for mobile apps but unfortunately poses an issue in the PWA, since none of those native plugins work in the browser.
One workaround is to have lots of if-else logic in pages checking whether the app was running on Cordova or as a PWA. Although this works, it’s messy and error prone. So a better solution is to encapsulate all native plugin functionality as their own providers. This way each provider handles the if-else logic internally, implementing the native plugin or providing browser friendly functionality. For example, we have a LocationProvider which uses @ionic-native/geolocation for Cordova but fallbacks to using navigator.geolocation in the browser. So pages don’t care how the LocationProvider gets the current location, it just needs a location information. Mmm, encapsulation…
One of the big upsides of encapsulating native plugins in providers, is that our pages are now a lot cleaner with no imports to any @ionic-native plugins. Since providers are self-contained, this also allowed us to reuse that entire set of providers in a new product we’re prototyping, helping fast track the prototype’s development.
The Rise of Hybrid Apps
Having developed mobile apps for over 15 years, starting back in the beta version of Microsoft Compact Framework apps for the first generation of Compaq smartphone devices and later developing native iOS and Android apps, I’ve seen the industry change a lot. When hybrid apps first came on the scene, I was skeptical and honestly a harsh critic. Hybrid apps felt like a webpage wrapped in an app. Loading a new page often meant a complete refresh with views going blank before the next view loaded. Hybrid apps also suffered from not being like the target platform, so to users they didn’t look like either an iOS or an Android app.
This is a huge win for small teams, since you only need a single code base for your iOS and Android apps. Development is faster since you don’t need to develop twice–once for iOS and then again for Android. But even more important than the initial development, is the ongoing maintenance cost savings from not having to support two or more separate code bases. It also means that teams with traditionally separate native iOS and Android developers, can often be reduced to a single Ionic developer. These are huge wins for small teams with limited resources.
Design With Constraints
One of the things we struggled with on our old Angular 1 client, was the amount of design work required to implement any new features. With our previous frontend we rolled our own pattern library, a collection of custom UI components. Although this seems like a good idea in theory, in practise it dramatically slowed the design and development process. New features often meant lots of custom design work taking both design time as well as development time.
Luckily this is not necessary using the Ionic Framework, since there already is a large suite of components available. Although it does restrict us to a certain look and feel, this has proved to be a good thing. With Ionic’s components, we get to lean on effective design standards that are both well tested and sufficiently flexible, aka design with constraints.
On the design side, it’s allowed our product manager to create mockups for new features on his own. Usually this is good enough to move into development. At other times the product manager’s designs get passed off to a designer to polish and revise. But overall it’s greatly reduced the amount of time it takes to design new features.
From the user perspective, they now have a faster more responsive web app. Also the PWA has resolved a lot issues with accessibility and browser compatibility that our old frontend client suffered from, since we had previously implemented all our own custom components from scratch.
One Code Base To Rule Them All
On the development side, new code and features can be implemented a lot faster. For example, we recently rolled out bulk edit functionality in TenFour which is a big undertaking. Traditionally it would have taken us over a month but we were able to design, implement and deploy in under two weeks, with the work done by only a single developer.
We built and designed for the feature once. In comparison, if we had a standalone frontend web app, native iOS and native Android apps, it would have taken three developers to do the work, and likely would have been twice as long. Each platform would require its own design work. So what took one developer two weeks to build, would have traditionally taken us three developers four weeks. That’s a pretty big improvement gain!
And The Verdict Is...
On a recent team call our product manager Charlie asked, “So it’s been six months since the switch to PWA. Was it a good decision?” The overall consensus from the team was, “Yes!” We now have a single code base to maintain, which is pretty clean and easy to develop on. The design of new features is a lot faster and allows our product manager to be more involved. And overall our product is faster and more responsive.
One of our team members shared a very validating comment about the PWA after demoing it to a group of users at Mozfest:
That was easily the SMOOTHEST demo I have ever had to run. Everything worked REALLY well, I managed to sign users up, set them up into groups, send them check-ins via SMS and email, they received it in seconds, they responded and were also able to see their responses come in live. And they LOVED it! Super huge love bombs to all of you for such an amazing experience!
We feel validated in our decision to replace the legacy Angular frontend with a PWA. Huge kudos to the Ionic Team for building such a powerful development platform. Visit www.tenfour.org to learn more about TenFour and see the PWA in action. And please try out TenFour, we’d love your feedback!