Time to Embrace Escape Hatches on the Web Platform?

NOTE: This was originally posted on my own corner of the Internet.

Progressive Web Apps aren’t reaching their potential at scale. I just spoke about how I think it’s important for the Web to push on its own vision as a platform, but as a universal app platform (one of the key segments, along with content and commerce) it isn’t hitting the mark, mainly on mobile. What if we rethink the web platform, and embrace the “progressive” quality to allow for escape hatches on top of web standards as an interop layer for maximal reach?

The default mode of evolution on the web is deliberate. This gives us a nice eventual consistency across multiple implementations, but there are times in which it is held back too much and at those times I think it is important for us to break out of the mold, branch off and prove value, while always looking to merge back in the future. We are at one of those times, and here is why our current situation isn’t working for users and developers (and thus the platform).

User Expectations

People go to app stores to find apps. On desktop, the browser as a virtual machine kinda works, and there is enough real estate for the browser chrome to be a feature not just a bug. On mobile that isn’t the case. And expecting users to understand Add to Home Screen is swimming upstream. And of course, there are plenty of uncanny valley situations when using a PWA. It doesn’t come across when you migrate devices. It doesn’t show up across an ecosystem (e.g. widgets, watches, notifications on some platforms, etc).

Developer Expectations

As a developer, knowing that I can’t hit the user bar already has me thinking about how far I can go. I sure as hell don’t want to rewrite a mobile app to target multiple platforms, and LOVE the idea of not reinventing the wheel, but I need to not be locked out of key platform capabilities and user flows.

Add to that the notion of FOMO. When iOS and Android release their new SDKs, how long will it take for me to get access via a web standard feature? Can I risk being locked out of $SOME_COOL_NEW_FEATURE?

And will Apple ever implement what I need? They have shown, through action, that they have a different vision for the Web, one that is much more focused on the content Web. Given their business and app strategy, it isn’t being evil, it makes sense. They want developers building on their native stack and offering experiences that are differentiated.

We have all tried to push on this for some time, but maybe it’s time for a different tact. Instead of slowly doing all we can to change the calculus for Apple to implement something (e.g. finding ways for their internal teams to request a feature, or getting adoption of something so that it works poorly or slowly, such as YouTube supporting Web Components) let’s think different.

Web as an Interop Layer

It’s interesting to look at iMessage and SMS as another path. The SMS standard acts as an interop layer, where you are able to text between iOS and Android. It doesn’t have all of the fancy features… but it allows for fast iterations when each platform is talking to another device on it’s own system.

This is far from perfect. How frustrating is it to react to a text on iOS, but because someone on the thread is on Android, you get another text with: Liked “repeat of the message”. I see this and conspiracy theories start up in my head…. Surely you could write the Regex to see the pattern and just show the reaction on that message :/

And then there is Spotify and podcasts. Originally, you were very much locked in, but recently Spotify supported RSS and your ability to monetize your own way if you wish. If you can offer choice to developers where they can get different levels of integration based on the direction they go (doing extra work for a platform vs. open standards) that is a real trade off with real choice. Once again though, far from perfect, and I am frustrated with Spotify sucking up “exclusives”, and shoving podcasts down my throat in the app when I just use it for music.

What would this look like for the Web? The standards (and really the implementation of them… which is why compat efforts will always be so important) are the interop layer that gives you the base level functionality and allows you to reach every user with a device that implements a web client. We use progressive enhancement as always to do the right thing to make the experience work as well as it can for the given device and modalities and browser and version that a user is browsing your site with.

But we progressively enhance further, breaking out of the sandbox as needed. The starting point is on getting browser vendors onboard, but if to bogged down you aren’t stuck. We lean into Capacitor type approaches, letting you reach to native when needed, and getting you into the stores that don’t support you with a simple URL. Platforms can give you extras and you can choose to put in the extra work to enhance to them if the ROI is there. We learn from this evolution and always push to eventually bake it into the standards. Just like how I wish that reactions get baked into new versions of texting standards, and how chat apps could eventually get interop (fun fact: I used to be an IRC admin for the University of Minnesota!)

What does this look like?

Let’s say I build an image editor application. On ChromeOS the web is the app platform, so I want my users to be able to double click on the PNG file on their desktop and have it launch and load in the PWA. If this feature isn’t fully implemented on other browsers, give me a way to do it on ChromeOS first. It’s OK!

Now let’s say we want to bring this editor to mobile and are frustrated at the lack of support for *simple* features such as access to a file system. If one OS isn’t getting you what you need, we break off and have a wrapper API that bridges through the native SDK. We have polyfills where we can, and clean ways to use enhanced APIs that don’t break the web experience when we can’t. We can even embrace the fact that the app install step is a nod that the user cares about this experience.

Trust is important. The ephemeral nature of the web is key, and I’m all for leveling the field, but we also need user signals that don’t make UX of an API awful.

Let’s take the image editor example and say that we want to add rich font support and we want to be able to access your local system fonts. If you meet with the security and privacy team first they may point out that a web site knowing which fonts you have is just what finger printing folks would love to see. Instead, what if we protect users and when you sign in we ask users to choose which fonts they want to share…. Like sharing images via a picker vs granting access to your camera roll. You nod for a bit, and then you think through that UX.

Wait, how do I know which fonts I want to use in the future? In my editor I want users to be able to play with their design and quickly flip through fonts to see how they look with the content I have?

Now imagine that this image editor is from Adobe, and picture the user…. Logging into creative cloud which they pay for, and seeing this? Does this keep them safe? Or does it result in closing the web app and just switching to native?

We have this working now!

We a history of this evolution. On desktop with Electron, and a huge number of mobile apps embed WebViews, use custom bridges, and use products such as Capacitor.

And we are seeing success stories, particularly within certain verticals such as enterprise and publishing. I remember meeting with a huge media company in Latin America who switched from their native apps to using web + native where needed. It wasn’t just useful for their general ROI, all of their metrics went up and to the right:

• Positive App Store ratings increased by 25%
• App size was reduced by 70%
• Crashes reduced by about 80%
• Engagement increased.

But how? Well, context matters. They had a large web team and small native teams and this resulted in native always being far behind in features and the overall quality not being the best. You don’t get platform leverage for free. You still need native skills but a core group could watch over some of that and the feature teams could run faster.

And now when this years SDK comes out, they can bridge over to it and access that new branch of evolution.

Let’s consider how to keep up the pace and deliver on user and developer expectations by offering progressive enhancement down to the underlying platform vis escape hatches, and do it in a way that learns from the past (e.g. MS universal apps) allowing us to be constantly merging improvements into main, which are the web standards that we hold dear.