Installing Uno as a PWA with WebAssembly

One of the things that I don’t like about the web is that I have to access everything via the browser. Whilst favourites and bookmarks are all well and good, one of the nice things about apps is that I can do things like pin to start/taskbar (Windows) or add to homescreen (Android). Sure I can pin a website, but this leads me to my next point – it still feels like the web, rather than an app experience. There’s still the browser chrome that sits around the edge and it doesn’t feel the same as being in an app. In this post we’re going to look at one aspect of Progressive Web Applications (PWA) which is the ability to “install” the application in order to address some of my feelings towards web applications.

Twitter PWA

Let me start by walking through one of the better PWA experiences offered by Twitter. Over the last couple of months Twitter has changed the layout of their website significantly but what’s interesting is that it appears they’ve been moving towards a single look and feel across both their web and app experience. For example, the experience you see today on the website is basically the same as what you get if you download the Windows Store app. As you’ll see once we install their PWA that the web interface makes sense because it’s designed to work as an app.

Back in 2017, Twitter announced Twitter Lite which they talked about as being a PWA. They talked a lot about how they built it and their post is definitely worth a read. However, I want to focus on the experience they’ve built for users.

Twitter on Mobile Chrome

Let’s look first at their mobile experience. When you go to mobile.twitter.com in Chrome on a mobile device, assuming you’ve signed in, you’ll see a prompt at the bottom of the screen to “Add Twitter to Home screen”. Alternatively if you’re not signed in, or you’ve dismissed the prompt, you can select Add to Home Screen from the side menu in Chrome.

Tapping on Add Twitter to Home screen displays a confirmation prompt

Tapping Add will “install” the mobile website as an application. This includes an icon that you can move around your home screen. Note that the icon is almost indistinguishable from the actual Twitter application that you can download from the store.

When you launch the newly installed Twitter website, what you see is virtually the same as the Twitter application you’d download from the store. There’s no browser chrome and it looks and behaves just like an app.

And in fact if you press and hold on the Twitter icon on the home screen and go to App info, it even displays information in the same way as it would a regular application, including the ability to Uninstall and Force stop.

Twitter on Desktop Chrome

So that’s the mobile experience. Let’s just check what the desktop experience is. It’s not much different, except for there’s no prompt to install the application. However, if you look to the right of the address bar, there’s a little circle with a plus button; hovering over it indicates it will Install Twitter. Similarly if you go to the right side-menu, there’s an option to Install Twitter.

Again, the install process prompts for user confirmation.

Once installed the Twitter website launches without the browser chrome. In addition to the usual minimize, restore and close buttons on the right side of the title bar of the window, there’s a key icon and a vertical dots icon. The key icon allows you to clear all browsing data.

The vertical dots reveals a menu with the option to Uninstall Twitter.

After installing the Twitter website as an application the Twitter icon does appear in the applications list. However, if you attempt to uninstall the Twitter website by right-clicking the icon and selecting uninstall, it’ll just take you to Add/Remove programs in Settings (I suspect Windows thinks you want to uninstall Chrome). You need to launch the Twitter website application and use the Uninstall Twitter option in the menu.

Making Uno a PWA

Now that we’ve seen how a website can be installed and then behaves just like a regular application, let’s take a look at how easily we can do this for an application that uses Uno and WebAssembly.
The firs thing that we’ll need is a manifest file. In my case I’ve called it manifest.json and I’ve put it into the root of the WASM project in my Uno solution. It’s got the following content that defines things like the icon and the name of application etc.

{
    "background_color": "#ffffff",
    "description": "Freakin awesome Uno web app.",
    "display": "standalone",
    "icons": [
      {
        "src": "Icon192x192.png",
        "sizes": "192x192",
        "type": "image/png"
      }

    ],
    "name": "Uno as a PWA",
    "short_name": "Uno PWA",
    "start_url": "/index.html",
    "theme_color": "#ffffff",
    "scope": "/"
}

Of course, we’ll need to add the icon – I’ve added an 192×192 png with the name Icon192x192.png to the wwwroot folder within the WASM project. I also need to connect the manifest file so that the browser knows to look for it. To do this I need to add it as a link to the web page that hosts the Uno WASM application. In the default WASM project generated by the Uno solution template, there’s no html file, since it’s automatically generated. From the Uno documentation it’s possible to add in a template html file (see the Index.html content override section in the Bootstrap readme). However, it’s also possible to just specify the name of the manifest file using the WasmPWAManifestFile attribute in the project file (see Support for PWA Manifest File section in docs).

<WasmPWAManifestFile>manifest.json</WasmPWAManifestFile>

When we now run the WASM project and bring up the developer tools on the Application tab you can select Manifest and see the information contained in the manifest.json.

Also, the plus button is on the right of the address bar (and the option to Install in the side menu), indicating that this website can be installed.

And that’s it – all you need to do to get your Uno website setup to be installed as as PWA.

