Building a native app from a PWA - 10 things to know before going in

That’s right: PWAs have been fully embraced by Google while becoming second class citizens in the iOS realm. For a long time, if you turned your website into a PWA, you could therefore easily deploy it on the Google Play Store, but not on Apple’s App Store… until recently that is. What follows are tips we gathered when going the app route from our PWA…

***

As we were saying, creating a “native” application from a PWA is now absolutely feasible, thanks to none other than… Microsoft. The company’s new Satya Nadella-led era is on full display here: make the developers happy and they will use your tools (does Visual Studio Code ring any bells?). Still, why would Microsoft help web developers and Apple in this scenario? Because they are confronted with a big issue: most developers create apps for Google’s Play Store and Apple’s App Store but not for the Microsoft Store…

 

Enter PWA Builder, a project “founded by Microsoft as a community guided, open source project to help move PWA adoption forward”. With this new resource, the tech giant tackles one of web developers’ worst issues: converting a PWA to the App Store (the Google Play Store has always played nice on that front). And, as they are not doing this entirely out of the kindness of their heart, they also propose to push those PWAs to the Microsoft Store with one extra click… “clever girl!”

 

Following are 10 tips or bits of info that could be of help to any developer going the Store route from their PWAs. Note that, in this article, we assume that you already created your PWA and that it is fully up and running. We are also not going to do a “How to transform you PWA in an app” piece, as it would simply be a copy of the great documentation already provided by the PWA Builder team. No, the aim of this article is to focus on little things that are glossed over or considered obvious to developers in Microsoft’s documentation but, to us at least, weren’t and made us lose quite a bit of time. So here is to giving back to the community !

 

1- For iOS – Open the correct xcode file

Full disclosure: this is not our proudest moment, but boy did we lose some time over this silly mistake! So, when PWA Builder provides you with a download link to your xcode / Swift-based transformed PWA, they assume that you already master xcode a little. However, if like us you are web developers first and foremost, xcode is rather foreign to you and this is where mistakes get made.

Let’s play a game: out of these two files, which one would you open? the shiny blue one, that looks suspiciously like the xcode logo, or the white and rather bland one? Worst of all, both will open with xcode, not giving you a proper feedback on whether you have opened the right file!

 

Well, you probably guessed it with our premise: you must open the xcworkspace file, otherwise you will be missing most of the code (see the pods section at the bottom)!

 

2- For iOS – Install “pods” or nothing works

This one also made us lose a bit of time because, if you don’t do anything, by default nothing will work. The way xcode functions is through a notion of pods and podfiles. Pods are pretty much the same thing as your node_modules and the plist is the package.json attached to your project, so you have to do the equivalent of an npm install. In order to achieve that, you need to do two things:

1. Install cocoapods
   Either through brew :
   brew install cocoapods
   Or through other means (e.g. for Ruby)
   sudo gem install cocoapods
2. Install the pods themselves
   Go in your terminal in the /src folder of your application and simply run the command:
   pod install
   You should get a terminal like this and now you can actually start working:

 

3- For iOS – Modify your “assets” to get transparency and a proper app icon

By default, we assume you will have created nice “app-like” icons with pretty rounded corners, but you actually shouldn’t use those in all instances, and this is why. For your splash screen to look nice, you do need a round-edged app icon with a transparent background. However, if you use the same icon for the application, some things will start looking ugly when exiting the app. What will happen is that iOS will create a white background instead of your nice transparent one and will add an animation to crop back to the round-edged application icon that you see on your home screen. The animation goes really fast but it is rather annoying to the eye as it roughly looks like this, where little by little the white background is rounded off to the app icon:

 

The trick here is to simply provide a squared picture, which will make the animations way smoother-looking, and actually barely noticeable:

 

All you need to do is go to a page like this one: https://appicon.co/ that will generate the different pictures for you. Then, you need to go in the Assets.xcassets in the left menu, click on AppIcon and drag and drop all the proper squared images like so:

 

Also, make sure that the LaunchIcon images have a transparent background, this will help you for the next tip:

 

4-For iOS – Modify your splash and launch screens

By default, your splash and launch screens should look rather ugly and will need customizing. The splash screen is the image that will appear immediately when you open the app and the launch screen will appear while the app is loading. If you do nothing, it should display your logo on a white background without using any of your theme’s colors.

