The author is focusing on revenue generation opportunities.
Glenn Marcus

I have also been on (several) teams that were building the same app for both the web and mobile native deploys.

While I appreciate your detailed summary, it is an anecdote, and like all anecdotes, it is not evidence that you can apply the same experience generally.

Here’s one of my anecdotes about managing apps for 3 different platform targets:

App X

  1. We had both Android and iOS teams, but we still had to build the web version. Our URL was the best way to get traffic to our app, and supplying a web version meant users could jump in and experience the app right away, leading to much higher download and activation rates. Since 60% of web traffic comes from mobile, the web app still had to work on Android and iOS.
  2. Because of #1, all our development for Android and iOS was redundant work, and we did it only to provide a native app like experience with a home-screen icon, full-screen mode without URL chrome, and offline access. All of which the web platform now supports.
  3. We struggled to maintain feature parity between the development teams. There was always a team lagging behind on implementations, and our users complained when features existed on the web but not mobile or vise verse.
  4. Development cadence did not differ significantly when man hours were adjusted to the number of users we reached with each platform (something I kept track of for ROI metrics per platform). Between the web and mobile teams.
  5. What did happen frequently is that we’d ship a new feature for the web, but native app users had to wait for an average of two weeks before the mobile app updates became available.
  6. We had to support a lot of outdated mobile app installs, because they frequently didn’t upgrade to the latest version right away, which added costs to support legacy APIs just for straggling mobile users.
  7. We did have a smaller iOS team, but instead of working faster to keep up, the iOS version always shipped with smaller feature sets. It’s not that developing for iOS was faster, it was a lot less getting implemented for iOS — particularly in regards to the compatible screen sizes / layouts, etc… there was a very limited set of devices it had to (read: could) run on, and as such, a lot less work to make it work on all of them. It also reached the smallest audience segment by a good margin.

All told, the cost of supporting native Android and iOS devices was 2–3x the cost of supporting only the web app. It hurt development velocity because we had to maintain legacy APIs for outdated mobile app installs, and users hated it because features they depended on were never at 100% parity across versions.

All that before I mention that the web app had 3x the activation rate of the native apps, and most of our users discovered the app via shared web URL. Close to zero of our users discovered the app through the app store.

By far, separate apps for each platform was the worst experience of these anecdotes by every measure:

  • Cost
  • User experience
  • Development velocity

App Y

App Y was on paper a better candidate to chose a native app experience because we needed to access a variety of device APIs, but we wanted to use a single team. We built a web app and wrapped it up in a Cordova hybrid to give us access to the native APIs we needed. A single app could build and deploy to all of our targets easily.

  • Apple pushed back hard trying to prevent us from publishing the app to their app store. We pushed back harder and got it in by the skin of our teeth. (Word to the wise: this can be a real crap shoot).
  • Our mobile apps were a very thin layer that exposed device APIs.
  • We didn’t need dedicated mobile teams. The web devs used Android Studio and X Code to test and debug native device issues.
  • We built a much more complex app than App X and deployed to the same targets with a team less than half the size.
  • We had to resubmit to the app store very infrequently. Most of the updates shipped immediately via the web, instead.
  • Because we didn’t need to support legacy APIs for outdated mobile apps, our velocity was not hampered by legacy mobile install support.


  • Less cost vs native apps
  • Better user experience because of full feature parity across web and mobile apps
  • Better development velocity

App Z

Tiny team on a PWA.

  • One app team, works everywhere
  • No need for app store approval.
  • No trial friction. Just send a link, and users jump in. So far instant delight.
  • No need to even use X Code or Android Studio. All the dev & debugging happens with standard web tools, with great mobile debugging experience that allows us to step through code in Desktop chrome while the app is running on real mobile devices.
  • Got the MVP running smoothly on all 3 platforms in less than 2 weeks, with complete feature parity across all devices.

The PWA has the smallest development cost by a HUGE margin.


  • Lowest cost
  • Best user experience by a huge margin
  • Best development velocity

All that said, I found your anecdote very interesting to read. Thanks for your response. =)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.