Web Apps are Native Apps

Why native apps aren't necessarily your best option.

The CEO said:

"We need a native mobile app."

The software engineer heard:

“Build me:

1. An iOS app, written in Swift;

2. An Android app, written in Kotlin;

3. And keep maintaining the web-based version of our app that is hosted on our website.”

This probable miscommunication is underpinned by a fundamental misconception.

What is a “Native” App?

The CEO’s goal is most likely to have a downloadable, self-contained app that can be launched directly from the phone's home screen, in contrast with functionality that has to be accessed via a web browser. This app could be expected to make the user log-in using a face-print or fingerprint, and receive push notifications (for example). Such apps are typically downloadable from Apple's App Store and Google's Play Store — but this can be more of a hindrance than an advantage.

You don't actually need a native app for this — at least not in the strict technical meaning of “native”. To a software engineer, “native” means “integrates tightly and exclusively with a specific operating system and/or specific hardware.” Our CEO almost definitely did not intend this.

There is an additional option, that practically speaking, is just as native. Native to the web. Web-native apps leverage web technologies and can run smoothly and securely on any modern general purpose operating system and device. Such apps can be completely indistinguishable from classic native apps.

I have worked with numerous companies that automatically assume that apps made with web technologies cannot be as good as classic native apps, and they make the costly mistake of fragmenting their front-end technology stack.

In 80% of cases, web technologies are a perfect match for what a business needs. When used correctly, browser engines provide a fast user interface layer, and they have APIs that provide much of the hardware integration functionality that was once reserved exclusively for classic native apps.  

Web technologies have graduated to become a set of standardised APIs provided by general purpose operating systems, that provide streamlined access to lower-level resources and hardware.

Multiple Apps or One App — Which is Better? 

If you take the classically native approach, you’ll likely build and maintain multiple apps — one for each target platform. These apps all do exactly the same thing, but are re-written in different languages, using different tools. You will have multiple codebases to manage, and probably a separate engineer, or team, for each one. Good luck when you try to roll out new features in a synchronised manner. Each one will have its own peculiar customer support issues, too.

Using web technologies, you can use a single family of technologies to build and maintain a single codebase that requires fewer engineers. Not only is it cheaper to build apps using this approach, but it’s also more suited for subsequent maintenance because of the more limited competencies required.

The same web app can be deployed to all these target platforms:

1. Web site

2. Progressive Web App (PWA) — a standalone web app, see below

3. iOS app, available in the App Store

4. Android app, available via the Play Store, or as a downloadable APK file

5. Windows desktop app

6. MacOS desktop app

What is a Progressive Web App?

A Progressive¹ Web App (PWA) is a website that can put its launching icon on your phone’s home screen or your desktop’s dock or start menu, like any other app. When launched, it uses your browser’s underlying technology, but you don't necessarily see any of the browser’s “chrome”² — user interface elements such as the address bar. 

You may not even be able to distinguish between a PWA you installed from a website and an app you installed from the App Store. My desktop Gmail and Google Calendar apps happen to be PWAs. They launch from MacOS’s dock or Windows’ taskbar into their own windows, which have no browser toolbar. Unlike individual browser tabs, they are each distinct entries in the series of apps I can cycle through using Command-Tab (MacOS) or Alt-Tab (Windows).

PWAs are far smaller in download size than corresponding classic native apps, and their updates can be instantaneous, too.

Steve Jobs Makes the Case for Web Apps

When the iPhone was launched in 2007, web apps were the official way to develop apps for the iPhone. Steve Jobs gave the best sales pitch for PWAs you’ll ever hear:

“You can write amazing Web 2.0 and AJAX³ apps that look exactly, and behave exactly like apps on the iPhone. 

And these apps can integrate perfectly with iPhone services; they can make a call; they can send an email; they can look up a location on Google Maps. 

After you write them, you have instant distribution. You don’t have to worry about distribution — just put them on your internet server. And they’re really easy to update — just change the code on your own server, rather than having to go through this really complex update process. 

And they’re secure, with the same kind of security you’d use for transactions with Amazon or a bank. And they run securely on the iPhone, so that they don't compromise its reliability or security. 

And guess what? — There’s no SDK⁴ that you need! You’ve got everything you need — if you know how to write apps — using the most modern web standards, to write amazing apps for the iPhone today.

What Can PWAs Do Today?

PWAs can do most of the same things you expect from classic apps, for example:

• Install to the operating system's Home screen.

