Why a PWA made much more sense?
In one of my recent interactions on issues faced with the launch of a mobile app to the app store, I realized that one of the primary reasons behind the popularity of PWAs could be the circumvention of publishing apps to the Google Play Store or Apple’s App Store!
This implied…. No permissions, no restrictions, no rejections!
We had developed a Cannabis eCommerce application in native Android and iOS. But unfortunately it was repeatedly getting rejected from Apple’s Appstore, although it is a legal trade in many geopolitical areas of the world.
There were many more such examples such as an arms and ammunition business app, a pharmacy mobile app, where releasing them on the stores was tedious.
The best solution for this problem was in fact available just around the corner… in the form of a PWA or a Progressive Web Application.
Primarily being a web application installable on the mobile devices, this would completely eliminate the need for deploying to the application stores. This is one of the most attractive features of the PWA that pitches it against native development. Also as businesses shift focus to mobile audiences, the PWA, with its mobile-first design, makes this transition seamless and effortless!
We have an experienced team on PWAs, and you can read more about it here. A recent project for which we developed a PWA using Angular, Ionic and Cordova was for a supply-chain enterprise. Based on our experience and the market study on PWAs, we did a quick research on the Cannabis application and its pain points, and how we would resolve them by implementing a PWA. Here is a quick run through the points…
We had put multiple teams to deliver a single product. But now we could dedicate our efforts singularly on one frontend and would still roll out the application across multiple platforms. This generated savings not only in terms of cost but hugely in terms of time, making it an important decision-driving fact for the app’s market strategy.
Augmented by the power of the “ServiceWorker”, web apps that are built as PWAs can now control network access and can decide which data to cache or how to deal with varying network conditions, enabling it to challenge the native app’s capability to handle network conditions. This opened our door to introducing offline working mode in the app.
Native and hybrid apps give developers much more access to the device hardware than web apps can. While this is still the case for some hardware, the web has come a long way. There are now APIs available to a PWA for accessing the device’s accelerometer, location, camera, 3D acceleration and more. This was seen as a major show-stopper earlier, but with all the APIs available today and growing, it has opened the way for PWAs to leap forward.
Having made so many decisions around the implementation, the discussion then drifted into the app’s accessibility, distribution and versioning model. Accessibility was in fact the primary reason to convert to a PWA. Having the app installed on the user’s home screen without requiring a download from any app stores was huge! This makes the user engagement of web apps comparable to that of native and hybrid apps.
What about the distribution and searchability of the app?
Mobile App’s are not easily found on app stores. With Google rolling out mobile-first indexing and endorsing PWAs, this roadblock is easily overcome. There was an edge we had here, as a PWA was a web app after all …searchable and distributable through the world wide web! Here was a frictionless, easy distribution that ensured a higher conversion rate than finding, downloading, and running a mobile app from the stores.
What’s more, as we upgrade to new feature sets, we need not be worried about maintaining backward compatibility of mobile apps or their service APIs, because the app always hits only one version of the application and is always serving the latest information!
If you have any queries or need to develop a PWA, please do write to us here.