The Future of Progressive Web Applications (PWAs) in Capital Markets

10th July 2024

The Future of Progressive Web Applications (PWAs) in Capital Markets

The Capital Markets Web Platform Landscape

Uncertainty about app store rules has dramatically increased. Recently, various players in the financial markets have seen their business affected by changes regarding what applications (apps) can be published and distributed via those app stores. These changes originate either directly from vendors, or as a reaction to local regulations. In this context, PWAs (Progressive Web Apps), gain competitive advantage.

What you’ll find in this article:

MetaQuotes’s App, MetaTrader, banned from AppStore

In 2023, MetaQuotes saw its business affected by both of the above reasons. First, Apple banned MetaTrader from its App Store, claiming MetaQuotes instruments didn’t comply with its App Store rules. Then in 2024, MetaTrader apps were removed from Indian Google Play Store due to local regulation changes.

Under these circumstances, sometimes it is possible to make changes to application code and re-submit apps for revision. This is the path that MetaQuotes followed with Apple, which resulted in getting its apps re-published. But dealing with local regulations might be more complicated.

Some commentators have argued that customers are willing to move to web-based platforms, where businesses can publish content directly. This approach allows to remove some of the publishing hurdles around app stores, but more importantly, allows to keep a non-interrupted presence in the market. And as we have seen before, the web platform is rich in features that can be used to build compelling experiences for your users.

But the web platform comes with challenges of its own, more prominently, the restriction in features we observe in iOS. Historically, Apple has not fully adopted the web platform, and features like notifications have lagged behind Android. The story in this arena is different, because in this case regulators advocate for openness and feature parity. A recent attempt from Apple to downgrade installed web apps to shortcuts in iOS for the European Union, kick-started an effusive response from the web community, as can be reflected in the Open Letter to Tim Cook. This decision was later reversed by Apple, which evidences how strong is the position of the web platform in the market.

Implications of App Store Bans on Capital Markets Firms

App store bans can cause significant losses for companies within capital markets as they hinder traders’ access to the trading platforms. When an app is removed from an app store, existing users might be unable to receive updates, whilst new users can’t download the app at all. This disruption can result in a reduction in trading volumes and user engagement in the long run, affecting the organization’s profitability. Moreover, there is a reputational risk, as users could perceive the ban as a sign of regulatory or security concerns, prompting them to switch.

Lastly app store rules can vary by geography or country. Therefore, users in certain regions might have access whilst other do not, potentially excluding a lucrative portion of the market.

Staying Competitive Without Relying on Third-Party Ecosystems

As we have seen, reliance on native app stores can have revenue and reputational implications and put corporations at a competitive disadvantage, particularly when their apps are banned or restricted. One alternative are Progressive Web Apps (PWAs), which will be explained in more technical depth below. PWAs don’t have the same App Store limitations and can provide firms direct access to users via web browsers, ensuring a wider reach and consistent UX across different markets.

Additionally, PWAs can be updated instantly, ensuring access to the latest features and security patches without the need to wait for App Store approvals. This agility in delivering updates and maintaining 24/7 service enhances a firm’s competitive advantage. Adopting Progressive Web Applications (PWAs) can provide a more stable, flexible, and user-friendly platform, ensure uninterrupted service and broader market access, and additionally foster innovation and enhance consumer experience.

What are PWAs and what is progressive enhancement?

PWA stands for Progressive Web Application, and progressive enhancement is a well honed practice in web development, which in its origins is an adaptability response to the ever changing environment of early web applications.

According to MDN:

“Progressive enhancement is a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.”
—MDN

And it is from this design philosophy that PWAs originate. Again from MDN:

A progressive web app (PWA) is an app that’s built using web platform technologies, but that provides a user experience like that of a platform-specific app.
—MDN

The definition from MDN highlights the importance of delivering features that take web applications closer to the performance of native applications, which is what most of us assume today when we talk about PWA: a web app that performs like a mobile or desktop native app. But the term also refers to the use of modern technologies, and as we have said before, being able to bring cutting edge features to users as soon as they become available. In that sense, the definition from web.dev is very appropriate:

“Progressive Web Apps (PWA) are web apps built and enhanced with modern APIs to provide enhanced capabilities while still reaching any web user on any device with a single codebase. They combine the broad reach of web apps with the rich capabilities of platform-specific apps to enhance the user experience.”
—web.dev

But one thing to remember is that PWAs adhere to a way of designing software that builds on the long tradition of progressive enhancement. According to MDN:

While progressive enhancement is a desirable attribute for most websites, it is especially important for PWAs, which expect to run on a wide range of devices and often use advanced Web APIs which may not be supported by all browsers
—MDN

The Market move from Native to Browser-based Applications

In the past, there were considerable differences between web browsers. Some browsers did have features that were missing in other browsers, or the same feature could be implemented differently across browser vendors. At the same time, significant segments of users could be stuck with old browser versions, which encouraged web developers to be cautious when choosing core features for their applications.

But there have been unifying forces. Today, open source browser engines like Chromium and WebKit are the foundation of most modern browsers, resolving feature parity by construction. And adding automatic updates to this common foundation results in much shorter waiting times for new features to become available to your user base.

In this scenario we can find a set of features available in all major browsers today that can bring your web application performance closer to native apps, while at the same time making them resilient and accessible to an even larger user base than a single native app could ever do. So yes, your users are probably ready, but most likely they are already waiting for a PWA!

Where to start when considering PWAs for your trading needs?

After gathering requirements, make sure the features needed to implement such requirements are well supported for our users. This process can be divided in two steps:

  1. Identifying the target browsers and creating a browser compatibility matrix*.
  2. Verifying the support status of each required feature using the browser matrix.

*A browser compatibility matrix is a list of browsers, browser versions, devices and operative systems in which our application is expected to be supported.

Creating a browser compatibility matrix

In order to create the browser compatibility matrix, we’re going to be looking at:

  1. Browser market share
  2. Individual browser version market share.

Each business and organisations will have different statistics, but as long as they are taken into account it should be possible to add progressive enhancements to your web app.

We’re now going to develop an example in which we identify a target browser and a target version for the same browser. Later on we will use this information to choose some modern browser features to add to a fictional web application

Your marketing team may have statistics describing your user’s browser market share. For this example we’ll use publicly available global statistics for desktop browsers from Statcounter. The first piece of information we want to find is which one is the most commonly used browser.

Progressive Web Apps (PWAs) in Capital Markets - Browser Market Share
Browser Market Share – Data from Statcounter

In April 2024, the most popular browser globally is Chrome. Knowing that let’s now look more closely into which versions we want to support. Clearly the most popular version is 123.0, followed by 122.0. We could choose to support the latest version only, or the latest two versions, and so on. This is commonly referred to latest-n versions, where you support only the latest version and a fixed number of previous versions in a “moving window” style, where support keeps moving as versions keep changing. In our example, we’ll only support the latest version.

Today, many browsers are based on The Chromium Project, for example Microsoft Edge and Opera. This means that adding Chrome to your browser matrix will by extent add some level of support for other Chromium based browsers. Always verify feature parity before making any assumptions.**

Progressive Web Apps (PWAs) in Capital Markets - Chrome Desktop Market Share
Chrome Desktop Market Share – Data from Statcounter

If you repeat this process for, lets say, the top 3 browser engines along with the their latest-n versions, then you will have a browser matrix that can be used to select well supported features for your PWA.

Using the browser compatibility matrix to validate feature support for your PWA

With your browser matrix in place, you can now start looking into implementing requirements using the latest web technologies. For this example, we are going to imagine we have an initial requirement:

Users should be able to launch our application with the same user experience as native applications.

This means, for example, that our users should be able to launch our app from the Start menu in Windows and from Spotlight in MacOs. Also, when the application launches, we would not expect our users to see an address bar, or other of the characteristic features of web applications running in the browser.

In order to implement this requirement, we need to ensure all the browsers in our browser matrix can read and understand a web app manifest. From MDN:

A web application manifest, defined in the Web Application Manifest specification, is a JSON text file that provides information about a web application.

The most common use for a web application manifest is to provide information that the browser needs to install a progressive web app (PWA) on a device, such as the app’s name and icon.
—MDN

A web app manifest defines a list of members, each one controlling a particular aspect of how a PWA behaves. Support for each member varies, but luckily we don’t need to support all members. The minimal supported members for Chromium-based browsers we need to implement our requirements are:

You can follow the links to learn more about what each of these members do.

With a much clearer picture now, we need to find out if we can deliver the requirement for our current browser matrix. There are at least two ways of doing this.

One way is to follow one of the links from above and scroll down to the end of the page, where MDN adds support tables to their documentation. Looking at the support table for name we can see the feature is available since Chrome 39:

Progressive Web Apps (PWAs) in Capital Markets - Browser Compatibility
Browser Compatibility – Web App Manifest

An alternative way is to make a Can I use? query:

“Can I use” provides up-to-date browser support tables for support of front-end web technologies on desktop and mobile web browsers.
—Can I use?

Issuing the query for web app manifest name member, we get a similar picture to what we’ve already seen in MDN, full support in Chrome 39:

Progressive Web Apps (PWAs) in Capital Markets - Query for Web App Manifest Name Member
Can I Use? – Query for Web App Manifest Name Member

If we repeat this process for each one of the browsers in our browser matrix and each one of the web app manifest members we require for our feature, then we will have a verification of whether our browser matrix has enough support to implement our requirement. In our case it does, so now we can carry on with the implementation.

PWAs Built by Adaptive

At Adaptive, we have been trusted by our clients to collaborate with them bringing their businesses into the web platform. We have built compelling experiences that make use of many modern day technologies, and can be delivered to clients at any time, bringing value directly to customers with speed and agility.

These are some of the features we deliver successfully on a regular basis:

  • Web app manifest to make applications installable both in desktop and mobile devices.
  • Static asset caching with service workers for faster initial loading times.
  • Computational expensive storage offloaded to IndexedDB for non-blocking asynchronous processing.

The web platform and PWA is the platform for today

If there is one takeaway we want to pass along, it is that the web platform is mature and ready to deliver value to customers directly and efficiently. Using analytics, you can understand your audience and build products that rely on the features they already have at their disposal, all this with the confidence of having a browser grid that doesn’t leave any relevant browser behind. Building a PWA provides not only direct access to your customers, but also the backing of a vibrant community that has always strived for openness and standardisation.

Leon Coto, European Head of UI Practice at Adaptive

Leon Coto

European Head of UI Practice at Adaptive