Progressive Web Apps–Are these a “thing” yet?

Progressive Web Apps–Are these a “thing” yet?

Maximiliano Firtman has a great post that discusses the current state of play of Progressive Web Apps (aka PWAs). For me the stand outs are:

– iOS hides the “Add to Homescreen” option within the Share extension

– On iOS the ability to Add to homescreen isn’t available when using Edge or Chrome, despite the Share extension being a common across applications.

– Lack of push notifications is a major annoyance from a user perspective – After installing iOS 11.3 I went and added the PWA version of Twitter (just go to https://mobile.twitter.com and add to homescreen). The app works great but the lack of any form of notifications is just crippling and means I now miss messages until I get prompted to go into the Twitter app. This alone is a reason for me to install the store version of the app.

– PWAs still only get a limited cache, with no option to extend it with user consent, which is hardly enough to cache the static resources for a good responsive website, let alone provide offline data access

– Windows support is still via an app coming from the store

The upshot of this is that whilst Google is doing a great job in advocating for PWAs, the reality is that they’re still not ready for the prime time.

Every day there are new technologies emerging; there are new frameworks available; there are new scenarios and devices to build for, so it becomes difficult as product owners, as developers, as technologists, to work out where to focus our attention. As we discussed in a recent article on App – Fomo before you jump into looking at technology it’s important to decide whether an app is even something you want to build. The true value of PWAs is that they are starting to bridge the cap between what the web can do today and the benefits offered by applications delivered by a store (eg place on the home screen, offline, push notifications). This in turn will ease make it easier to determine whether you truly need an app, or whether a modern responsive website (aka a PWA) will suffice.

PWA Follow Up

PWA Follow Up

It’s clear that talking about Progressive Web Applications (PWAs) is all the rage. I noticed today that fellow Microsoft MVP, Adam Pedley who runs the Xamarin Help website and blog, posted about where PWAs and Xamarin.Forms fit. Whilst I’m not sure I agree with his opening statement about PWAs being started by Google (there is a long legacy of different browsers providing pseudo-offline features which pre-date the term PWA, so the concept itself isn’t new), I will definitely agree that it has been Google that has been championing the cause, with Microsoft adding some behind the curtain support (eg PWABuilder.com). One of the most interesting points that’s worth highlighting is the disconnect between the device features/capabilities that the web and client applications (native, Xamarin or Xamarin Forms) can take advantage of. Whilst the difference is being progressively eroded, there are still plenty of areas where a client application is the way to go. Shout out to https://whatwebcando.today/

image

What’s a Progressive Web Applications (PWA) and Why does my website want to be one?

What’s a Progressive Web Applications (PWA) and Why does my website want to be one?

My last couple of posts (App or not to App and Cross-platform applications – PhoneGap/Cordova, Xamarin, PWAs and now Flutter) have been discussing different aspects of build applications. In particular in my previous post I discussed deployment models as being one dimension of applications. In this post I’m going to focus a bit more on the one of the hottest topics going around at the moment, Progressive Web Applications, or just PWA for short. If you’re new to this topic, I’d suggest a quick detour across to the Google developer site where they have an entire section dedicated to PWAs, and it’s a great starting point to understand the importance of PWAs and the experience that a good PWA should deliver.

Side note: I had to laugh when I first went to the PWA page on the Google developer site as it talks about “A new way to deliver amazing user experiences on the web”. This is really what happens when you let the marketing get out in front of technology. Unfortunately I’ve see this type of propaganda so many times (Flash, Silverlight, HTML5) that it actually makes me a bit nervous as I start to think about another learning curve.

image

One of the quickest ways to get past the marketing fluff is to click the PWA Checklist button in the top right corner of the PWA page. Here’s a list of some of the other useful links on the Google developer site in relation to PWAs:

PWA Checklist

Lighthouse

PWA Summit videos (a bit dated but still a good place for building familiarity)

Now that I’ve assigned you a bit of reading, let’s talk about what all the fuss is about. After scanning through the PWA checklist it becomes very evident that there are a couple of key topics: security, offline, seo and notifications. Let’s break these down, with specific attention to why they’re all important aspects of a great application (not just a PWA).

Security

Whilst not the first topic that comes up in regards to PWAs in the checklist it’s very evident that security first is still a key mantra when building the next generation of applications, which is made clear by the first item in the checklist which indicates that all content should be delivered across HTTPS.

In the context of application development there has been an increase flow towards the use of HTTPS (for example the release notes for iOS9 by Apple indicated that all new apps should use HTTPS). Without HTTPS it’s just too easy for any third party to intercept and read/modify the traffic to and from the application.

Offline

This is a biggie when it comes to PWAs and in fact you could argue that this is probably the most significant departure from traditional web development. The introduction of service workers that can intercept requests, cache and dynamical change request behaviour opens the world to building intelligent offline-enabled applications. However, from an offline-ready application development perspective the current thinking in this space seems relatively immature, with most of the priority being placed on caching the components that make up the application (ie the HTML, CSS, JS that make up the application), rather than offline data and synchronisation scenarios.

SEO

Optimising your application for search has been one of those things that every developer says they’re going to do but rarely do they do it, and seldom is it done well. In terms of application development, one of the challenges faced by developers is how to define a set of deep links that will resolve both on the web and in the app. In structuring an application, it should be possible to provide an external link to any part of the applications, and in an ideal world the the link can be shared via any method, whether it be a link on social media, or via private correspondence such as chat or email. The upshot is that by structuring an application this way, you’re already half way there to making it indexable – you just need to make sure that the web application can be statically crawled so that relevant sections will appear in search results.

Notifications

Another aspect that tends to differentiate a good application is one where the user doesn’t have to keep on opening the application in order to see whether anything important has happened. All the native platforms, Windows, iOS and Android, have a rich push notification system that allow for interactivity and rich media in some cases. However, there is a disconnect as applications have to support multiple vendors that all support a slightly different push notification format. Notifications are important for a quality application as they help to keep the user informed about the things they care about most. The “Glance and Go” marketing campaign by Microsoft a number of years back for Windows Phone, whilst ultimately a failure (bye bye Windows Phone, we’ll miss you) it rang true in that notifications and badges are an extremely effective way of keeping users abreast of background activity within applications (either locally on the device, or remotely)

Hopefully from this breakdown you can see that PWAs, whilst one of the hottest topics today, is far from “a new way to deliver amazing user experiences,” since application developers have been doing this since before the release of the iPhone. I guess the big distinction with PWAs is the “on the web”…. as in “please developers, stop building web sites with a crappy user experience, and start building rich applications that delight the user”. Perhaps some day we’ll break the dependency on the request-response model that has for so long governed the design of web sites.

Cross-platform applications – PhoneGap/Cordova, Xamarin, PWAs and now Flutter

Cross-platform applications – PhoneGap/Cordova, Xamarin, PWAs and now Flutter

At Built to Roam we build applications that target a wide array of different platforms, using a wide variety of technologies depending on the project requirements. One of the most challenging things faced by organisation looking to build any form of software is often not what should I build, it’s often what technology should I use to build it. Unfortunately this is also where the most cycles are wasted and the poorest decisions are made.

Nirvana would be building the software once, and for it to be available on every platform and device type, able to be instantly updatable and have a rich and engaging user interface (and I’m sure there’s more things that needed to be bolted onto this list of “ideals”). However, the reality is that there are different device types and sizes; there are different technologies with differing capabilities; and different developer and deployment workflows. Rather than being able to make an absolute decision on the best strategy, companies are limited by their own field of influence. Too often this includes Gartner reports, media hype and both internal and contractors with whom the decision makers have a relationship with.

In addition to the number of options that are available, the optimum strategy also evolves over time. For example, five years ago in Australia it made sense for organisations to start their investment in mobile apps with a fairly basic iPhone application. Today the market expectation is that a mobile strategy encompasses at least Android and iOS, phone and tablet, and with a comprehensive set of features. In fact some applications, don’t even have a web presence, finding that their mobile apps were sufficient for their business model.

So the question is really whether it is possible to define the optimum strategy for a business and is it possible to future proof it?

To investigate this a bit further, let’s take a look at the progression of native application development. What’s quite interesting is that businesses have woken up to the fact that maintaining multiple applications written in the preferred technology for each platform is not sustainable. This has led to the emergency of a host of cross platform tools that generate native applications. There are tools such as Xamarin/Xamarin Forms which compile C# so that it can be run on the target platform; There has also been an explosion in Javascript based solutions, such as React Native where it generates the native components for each platform based on HTML mark-up (+CSS, JavaScript etc); More recently again there is Flutter, which aims to provide a user experience that has been drawn from the ground up to be platform agnostic. How do you make a decision between these technologies?

More importantly is – are you making the decision about the right thing? It would seem that making a decision about which native application toolset to use would be right but actually the web and some of the hybrid solutions solve so many challenges that native application developers face, it would be foolish to ignore them. Take for example the recent hype around Progressive Web Applications. There are some who believe this is just another round of hype about the newest buzzword to arrive on the scene but in actual fact whilst the name is new, the concept is not. Back even in the days of Windows Vista, there were desktop gadgets that essentially allowed parts of the web to run in a container in an offline capacity. PWAs are just the latest name to be given to this concept.

Where PWAs are set to make a difference is that they are being widely backed (eg Google: https://developers.google.com/web/progressive-web-apps/ and Microsoft: https://pwabuilder.com) and they also arrive at a point in time where devices have browsers and rendering engines that are capable of delivering a high-performance web experience whether in-browser, or in a hosted web application.

Do you think the market is ready for PWAs? or are native applications going to rule for the foreseeable future?