DEV Community: Toni Engelhardt

Which WebAPIs are supported on this device in this browser?

Toni Engelhardt — Thu, 27 Oct 2022 16:05:15 +0000

I had trouble finding this out while working on two side project, both PWAs, Journalistic and RepoTracker.

As I ended up adding developer-only pages to each app, checking and displaying the status of the WebAPIs that I wanted to use and testing it in different browsers, I realized that is stupid. Better to have a tool that can do that independently of my apps without the hassle.

A few hours later webapicheck.com was up and running. Atm there are only a couple dozen APIs that get checked but I'm adding more as we speak.

It's ridiculously easy to use. Just open the page on the device and with the browser you want to check and you get an instant visual overview of the APIs that are supported/not supported and whether or not they are in experimental stage. Selected APIs even have a quick test with which you can try the APIs and play around at the click of a button.

If you're building modern web apps, try it out, would love to get some feedback.

🙏🏽 ✌🏽

Let’s build a Native(-like) Web App (NWA)

Toni Engelhardt — Tue, 27 Sep 2022 21:14:50 +0000

…and with that, I mean a web app that works and feels exactly like a native app.

Why, what’s wrong with native apps?

Let’s say you come up with a great concept for an app or service, e.g. in my case, a minimalistic micro journaling app. You naturally want it to be available to as many users as possible, no matter where they live and which device(s) they choose to have on their desk, wrist, and/or in their pocket.

For a decent-size corporation that is no big deal, just let your product team come up with a design and hire a bunch of Android-, iOS-, and web devs to implement a version for each platform (3 in total). But for a small organization or an indie hacker that is not an option, you just don’t have the resources to build and maintain three apps.

Well, there are cross-platform solutions out there. The usual suspects are React Native, Ionic, and Flutter. They are all great and give you access to native device APIs. React Native and Ionic even allow you to use the web stack (HTML, JS/JSX, CSS) and frameworks like React or Vue to build your app fast.

(Thanks to Daniel Roe, using Nuxt will soon also be an option with nuxt/ionic)

Image from enappd

Nice, but they all share one problem: the app still needs to be packaged (several times), deployed to the web, and submitted to the respective stores of Apple, Google, and Microsoft.

This is annoying because updates to your app will be delayed by the review processes of each store as well as by users just deciding to not update their apps for ages. Your backend/API, therefore, has to be able, in theory, to work with every version of your app that ever existed. Meee…

Additionally, you are forced to implement multiple payment solutions (including accounting!) according to store policies (3 in this case, plus 1 for the web). And what if you want to accept Lightning payments for example?

What about Progressive Web Apps (PWAs)?

Progressive Web Apps (PWAs) are great and you can even publish them — with limitations — to most of the app stores out there via tools like bubblewrap or PWA Builder. See also Trusted Web Activities (TWAs) and my previous post Publishing a Progressive Web App (PWA) on the PlayStore — What works and what doesn’t (in 2021).

Image from web.dev

But progressive loading and caching are not really what we want when we’re talking about a “native-like” app.

A native app, once downloaded, works offline. That’s also the premise of a PWA, but a Progressive Web App (as the “P” in the name suggests) will only cache pages and update them when visited. So, the app is not really fully offline capable, but rather online with a fallback.

This behavior is useful to enhance the experience of web services and there are stats to prove it, but for a lot of use cases, i.a. my journaling app, this will just not work.

So let’s tweak it a bit…

Native Web Apps (NWAs)

What we really want is a PWA with impromtu caching and immediate full-offline support.

What would it look like?

Let’s look at an idealized concept that would resolve (almost) all of the problems we currently face with native apps as well as PWAs.

Instead of consulting an app store, you open the homepage of the app that you want to acquire, e.g. www.journalisticapp.com. There are two options here, either you are prompted with an install banner à la PWA or there is an install button triggering the installation manually. Ideally, the choice between the two options should be left to the developer.

Once the install is triggered the app will be downloaded (aka. fully cached) to the user’s device and therefore be available for offline use immediately.

There are currently no technical hurdles that stop us from implementing such an app, even though there is no out-of-the-box solution and we will have to tinker with workbox and/or service worker scripts.

However, it will be limited.

I mean, it is clear that we will have to take a performance hit when relying on a JS codebase that executes on a single thread in the browser as opposed to native Java or Swift code optimized for the chip architecture. But not all apps are performance critical. Those that are will not get around a native implementation any time soon I guess.

So what’s missing?

While progress is being made to enable access to more and more device APIs via Web APIs, there are still a lot of critical ones that are missing, e.g. control over the navigation bar color, access to a device’s security chip, or biometric authentication.

It would also be important for an NWA to have dedicated storage that is not shared with the browser and that can be encrypted and/or blocked, e.g. when the user is not authenticated or has locked the app. As of this writing, the only feasible storage option for the web that ships with the browser is IndexedDB.

Summary

It would be amazing to have web apps that are indistinguishable from native apps that combine the best of both worlds and that can be downloaded directly from the web. The latter is especially important when contemplating the decentralized future of applications and web3.

In all likelihood, I’ll keep going down the NWA rabbit hole with Journalistic and keep reporting back on how far I’ll get in the quest to build a web app that is indistinguishable from its native counterparts.

Thanks for reading and have a wonderful day ✌🏽

Talking Privacy of Journaling Apps

Toni Engelhardt — Tue, 12 Jul 2022 08:36:05 +0000

Privacy always comes at a cost. Let's discuss the pros and cons, and UX tradeoffs of different privacy strategies and find out whether or not your journal entries stay private.

”Will my journal entries stay private?” is one of the questions I get asked frequently by Journalistic diarists, so I want
to address it in detail in this post.

In a perfect world, the answer would be ”Yes, of course!”, but in reality, if we are honest, it’s not that simple. First of all, ”What do you mean with ‘private’?”. We will see that it is not so much a matter of technical challenges and
monetization strategies, but more about UX tradeoffs, convenience, and legislation.

Grab a coffee and get comfy, this is a long one.

The White Rhino

It’s always a good idea to lay out the ideal scenario and then try to minimize the concessions that inevitably will have to be made.

The perfect, privacy-focused journaling app would IMO satisfy – among others – the following requirements:

Only users can access their entries without exception
Entries are synced instantly across all of the user's devices
If a device (or all devices) are damaged, lost, or stolen, the entries can be fully recovered
Recovery should also be possible if a user forgets their password or is not able to provide the required means of authentication (fingerprint, etc.)

The White Rhino is a metaphor for rare or elusive things.

I’ll try to make the case that achieving all of the above simultaneously is
(virtually?) impossible and that we have to make some compromises to optimize user happiness.

As a side note... While journaling apps have extremely high privacy requirements, similar challenges apply to almost any web-based app that deals with private user data.

Privacy-enhancing strategies

First, let’s look at some methods that are commonly used to enhance the data
privacy of consumer apps and afterward analyze whether it makes sense to utilize them for our journaling app or not.

Encryption

Using cryptography to keep data private is an ancient concept, dating back to the medieval ages. But advances in Mathematics and access to great amounts of processing power in every device make it now feasible to seamlessly integrate encryption mechanisms into real-time applications.

When appropriate algorithms are used it is currently impossible to viably decipher encrypted data. Journal entries stored on cloud servers could therefore be reliably protected from unwanted access when encrypted.

The Achilles Heel of encryption is the encryption key, which has to be taken care of by the user. If the key is lost, the data is gone for good. More on that later.

Pseudonymity

Pseudonymity refers to the separation of data from identity. For instance, a user could create a brand new email address, which doesn’t hint at their name, and then use it to sign up for the journaling service. If they do not tell anyone about their new virtual identity their data might be accessed, but it cannot be linked to them.

I guess this is a good opportunity to introduce the two types of private data we have to worry about:

Personal data
People usually do not want strangers to know what they think and what they do at any given time, unless they choose to share it. This is more or less our common definition of privacy and also exactly the kind of information someone would store in a journal.
Secret data
Secret data either holds value in itself, e.g. intellectual property, insider knowledge, etc., or can endanger the safety or property of individuals or groups if exposed. Think credit card information for example.

Pseudonymity is only useful (to a certain degree) to protect personal data. Most people would probably not care if their daily logs got leaked if they could be 100% sure, that nobody would ever find out that they wrote them. In practice, this guarantee can never be given and the more personal the data is (think names aso.) the easier it becomes to link it to a person.

To protect secret data, pseudonymity is useless.

A great example of pseudonymity is the Bitcoin protocol. While the protocol leverages strong encryption to protect the network itself, wallet addresses and transactions are pseudonymous and easily accessible for everyone in the public ledger. Since the addresses are only strings of seemingly random letters and numbers, privacy is protected until a wallet is at some point linked to an identity.

Local data storage and peer-to-peer sync

The most stringent strategy to enhance privacy is to store data exclusively on devices that the user physically controls and that nobody else has access to, e.g. a mobile phone. This is usually referred to as local data storage.

To synchronize locally-only stored data between devices they have to communicate directly with each other – peer to peer – without a middleman. Thanks to encryption, this is even possible through public networks.

Analyzing the requirements

Let’s go through the requirements one by one, clearly define why they are important, how they can be implemented, and also where the challenges are.

Only users can access their entries without exception

Why is it important?

As mentioned above, users want their entries to be private, and if third parties can access a user’s journal entries, the user has to trust each of those parties to keep the data private and secure. There is no way around it.

In general, the more parties have access to your data, the more likely it is that one of those parties is not acting in good faith, accidentally leaks the data, or becomes the target of a hack.

Depending on the jurisdiction in which the third parties are located, it is also possible that a court can subpoena private data, or that a government agency actively spies on citizens (see for instance the
Snowden leaks¹).

How can it be done?

The two ways to make sure that no one can access a user’s private data, except for the user, are:

Encryption
Local data storage only

What are the problems?

First of all, both techniques only work reliably if the software is flawless (app and encryption mechanisms/libraries). Bugs might easily lead to data leaks (e.g. the Heartbleed bug²).
The hardware can also have design flaws, see for instance the Meltdown vulnerability³.

But let’s assume that software, hardware, and app are immaculate. Then it comes down to the single user.
The elephant in the room for this one is data loss. If only the user has access to their data, they also bear all the responsibility for storing and/or accessing it.

In the case of encryption, data can be backed up the same way as unencrypted data, but if the encryption key is lost, your journal entries are encrypted for good. Potentially years’ worth of reflections – gone. Bummer!

Violation of requirement #4.

Here's a story where losing encryption keys went wrong big time: Half a Billion in Bitcoin, Lost in the Dump.

For local storage only the problem is more on the backing-things-up side (discussed in the next section).
A user might also only have one device – most likely a phone – which can be lost or stolen; or multiple devices, that all get destroyed simultaneously, for example in a fire.

Violation of requirement #3.

Entries are synced instantly across all of the user's devices

Why is it important?

It’s simply a matter of convenience and great user experience. Depending on the situation, you might want to write entries on your MacBook, where typing is more convenient; or access them on the go, on your phone, when you do not have your laptop at hand. Being always with you is one of the great advantages of an app over a paper journal. In the case of local storage-only, instant sync is also essential for backups.

How can it be done?

Data syncing has its own challenges, especially if devices do not have a stable internet connection or are disconnected from the web entirely for long periods. But that’s a topic for another day.

Data can be synced either peer-to-peer (see above), or traditionally via a central web server. Almost all web services you know (Gmail, Dropbox, Evernote, you name it...), use the latter.

What are the problems?

If devices need to communicate directly to exchange data in the peer-to-peer case, continuous synchronization is difficult, e.g. all devices would need to be ON all the time and connected to the network to be able to provide their latest updates when another device performs a sync.

Since there is no single device in a peer-to-peer network that serves as a master node, inconsistencies can occur when different devices resolve conflicts and do not immediately broadcast the changes to all other devices.

Using a central server circumvents these problems by being always available and serving as the single source of truth by always keeping the most up-to-date state.

The downside is that the service provider and/or a third party have physical access to the hardware on which the data is stored.

If a device (or all devices) is damaged, lost, or stolen, the entries can be fully recovered

Why is it important?

In almost all cases complete data loss is probably the worst-case scenario.

How can it be done?

Data should be backed up multiple times (at least 3x, ideally more) in as many different physical locations as possible. Physical distance is important in cases of black swan events where all devices in a location can be lost or destroyed, e.g. burglary, flooding, etc.

What are the problems?

With a local storage-only system, it might be inconvenient or even impossible for a user to establish 3+ backups on different devices and separate them spatially at all times.

In the conventional case, this responsibility is shifted to the cloud service provider. Their advantage is that they are professionals and safely storing data is their business.

Recovery should also be possible if a user forgets their password or is not able to provide the required means of authentication

Why is it important?

Again, complete data loss might be the worst-case scenario.

How can it be done?

The only way to achieve this is to entrust the service provider or a third party with a master key to your data. This applies both to encryption and authentication.

Violation of requirement #1.

What are the problems?

Being able to recover your entries after losing your password or encryption key can only be achieved by giving up a certain degree of privacy, at least if you define it most stringently. Password reset always requires trust.

Keep in mind that if a web service claims your data is encrypted, but you can reset your password, they at least have a key as well, otherwise they would not be able to help you out. And then, what’s the point?

Concessions, trust, and risks

As we’ve seen, it is not possible to fulfill all four requirements we set simultaneously, so we have to prioritize and balance the cost versus benefit of each of the privacy strategies and accommodate for their incompatibilities. This is also where we’ll leave the realm of objectivity and enter the world of the opinionated design principles and ideologies behind Journalistic specifically (see About page).

I’ll try to explain the reasoning behind all privacy-related design decisions and will attempt to answer the question that led us here:

”Will my journal entries stay private?”

Avoiding data loss at all cost

I already mentioned that IMO complete data loss is the worst-case scenario. How many times have you reset a password in the past? And what if you couldn't do that?

Therefore, unfortunately, we have to compromise on both encryption and local storage-only. At least in the default case. It might be possible to opt-in to either of those in the future if you prioritize privacy over data recovery. Have a look at the Voynich Project if you want to know more.

Does that mean my data is not private?

No!

It means that you have to trust us and our meticulously selected third-party service providers to keep your data safe and private.

Who you need to trust

Journalistic

You have to trust us. Obviously.

In any case, unless you are an expert in software and security, you will always have to trust at least the service provider (the organization behind the app/website you are using). If a service you use wanted to spy on you they could just add a backdoor to their encryption algorithm or broadcast data without your knowledge.

But you also need to trust the service provider that their highest priority is user satisfaction, not profit and that they take privacy seriously.

Being a tiny organization is advantageous here, versus a big corporation with stakeholders that are only in for the bucks.

We strongly believe that transparency builds trust. In the end, this is why I’m sitting here writing this lengthy post.

Digital Ocean

We use Digital Ocean as our cloud service provider. DO is a US company, but the servers we rent from them are located in the European Union. European data protection rules (GDPR) therefore apply.

As explained in this thread, it is not in their interest to go out of their way to access data we store on one of their servers, even though they theoretically could.

Relying on a professional cloud service provider is, especially for small organizations, more secure than running, protecting, and maintaining an in-house infrastructure.

Third-party services

Specifically for privacy reasons, we keep reliance on third-party services at a minimum and currently only use Sentry for error monitoring and Plausible Analytics to gather usage data.

Encryption in transit

While end-to-end encryption is risky, encrypting data while it moves over the wire is standard as of 2022 via SSL (known as https). Your data will always be encrypted when it moves through infrastructure that is not controlled by you, by us, or by Digital Ocean.

Risks and word of caution

While we do everything in our power to keep your data safe, there is always the risk of a hack. I therefore strongly encourage you to not add content to your journaling app that could harm you or anyone else if exposed. This warning applies to Journalistic as well as for any other journaling app, whether it is encrypted or not!

What about pseudonymity?

It is completely up to you to activate “stealth mode” and add an additional safety layer to your privacy. Here is how it works. Just create a new email address that doesn’t have your name in it and exclusively use it to sign up for Journalistic. You can get free email accounts from Gmail, Yahoo! Mail, etc. In case of a data leak, your journal will be only one among thousands.

We might integrate pseudonymity directly into our service in the future via a service like Evervault.

Verdict, and looking ahead

Beware of the black swan!

The [...] theory of black swan events is a metaphor that describes an event that comes as a surprise, has a major effect, and is often inappropriately rationalized after the fact with the benefit of hindsight (Wikipedia).

I would claim that any web-based service that asserts that your data is 100% safe is either ignorant, rounding up, or straight out lying. And it surely is the more responsible approach to be rather cautious and transparent than overconfident. There is always the risk of a system failure or an unforeseen security vulnerability.

That being said, Journalistic is designed to be secure and private, and if we assume that our software works as intended your journal entries will stay private. We will not ever sell or intentionally give away your data to third parties without your explicit consent!

To answer another often asked question: this is also why we chose to rely on a business model with a paid PRO version for advanced users (not yet available) to fund the development and operation of Journalistic instead of selling data for dollars.

Regarding the future… We are committed to continuously refining our software design to make systemic failure as unlikely as possible. Furthermore, we’ll keep experimenting and testing opt-in features like encryption and local-only data storage and give you the option to use them.

Feedback and suggestions

If you have any suggestions regarding our approach towards data privacy, our Privacy Policy, or general feedback, please send it our way to feedback@journalisticapp.com.

In 2013, Edward Snowden exposed a secret, large-scale spying operation on private citizens, coordinated between the NSA and the US government: NSA Files Decoded. ↩
Heartbleed was a security bug in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security protocol (Wikipedia). ↩
Meltdown is a hardware vulnerability affecting Intel x86 microprocessors, IBM POWER processors, and some ARM-based microprocessors. It allows a rogue process to read all memory, even when it is not authorized to do so. Meltdown affects a wide range of systems (Wikipedia). ↩

Augmenting GitHub repository stats and insights

Toni Engelhardt — Sat, 02 Apr 2022 11:49:35 +0000

While GitHub is amazing (hence, their insane market share), they unfortunately provide only very limited insights for the repositories that they host. Moreover, most of the stats in the "Insights" tab are only available for PRO users when the repo is private.

Therefore, I set out to build a tool that augments those insights with loads of cool charts and cards. You can read the full story on why in this post.

RepoTracker is designed for two user groups:

Open source devs and -users that want to keep up with the latest changes, issues, etc. in the pre-rc repositories that they are working/playing with.
Professional software developers and dev ops peeps that need to know which of the packages their software depends on are properly maintained and which are not.

If you breathe software, try it out at www.repo-tracker.com, it's free!

I'd love to hear what you think about the project and which metrics you would be interested in as a developer ✌🏽

Made with Nuxt 3.

I made a GitHub repo tracker with Nuxt 3 to track when Nuxt 3 is ready

Toni Engelhardt — Fri, 11 Feb 2022 01:02:31 +0000

Ever since Vue 3 One Piece was officially released in September 2020 by Evan You, we Nuxters have been waiting for Nuxt to catch up so that our projects could also finally benefit from all the cool new stuff (script setup, reactive CSS properties, portals, and what not...).

And the wait has been long, painfully long!

Composition API has been partially backported, but it's just not the real deal and it's already clear that most of the code we henceforth write for Nuxt 2 will probably have to be refactored in some way or another for Nuxt 3. That's obviously a bummer and highly demotivating.

And then there are also Dom, Saito, and all the other guys starting new Nuxt projects right now, stuck in limbo, not knowing whether to start with Nuxt 2 or rather wait for v3 RC.

Fortunately, Nuxt 3 public beta dropped in October last year and everybody was happy, right? Right?! Well, not really...

I dropped Nuxt Bridge into my pet project (Journalistic) and started migrating, testing, asking, and answering questions on Discord, opening issues and PRs on GitHub, thinking that by the year's end it'd be running at least on Bridge, if not even v3.

But it quickly became clear that it would not be such a smooth transition. The problem is not even Nuxt itself (Daniel, Pooya, Antfu and others are doing an incredible job, fixing issues and helping folks out), but rather the ecosystem, aka. community module support.

As of now (4 month after release), only 13 out of 191 modules officially support Bridge and 12 support v3.

Hello RepoTracker

So I thought, f*ck it, I'm gonna build and ship a simple app with Nuxt 3 beta, just to see how it works, what the differences are, and how far I can get. And to cut a second bird's life short with the same pitch I'll solve the problem of keeping track of all the changes and updates in all the Nuxt-related module repositories.

And it was a blast, Nuxt 3 is so much fun, a massive improvement, even over the already great Nuxt 2. The DX is just another level.

You can take a look at the result and play around with it at repo-tracker.com (made with Nuxt 3, Vite, Pinia, and windicss).

What's next?

That was last week and the response has been really great so far. While working on the project it dawned on me that a cross-platform (GitHub, GitLab, BitBucket) repository tracking/analytics dashboard might have quite some potential, for open-source development, as well as in a professional software development context.

I'll add some additional features, like drag-n-drop package.json and requirements.txt file import, repo lists, insights charts, etc. and see where it goes.

Thanks for reading and have a wonderful day ✌🏽

Publishing a Progressive Web App (PWA) on the PlayStore – What works and what doesn’t (in 2022)

Toni Engelhardt — Mon, 12 Apr 2021 19:19:14 +0000

I’ve been working on a micro journaling app (PWA) over the last year, thinking that with a little notching users would just get used to installing apps directly from their browser, but errrrr…

Turns out they don’t. Not yet.

So I was stoked when I realized that with Google’s Trusted Web Activities (TWA) you can just publish a PWA on the PlayStore.

The result is actually pretty great, you can check it out here: Journalistic app on Google Play. It quacks like a duck, mostly…

Journalistic TWA screenshots: text input, lists, charts, menu

The stack behind Journalistic is Django and Nuxt. The nuxt/pwa module takes care of everything PWA-related on the app side: manifest, service worker, etc. Easy peasy.

Generating the app bundle is also more or less straight forward if you use bubblewrap. There are some pitfalls with the app signing shenanigans but after a few hours I managed to have a working bundle and it went straight into the PlayStore review process.

Turns out that Saturday was well spent, more than 80% of new signups come through the PlayStore now, without any buck or minute spent on promoting the listing (except the 25€ one-time fee for the Google developer account).

There is quite some hacking required to make the web app truly behave like a native app, especially on the CSS side, but it can be done for the better part. Since there are already a lot of posts about this topic I won’t get into details here. Let’s look at what doesn’t work well (yet).

Bummers

Navigation bar color

You can customize the navigation bar color in the app manifest, but only static. For a lot of apps that might be enough, but if you have a dark mode for instance and want the user to be able to turn it on/off manually via a setting in the app you have a problem. I’ve raised the issue with bubblewrap developers and the problem clearly is a lack of support on the Chrome side.

I’ve resolved this to some extend by detecting and using the system theme as default (you can specify a color for light- and for dark mode). This works well until the user decides to choose a theme manually. If the device is in dark mode and the selected theme is “light”, things are not so bad, you get a black bar at the bottom, not ideal, but not too bad either. But if the device is in light mode and the user chooses a dark theme they get a dark app with a white bar on the bottom and that is really not cool.

Status bar color

You can also customize the status bar color, even dynamically, until again, dark mode. When the device is in dark mode it will always use a weird dark gray as background for the status bar, which raises the question: “WHY?!!”. Same problem, the limitation is on Chrome side.

Performance

Javascript is single-threaded. You can achieve multi-threading with web workers, but for most use cases they don’t bring any benefit and for others implementation is quite tricky. As a result, a TWA will feel clunky and less responsive when compared to a native app. Especially scroll animations, chart rendering, aso. can introduce quite some lag and compromise UX.

Text input

Text input is generally a big problem on mobile devices and it gets even worse if you’re in a browser. While you have some control over input elements in native apps, dealing with is simply a nightmare. On top of that you have no control or even knowledge over what the soft touch keyboard is doing. Eventually you’ll have to adjust (and probably compromise) your design to cope with the weirdness.

Ah right, if you have a nav bar at the bottom, you’re f***ed anyway.

Journalistic UX example for text input with controls

Monetization

Google is currently running trials in Chrome (88 and 89) to integrate Play Billing via the Payment Request and Digital Goods APIs. This is definitely a big step in the right direction, but it will probably still take a bit until this is fully supported.

If you want to monetize your app, this might be the dealbreaker and even if Play Billing is fully available eventually you will still have to shoulder the burden of integrating two different payment systems, the Google one and the one you use for the web app (Stripe or whatever).

Data storage

You can of course use local storage, just like in the browser, but if the user erases their Chrome storage it will also wipe out your app’s data, which is something most users would certainly not expect. So far I haven’t found a way around this, but tbh also haven’t been looking a lot.

Annoying “Running in Chrome” banner

When opening the app for the first time the TWA will display a banner notifying the user in which browser it is running. This is in my opinion completely unnecessary and annoying. It just confuses users and gives the impression of a “fake” app. A better alternative would be to only display the banner if the app was installed with a browser that is not the default.

Device APIs

Chrome already supports a lot of device APIs (way more than Safari for instance), but some important ones are still missing and some have really bad UX. If you want to access Bluetooth for instance via BLE, Chrome will drop an ugly browser menu in the pairing process.

All in all

All in all, depending on your use case you can already get quite close to a native experience. Most of the outstanding issues are annoying but minor and could be (and hopefully will be) easily resolved on the Chrome side. Sadly progress is pretty slow here.

Over the long run I see the above mentioned performance issues as the biggest limitation for PWAs compared to their native counterparts and the question is whether advances in web tech and on the framework side will be able to close the gap.

Daydreaming

Chrome

I hope that in the future Chrome will support dynamic theming for the status- as well as for the navigation bar via meta tags (text- and background color) and get rid of the weird behavior in dark mode.

Removing the “Running in Chrome” banner or introducing a more user-friendly UX for it would also be amazing.

I’m not sure if that would even be possible, but giving TWAs their own local storage and cookies, independent from Chrome, would be totally sick.

Payments

Can there not be a single API that you can integrate and it figures out automatically who gets their cut when someone purchases something? 💭