How we publish a Web, Android, and iOS app with the same code-base
This is the story of how we were able to launch a web application and publish it at Android and iOS stores with the same code-base using WebView and a little bit of magic.
Why
The main reason that led us to this need was:
- Time: Our client had a very tight deadline due to commitments with investors.
- Resources: We did not have the capacity to have developers dedicated to native platforms.
How
With this in mind, we took the risky decision to bet everything on the web platform, with the idea that the changes planned to improve the mobile experience would give us enough credit to pass the approval of the mobile stores.
The mobile-specific adaptations that made this a reality were as follows.
Splash screen
We took advantage of the PWA (Progressive Web Apps) concept to have an initial loading screen that would serve as the “loader” of the application, also taking special care to match the colors of the mobile status bar with our brand colors.
Native Inputs
One of the first things we approached was the mobile experience when entering data, trying to delegate as much as possible to native controls of the Android or iOS mobile OS. (Select, date, number, text,).
We must be careful if we use a very complex component library, trying to set the appropriate<input type=""/> for each case. Here you can find a complete list of the different values it can take.
With particular emphasis on the input of dates, selects, dropdowns.
Mobile First
Taking advantage of the responsive capabilities of our web-app, we followed a mobile-first design strategy to ensure that all functionality was well covered and designed for all screen widths.
If it is not possible to follow a mobile-first strategy, a good “responsive” could be just as effective.
(No) Payments
For our particular case, our application offers a subscription service, so you need to pay a fee to enjoy all the services offered by the platform.
In the case of the stores, if you want to allow payment within the apps, it is necessary to leave a % of royalties or otherwise not allow any type of payment or mention any type of subscription within the mobile applications.
To do this, we review our entire navigation tree to make sure that the user not only cannot pay within the app, but that the screens and texts related to subscriptions are not available in the mobile versions.
This saves us integration costs with other payment gateways, and the annoying royalty to jump through the hoops.
Files upload
One of the guidelines that the stores have when approving your application is that it has to provide a differentiating value that makes sense through the mobile application and that cannot be done on desktop.
In our case, we take advantage of our file upload from the web, to integrate it directly with the file system of the operating system, as well as with the camera, very practical too!
Push notifications
We took advantage of this opportunity to bring additional value to the mobile experience through push notifications of events that may be of interest to our users, making use of the notifications web api and a dedicated push notification server like Firebase.
Deep Linking
Related to the previous point, we made sure that push notifications were able to send the user to the specific screen making it even more fluid and consistent experience.
Here you can see documentation about how to set it up in a ReactNative Application.
ReactNative WebView Wrapper
We created a ReactNative project with react-native-webview package to load our website as a mobile app!
Dedicated CI
One of the biggest headaches in mobile development is the packaging and deployment of applications in each store. Luckily, from the beginning, we set up in our code-base 2 pipelines, one for web, and one for mobile with Fastlane and Bitrise. With this, we would be able to automatize the publication in the stores in the different channels (alpha, testing, prod).
Bonus track
Everything that can help to get an experience as close to mobile is appreciated and helps to get your web-app approved by the stores, in particular, a couple of additional tips that may be useful:
- Button feedback when clicking on them.
- Click outside: for everything, that generates a background overlay, such as modal or side menus.
One more thing
All these modifications dedicated to native mobile, are implemented to activate automatically when the application detects that you are in a WebView, but if you browse from a mobile browser, the behavior is the same as a desktop but mobile-first, it is a win-win.
Recap
As you can see, publishing a 100%, web application in the stores is not impossible, but you must take special care of the details and in the user experience, trying to provide something of value that differentiates it from other platforms.
Hope you liked it and it will be a pleasure to answer or hear your experiences in the comments.
More stories in our blog:
If you have a digital product you want to make a reality do not hesitate to contact us:
