Publishing a PWA to App Stores
Hello, welcome to the journey of polishing a PWA to the app stores.
My name is Maximiliano and I will give you a journey into publishing a progressive web app to app stores.
That's our goal.
So you do have a PWA, you have a progressive web app that is already published and we actually want to get into app stores.
That's the goal.
So the first station and we are going to have a couple of steps to actually get to the final station, the first station is the PWA.
So you should have already that PWA published in a web server.
So you have a service worker, you have a web app manifest and you do have a good UX, and performance.
Something that we want to keep from progressive web apps, when we are going to the stores is easy deployment, single code base.
We don't want to change that.
Silent updates.
So actually updating the PWA is just changing the files on the server, that's all, and open web standards.
So we don't want to get out of HTML, CSS, JavaScript, and all of the standards that we love.
So the next station, after we have the PWA is the Plan.
We actually need to make a plan to actually get to the store.
So before actually doing the plan, we need to understand the actual app stores that are actually compatible with progressive web apps.
Today we have PWA support on Google Play-Google Play is the store for Android that's of course phones and tablets, but it's also the store for ChromeOS or Chromebooks.
We have support also on the Apple app store.
That includes iOS, iPad OS, and Mac OS.
And finally, we have PWA support also on the Microsoft store.
That's for Windows 10 and Windows 11.
What about other stores?
There are other stores available that are not actually the mainstream stores.
We have, for example, the Samsung Galaxy store that accepts actually publishing a PWA just by, by submitting the URL.
We have Amazon app store for Fire devices.
Kaios store for feature phones and Huawei app gallery for Huawei devices.
In these stores, we have some hacks to actually publish PWAs, but it's not so straightforward.
So we're going to focus only on the three more important stores that we mentioned before.
That's Play AppStore and the Microsoft Store.
First it's important to understand during our plan, that stores is not for all the Progressive web apps out there because the PWA needs to actually comply with store rules.
So some apps will never be accepted in the store.
So there are some user interface guidelines that sometimes we need to follow.
And when we have a PWA, we may be accepting those guidelines or not.
We might be following those guidelines or not.
And if not, maybe we need to make some changes.
Also, when you have premium content and you want to charge for that content, we need to follow the app store business model that that store has.
And because of the nature of the web and the nature means that you can actually change the contents of your app from the server, there might be additional restrictions.
For example, on the Play store, you cannot publish using a PWA content for children.
So there are restrictions on that.
So we need to read all these guidelines, to actually understand what's possible and what's not.
And we also need to do some homework.
Part of the plan is to do some homework.
We need to do and plan these with time.
So first we to register ourself as a publisher or we need to register our company or organization as a publisher, sometimes that involves paying a fee.
On Apple it's US$99 or different amounts of different currencies for different countries.
That's per year.
On play, it's, $US25 dollars, just a one time payment.
But that registration might take time.
The process can take days or even weeks, mostly when we're talking about organizations or companies, because the store needs to be need to have some kind of security or guarantee that we have the rights to publish apps under the name of that company.
After we have that account, we need to prepare a privacy policy URL.
So we need to have a document, an online document with the privacy policy, something that is not always mandatory when you have a PWA that is just published for the browser you need to pick a package ID.
That's a string that is typically a reverse DNS.
So for example, if your PWA is publshed under myPWA.com, you use com.myPWA as your ID, and on some stores you need to register or reserve that package ID.
You need to prepare a demo account for reviewers.
That's in case you have a login in, within your PWA.
So you need to log in and registering an account.
You need to prepare a demo account for reviewers and you need to prepare a lot of metadata from text descriptions categories of your PWA to icons, screenshots and a lot of promotional banners.
And of course on each store, the resolution that you need and the places where these promotional banners will appear differ.
So you need to read a lot of documentation on all the metadata that you need.
Something that is not necessary when you are polishing a PWA for the browser, or at least you need just one or two, a screenshots.
And that's all.
So after we have the plan, we have the PWA we have started the plan.
The next station is launchers.
We need to create and focused on PWA launchers.
Let's try to understand what this is.
So when we are talking about app packages, so whenn we are going to the store we're uploading packages.
This is like a ZIP file, a package an archive.
So there are a couple of packages.
We can create a native app package.
When you you're doing Kotlin aps or Swift applications you have within the package, you have all the assets, all the resources of the app, including the compiled code.
You can have hybrid packages, such as the ones that you publish with a Apache Cordova or a PhoneGap or Ionic.
In this case, you will have your web up embedded within the package.
So the package will actually have the web app inside.
And finally, we have PWA launchers.
And what's the main difference?
The PWA launcher is a package that is empty.
It doesn't contain actually the actual web app inside the package.
So the PWA launcher is a native app.
It's a native shell that launches a PWA and it just contains the app's icon, the app's name, the start URL-so the URL of your PW-and other metadata, that is actually different per platform.
But it doesn't contain the assets.
No resources are actually shipped with a PWA Launcher.
The service worker, is still in charge of downloading all the assets that we need, like HTML, CSS, JavaScript, images, web fonts, and all the, the rest of the assets.
It's also responsible for caching those assets and for serving those assets on the next load as with a browser installation.
So when you're installing a PWA from the browser, it's actually the same behavior.
So now let's talk about the three platforms and how to create these PWA launchers.
Let's start with Windows.
For Windows 10 and Windows 11 we need to create an APPX launcher.
The APPX launcher today is using the Chromium-based Edge runtime.
So it's going to use the actual Edge browser that the user has on that Windows PC.
And to create this package, we need to use Visual Studio in case you want to do it manually, or you can use PWAbuilder.com.
PWAbuilder it's an open source free tool available on the web where you can actually type the URL of your PWA.
Remember, our PWA must be published before going to the store.
So we type the URL.
And after a quick test, PWAbuilder will offer us a Windows package that we can download and then upload to their store later.
So what about Android with Play?
And when we are talking about Android with Play, I'm mostly talking about Chromebooks and the Play services on Chromebooks.
In this case, we need to use, we need to create, an Android App bundle.
It's an AEB file.
Android App Bundle.
That bundle will include inside a TWA or trusted web activity.
In short words, the way that we have today to publish a PWA in the app store.
And this is only available for public PWA.
So your PWA must be published within the public internet.
So if it's under a VPN or an intranet, it's not going to work.
Also, we need to verify that we own the PWA.
So there is a verification link process.
So we need to link the PWA, so our web server content, with the Android package.
So they, it's a process that we need to, we need to create the signature file, JSON file, and then we need to publish in our server.
And that's all.
For, for creating these packages.
We can use Android studio in case you have experienced creating Android apps with Kotlin or Java.
Bubble-wrap, bubblewrap is a free CLI comma line tool created by the Chrome team to actually create these packages or even PWAbuilder.
So I'm talking about bubblewrap it's available on NPM.
So you just need node JS and with bubble wrap, you will be able to create these PWA launchers for Android.
So you just use NPM to install, bubble wrap, then using the URL of your public manifest.
You create the project.
You build the project and you're done.
You don't need to have experience creating Android applications if you use bubble wrap.
And if you don't want to mess with command line tools and you prefer a graphical user interface, you can also use PWAbuilder.
The same tool that I mentioned for Windows.
It's also suitable for Android.
PWAbuilder today it's using the same CLI bubblewrap, but in the cloud.
So actually we'll compile your package, you would create your AAB, your Android app bundle in the cloud, and it will be ready for you in case you don't want to install anything in your computer.
And then finally we have Apple, iOS, iPad OS and Mac OS.
So the App Store.
And we know that Apple's relationship with PWAs is typically weird, so Apple doesn't officially say a word about PWAs in the store.
So if you go and try to find some documentation about how to publish a PWA in the app store, you're not going to find anything.
However Apple has something known as WKWebView.
WKWebView is a WebKit engine that you can embed directly in a native application.
And from last year we have from iOS 14, we have something, known as App Bound domains.
Actually an App can include the list of up to 10 domains-so myPWA dot com and over those domains, the web view will have full support of a PWA, including service workers.
So meaning that we have a technical solution today to have service workers in a WKWebView, which means at the end that we can publish a PWA to the App Store.
There are many PWAs already published using these techniques.
For that, you need to use XCode and you type some Swift or Objective-C code.
Now, unfortunately we don't have any CLI or online tool today that will help us with this.
And if you want, I have some code samples on a course "Publishing Progressive Web Apps" that it's actually available in my website, firt.dev/learn, if you want to get more information about how to use X code to create these PWA launcher for iOS.
So now we have the PWA, the plan, we have the launcher.
The next step is to talk about extensions.
So can we extend the web platform with native code when we are going to the store?
So let's talk a little bit about that.
Because now on the extensions we have, like, we are crossing with another line.
With a native line and yeah, we can connect with Android native code, with iOS or iPad OS native code or with Windows code.
So let's try to cover briefly if this is possible or not today.
So can we extend the web platform?
So this is actually necessary.
So let's write to the fan and first make a difference between the chromium universe and the webcam universe.
So we know that today on Android, ChromeOS and also on Windows, we have Chromium as the engine.
And chromium today has a lot of APIs available.
The Fugu project for example.
So we have access to Bluetooth, NFC, and a lot of stuff.
And on the WebKit side, we are more restricted in terms of what we can do with the Web platform.
So let's try to analyze if we can extend this web APIs with native code.
On the Playstore using trust web activities, it's kind of limited.
So you can ship with your PWA launcher, also Android components, native components, but those components are actually not connected directly with your PWA.
So it's not so simple to make that connection.
And something similar happens on Windows today.
So it's actually not so simple.
So it's actually better to stay within the, the web umbrella, the web platform umbrella.
But on iOS that the web platform is more limited.
Fortunately, we have a way to have a bridge so we can create the bridge to native code.
So Swift can execute JavaScript and JavaScript can execute Swift.
So we can extend the WebKit engine with native code for our PWA.
So some integration examples, for example, push notifications.
Do we need to integrate native push with a PWA while on Play?
For example, on the Play store, we have automatic notification delegation.
So when a notification appears the system automatically delegates that into your service worker, into your PWA.
Andon iOS, well, we can bridge to native.
So we write Swift code or Objective-C code, and we connect that with our PWA using app bound domains.
And another example is in app billing,in case you want to charge for additional content within your app.
On Play, we have digital goods API, so we can stay within the web umbrella because we do have an API today on Chromium-based browsers, digital goods that will let us charge for subscriptions or for items within our App.
And on app store the same as with push notifications, we need to write our own native code and call it, using this bridge.
From JavaScript we're going to call Swift code.
Okay.
So remember to use the P in PWA.
So the first letter is for progressive enhancement.
So remember to use this pattern to keep a single code base within different stores.
So we have extensions now.
It seems like we are reaching App Stores, but before actually reaching the final station, I want to take a shortcut to the enterprise world.
Just a minute.
Today you can deploy your PWA into employees' devices.
Incorporate the stores, both on iOS and Android.
On IOS and iPad iOS it's actually pretty simple.
It's a mobile config file.
So the file can be deployed through the web or through email.
So you can send emails to your employees, and if the user accepts, that file, the PWA icons will appear automatically in users' homescreens.
Automatically.
So you just create this file, this mobile config file using a tool, a free tool.
It's called Apple Configurator.
You type the URL, you select the icon and then you deploy the file.
That's all pretty simple, straightforward.
On Android we have Managed Google Play iframe.
That's the name of the tool.
You can push PWAs using the enterprise Android console.
In this case your users, the users of your enterprise account, will see those PWAs under work apps within the store, within the play store.
So this is how it looks like.
And in case you want to create or ship a new web app, a new PWA, you type a URL and you select some metadata, pretty similar to iOS, and then users will find that app within work apps in Google Play.
Remember, this is a parenthesis and this is only available for enterprise users, not for end users.
Okay.
So now we are finally reaching our final stations, app stores for end users.
So we are approaching that final station and our PWA is ready for the app store because we have a publisher account ready.
We have all the metadata and we have created the PWA launcher.
So the final step is to go to the app store connect.
That's the Apple portal to upload our apps.
To the Google Play console, the same portal, but for Google Play for Android and ChromeOS and the Microsoft partner center, where you're going to publish your PWA launcher for Windows 10 and Windows 11.
And the final step is to brace yourself for rejection and or for making changes in your UI.
So prepare for this.
So some stores will ask you for changes in your user interface to get a final approval.
And that's actually the final station.
So we have arrived at our destination.
You have now a PWA published in the app store.
So that's all that the journey to publishing a PWA ijyo app stores.
Thank you.
And good luck with your PWAs.