• Authenticate users using the device’s biometric capabilities.

• Use the device's camera and microphone.

• Detect the device’s location using GPS.

• Sense the device’s motion and orientation.

• Receive push notifications, even when the app is not active.

• Detect when the network is offline, and continue to function anyway.

• Create and access data files that persist between usage sessions.

• Make payments using pre-installed payment apps (Apple Pay / Google Pay).

• Share data with other apps, using the operating system’s Share Sheet.

• Establish real-time peer-to-peer communications (WebRTC).

These important features and enhancements are supported on Android but not (yet) on iOS:

• Enable a first class PWA installation experience from your website, including detecting whether your PWA is already installed and the ability to provide custom prompts to help the user install it.

• Register as a Share Target, i.e., appear on the Share Sheet as an app that can receive content that the user shares from other apps.

• Perform various operations in the background when the app is not even running.

• Register as a protocol handler — an app that can open specific types of links and file types.

• Home screen icon context menus.

• Interact with other devices via Bluetooth.

• Read and write to NFC tags.

• Prevent the screen from locking.

• Speech recognition.

You can find more details here:

• What PWA Can Do Today — install this web app on your device to discover and demonstrate your device’s supported capabilities.

• PWA Capabilities — a Google site for developers that thoroughly describes PWA capabilities.

The good news is that if you need one of the missing capabilities, there is a generally accepted workaround:

Deploying a PWA as a Hybrid App

If your mobile app needs a capability that is not yet implemented, you can easily create what is known as a hybrid app using a “wrapper” such as Capacitor. This creates a classic native app that encapsulates your web app, and also provides the missing functionality via available plugins. This approach will necessitate making your app available via Apple's app Store, and possibly Google's Play store, too.

On the desktop you have a variety of options such as Electron and Tauri.

App Stores are Cash Cows

Since launching the iPhone in 2007, Apple has strayed far from Steve Jobs's vision for standards-based apps. Apple could apparently not resist the lucrative temptation of creating a walled garden in iOS for which Apple itself serves as the gatekeeper. Android follows a similar model, ostensibly because Google would otherwise be leaving money on the table.

Thankfully, the web as a free and standards-based platform predates smartphones. Imagine a world in which Apple and Google decided which websites were “safe” to view on your mobile phone. The site owners would pay registration fees, and the content would be reviewed for compliance with the gatekeepers’ arbitrary policies. Any money changing hands would be automatically taxed by Apple or Google at 30%. You're almost there; Apple does exactly this with mobile apps. Google does this to a slightly lesser extent — Android allows you to permit installation of apps that don’t originate in Google’s Play Store, a method pejoratively termed “side-loading”.

Instead of expanding and deepening support for standards-based APIs, Apple and Google created platform-specific Software Development Kits (SDK) that allowed tight integration with each operating system. There are many benefits to this approach, but one of the trade-offs is reduced security and control. This conveniently necessitated that Apple and Google step in as gatekeepers in order to be able to evict bad actors — something they are notoriously bad at doing. The revenues they command are in return for their efforts to “create a safe environment”. 

Revenue Model

The Apple Developer Program generates hundreds of millions of dollars in annual membership fees of $99 or $299, paid by companies and individuals who host apps in the App Store (>2M apps). Google charges a one-time initial registration fee of $25.

In addition to this, Apple and Google charge up to 30% commission on sales of digital products and services. On iOS, apps must use Apple’s payment mechanism and are not allowed to link to an external website for processing payments. Google’s demands are not as strict, but they are in the same vein.

Out of $1.1 trillion billed by Apple App Store developers in 2022, $109 billion was from in-app advertising and $104 billion from digital goods and services. Apple therefore reaps tens of billions of dollars in annual income from the App Store. Google’s figures are smaller, but are still in the same order of magnitude.

Your Risks as a Vendor

When you use an app store as vendor, you assume significant additional risks to your app distribution operation. You are giving a third-party gatekeeper the power and authority to:

• Decide whether and when you can publish your app.

• Decide whether and when you can update your app.

• Remove your app from the store.

• Impose new rules or policies on your company and/or app.

In order to publish an app, you need to create a vendor account first. This involves submitting personal identification documents and company registration details⁵, as well as paying a fee.

After your account is approved, you need to request approval for your app. This can take a few weeks, even if there are no problems.