In order to modify both,  you need to access the lauchscreen.storyboard to the left of your xcode window and start fiddling with it. Select the view in View controller, then click on the attributes item (fifth element) at the top right and modify your background color to the one you want and voilà: your splash screen will look exactly like this:

On the Main storyboard, you have more things that are ready for tweaking: you can modify the background of different elements that will still have a white background by default, the same way it happens with the splash screen. You can also delete the progress bar (loading bar) and other small icons like the “connection problem” icon. The latter we chose to make transparent rather than in the same color as the background, but we kept it as it was generating error messages…

 

5- For iOS – Allow for your application to open external domains

This might not necessarily be an issue for you, as it comes from our application having a sign-in / log in option. But if you do,  those will be blocked by the application by default as you need to individually specify all “out of bounds domains” of your app — namely all sign-in domains. In order to do so, click on the info.plist on the left menu and add the domains that you need in the WKAPPBounDomains (for us, Facebook and Google at sign-in):

 

6- For iOS – You can reuse all your work from one version to the next

This was a bit of a fear that turned out to be largely overestimated… Simply put, all of the time and efforts that you have put into having a working xcode project from the steps above, you can copy/paste from one version to the next. So, when you are now working on your V2, just go to the PWA Builder page, make sure that you fill in the exact same configuration options, download the files generated and then overwrite all the xcassets, info.plist, xcworkspace and xcodeproj. The only thing that you will still obviously need to go through is the “pods install” phase, but everything else will simply carry over and you can push a new version in minutes! Not too shabby!

 

7- For Google Play Store – Provide a login & password even for a Google sign-in

If you don’t want to receive a message like the one below from the Google Play Store, saying that your application has been rejected, make sure that you provide a log in and password even if your log in option is specified as “log in with Google”. We are definitely at fault on this one, as it is clearly stated that you need to provide some log in information. We just assumed that, Google being a sign-in option, it was not mandatory… turns out it still is.  So there you go: create any extra test Google emails for Google to ensure that signing in is indeed possible.

 

To do so, in your Google Play console, go to the bottom of the left menu in “App content” then on to the App access section and click on “Manage” to add any test login / password that is required:

 

8- For Google Play Store – Special process for V2 versions and up

Quite strangely, Google’s approach is both simple and elegant, yet frustrating. PWA Builder actually has a separate section dedicated to this and there are a few trickeries you may want to know:

1. When you go and regenerate your new PWA version, make sure that the app version and the app version code are different and incremented from your previous version, as this will block you at the end of your process. In the Google Play console, it will simply tell you that the version’s code has already been used…
2. In order to reuse your previous signing key, you need to reopen your first “PWA Builder generated” Google Play Store folder and upload the signing.keystore. All passwords and credentials requested will be in the signing-key-info file next to it:

 

9- For Google Play Store – Don’t forget the extra settings

Something we didn’t notice at first was that, on some Android devices, the top bar with your battery level, wifi, time, etc… turns white by default for some strange reason. As it happens, this stems from extra options present in the “All settings” part of PWA Builder that are not all that straightforward. The ones you want to look at are next to the signing key and are the “nav colors”, that you may want to update to be black or a dark color in your theme in order for Android elements to properly display in the menu bar.

10- Globally, if it works in your PWA, it will work in your app

Something we noticed and had trouble believing ourselves is that everything that works in the PWA would work exactly the same in the app. Specifically, we wanted to add some menus in the app to make it look more “app-like” than the website. The idea was that it would detect whether you are using a PWA or an app rather than a Chrome or Safari browser and display menus differently.

As you can see below, we wanted the top menu to look a little different and to have a bottom menu specifically for the app:

 

To our surprise, once again, the following code we assumed was “PWA-only” actually works like a charm in the app as well, allowing us to achieve this “trick” of looking more like an “app’s app”:

//if no Boolean test if is PWA
if (!currentPWABoolean) {
let displayMode = 'browser';const mqStandAlone = '(display-mode: standalone)';
if (navigator.standalone || window.matchMedia(mqStandAlone).matches) {
displayMode = 'standalone';
currentPWABoolean = true;
IsPWAGlobalReactiveVar(true);
setIsPwa(true);
} else {
currentPWABoolean = false;
IsPWAGlobalReactiveVar(false);
setIsPwa(false);
}
}