Most app development technologies force teams to make hard decisions about where they will distribute their apps, usually either app stores as a native app or the web as a Progressive Web App.

Building a native Swift (iOS) or Kotlin (Android) app, for example, obviously limits teams to just those respective platforms. But others have more subtle restrictions. Xamarin enables you to build for iOS, Android, and Desktop, but not for the web, meaning no access to a major chunk of mobile traffic and app-consuming users. React Native’s View elements can be abstracted to have the same API on the web but you will need to write completely separate view code for it, avoid using certain standard web features, and use different calls for certain APIs, so it’s an additional investment. Flutter can be used to build iOS, Android, and Web apps, but its web support requires multiple MBs of code for users so it’s not appropriate for high-performance Progressive Web Apps and speed-sensitive web sites like those that depend on search engine rankings and SEO.

Capacitor, a universal app runtime, avoids these tradeoffs by targeting one universal runtime (the web), and giving you maximum optionality for where you distribute the app that you build. You can deploy your app with one codebase anywhere your users are, even if that happens to change! That might mean the app stores today, but it could mean the web and desktop tomorrow.

What Optionality Looks Like

I was recently helping a team think through an app project they were going to deploy to the app stores on iOS and Android. They were using Capacitor with React, using a home-grown UI based on Tailwind.

During development, the team decided that they wanted to have a strong web portion to their app in order to easily acquire users, benefit from instant access and SEO on the web, and avoid app install bounce risk (meaning, the user leaves without ever installing the app, which is very common in the mobile world!)

Since their app was built with Capacitor, utilizing Capacitor’s cross-platform APIs, they could simply deploy the same app with the same code as a Progressive Web App hosted on a platform like Vercel or Netlify.

And this decision didn’t preclude them from also shipping a native iOS and Android app. They decided that they would unlock some additional features that depended on native functionality missing from the browser environment for users that were “activated” and likely to stick around.

Doing so in Capacitor was straightforward because Capacitor APIs are identical on iOS, Android, and the Web, and Capacitor comes with a number of utilities for adding conditional platform-specific code if desired.

Why this Matters

For new projects, the greatest risk isn’t technical but rather that no one uses your app and it never gains meaningful traction or scale. One of the best ways to avoid that is to reach the broadest possible segment of your target audience on day one.

For most companies, their audience isn’t on a single platform, form factor, or environment (such as mobile or web). This is especially true for consumer and enterprise consumer companies. In fact, there’s a good chance a majority of users aren’t even on a platform that you, the developer, actually use primarily (such as Android if you’re an iPhone user or web apps if you’re in the US and used to installed native apps).

Having optionality might mean the difference between your app project failing or succeeding, and nothing could matter more than that.

How does this compare to Progressive Web Apps?

One of the things to think about when building a Progressive Web App not with Capacitor, is that it will constrain your app to running only in a traditional browser context. This means it will only be accessible on the web and not have the option to access native APIs that don't have a browser analog since it cannot be distributed in popular mobile app stores.

Thus, the decision to build a Progressive Web App can also be limiting. But in this case a very straightforward way to add native iOS and Android support is by installing Capacitor into your Progressive Web App.

Capacitor has full Progressive Web App support and apps use the same Capacitor API calls regardless of the platform they are running on. This makes it easy to bring it to iOS and Android with the same code.

In that sense, Capacitor is "web app virtualization layer" that enables standard web apps to run anywhere with the same APIs, regardless of the "host" platform underneath.

Who's using Capacitor today?

Capacitor is growing quickly (100% YoY) and is installed over 500k times per month. Teams at companies like Burger King, Tim Hortons, Workgrid (Liberty Mutual), and Fidelity, to name a few, are all using Capacitor to enable their web teams to deploy iOS, Android, and Web apps with the same code.

Capacitor was also rated #1 in satisfaction among mobile development tools on the latest State of JS survey.

Capacitor was created by the team behind the popular Ionic Framework as a replacement for Cordova for deploying modern Web Native apps on iOS, Android, Desktop, and Web.

Get started

Getting started with Capacitor and building full distribution optionality into your mobile-enabled web app is as easy as installing the Capacitor library and running a few commands.

Get started with Capacitor today and follow us for more resources and updates on the project!