Subsequently, each update also needs to go through the approval process. Many hearts flutter during the waiting period because the different examiners don’t seem to interpret and apply the criteria in a consistent and predictable way, and there is no deadline.

Your app’s approval can also be summarily revoked at any time! The most sensitive time for this is when you request approval for an update, because this triggers a fresh examination of your app.

Additionally, at any time, the gatekeeper can introduce an arbitrary rule that you then have to race to comply with, with little recourse to challenge or appeal it.

In short, you do not control the timeline of releases or updates, and your app’s distribution is constantly at risk. Admittedly, the probability of experiencing a business disruption may be low, but its impact will be very high if disaster strikes.

Legal Challenges and Antitrust Regulation

By keeping PWA support alive after their 180 degree turn towards the App Store business model, Apple was able to say that their App Store is not a monopoly because there is an alternative way to install apps. This is probably why Apple has continued to maintain a passable level of support for PWA features, even if there are some glaringly obvious and plausibly deliberate gaps.

However, the success of this approach seems to be waning in the face of increased legal challenges from corporations and government regulators, who assert that Apple and Google use their app stores to exert illegal monopolistic control over the app market. 

Epic Games, makers of Fortnite, recently sued Apple and Google for operating illegal monopolies, in separate cases in the United States. Epic lost against Apple, but beat Google. In the mid-market, smaller companies such as 37signals, makers of Basecamp and the HEY Email and Calendar products, are periodically embroiled in David vs. Goliath skirmishes against Apple’s monopolistic gatekeeping, but only massive companies such as Epic can afford the legal fees to take this fight to the courts. At the lower end of the market are small companies that feel they have no option other than simply to submit to the gatekeepers’ heavy-handed directives.

Similar to Microsoft in the 1990s, Apple is increasingly falling afoul of antitrust regulators in the USA and Europe. Their strategy seems to be to drag things out for as long as possible, all the while raking in the revenue.

As if Steve Jobs’s sales pitch wasn’t enough, Apple recently signalled that it considers Progressive Web Apps a credible threat to their App Store revenue. In what appears to be malicious compliance with the European Union’s Digital Markets Act that forces gatekeepers to allow alternative app stores as well as alternative browser engines, Apple announced the removal, in the EU, of PWA support from the upcoming iOS 17.4 update. In response to uproar from the app development community, the EU’s European Commission requested clarifications from Apple prior to opening an investigation. This resulted in Apple promptly backing down from these plans.

In another saga, the US Department of Justice, along with 16 individual US states, has sued Apple for illegal monopolisation of smartphone markets, listing a whole slew of anticompetitive behaviours that “impose extraordinary costs on developers, businesses and consumers.”

This battle will take a few years to play out until the parties settle it or let the court decide. But the writing is on the wall: eventually, the anticompetitive behaviours will be stopped, either using current laws, or by enacting new ones, as is the case in Europe.

Conclusion

Whether to build a classic native app or a web-native app is not a purely technical decision — there are also significant business aspects to consider. Web-native apps are eminently viable, both functionally and technologically, as well as being a wise choice economically. 

The app store model imposes numerous risks on app companies’ distribution and revenues. App vendors should not follow the herd that accepts these risks as a given, but should instead apply rational judgement.

Apple’s and Google’s monopolistic behaviours confirm that Progressive Web Apps pose a credible threat to the app store ecosystem. The tide that is turning against gatekeeping monopolies ensures that Progressive Web Apps will be an increasingly viable alternative to classic native apps.

Progressive Web Apps deserve a bright future. They are based on a natural progression of the device- and vendor-independent protocols and standards that power the free web, such as HTTP, SSL, HTML, CSS, and Javascript. The level of support for Progressive Web Apps on the various platforms is allowing these platform-independent apps to become increasingly ubiquitous, if not the norm.

The best app store is the web!

1. The word “progressive” refers to progressive enhancement, which is an approach whereby web apps (and websites) automatically adjust their functionality to match differences in levels of support for various features and technologies across the different browser engines and devices.

2.  “Chrome” is a term that originates in automotive slang, and refers to showy features that don't contribute to performance. This generic usage of "chrome" pre-dates the Chrome browser by many years. See this discussion.

3. Web 2.0 and AJAX refer collectively to what today are standard web technologies and approaches that no longer need special buzzwords.

4. SDK = Software Development Kit

5. From experience, it can be excessively challenging to set up and validate an Apple Developer Program account in a multi-national situation where the company is registered in a different country from where its director resides and/or the person setting up the account.