What example of PWA that works on IOS and has traction/loved by users, and isn't basically a website pretending to be an app?

Reply to this note

Please Login to reply.

Discussion

Who cares if it's a website pretending to be an app? We're talking about circumventing a 30% taxed walled garden.

Try Android?

Rough going with an Android-only strategy in the US or Japan.

In French "ruelle" is a little street, like a laneway.

French Canadian origin here. Family left Quebec to find gold in the West, lost the French. 34°S, sounds like a rugby latitude, a wine latitude, or both.

I'm all for PWAs, building one myself.

But as a business you can't be both profit motivated opt for a PWA when it could be a native app w in-app purchase. Even if all your users are coming to you organically, profit wise you will sacrifice far more than the 30% you save. And for users that are not coming organically, it's orders of magnitude.

So "profit-focussed and PWA-first" is somewhat of an oxymoron on iOS.

I'm not talking about trying to make money from users of an app. That's part of the problem.

What would the business model be then?

Provide an actual valuable service to your customers rather than extract bullshit rents inside a walled garden (while also helping make the walls of the garden taller).

Then give them a free open source UI that helps them use that service. Preferably as a PWA

I'm all for that. The issue is that for many app businesses of a certain scale if they go the PWA-only route versus the native route (assuming both routes are viable) they will lose money. Not make less money, but lose money. Can't pay the team, downsize, shut down. (Whereas going the Native-only/App Store compliant route they'd scrape a little profit, something to invest back in the team and keep going.)

If they do both, they will also lose money. (Starbucks can do both.)

The vast majority of app businesses operate at a scale where PWA-only means making a loss.

So the options for these teams are: go native-only, get grant funding (opensats or whatnot), or give up on the idea and do something else.

If they can't afford to do what I'm describing their teams are too large or they're using an inefficient tech stack or both. (Or they're providing a service that isn't valuable enough to consumers). Either way, I would personally prefer they go out of business than become another "zombie business" that survives purely off the little table scraps of the various megacorp walled gardens and further entrenching that model.

I think that's a fair argument, but on the basis of ethics or principles.

Not on the basis of team size or tech stack, as many of these teams don't have anything to point fingers at there.

On the tech stack side it could be their design is simply optimised for native APIs. PWAs can’t fully plug into the accelerometer, gyroscope, ambient light sensor, bluetooth, USB on and on. Geolocation on a PWA can be of by many meters more than on a native app. And so on. There are a lot of things you can only do on a native app—or you can do a very watered down version on a PWA that people at best don't find nice—and at worse hate.

These are make or break things when it comes to the business side.

Or it could be down not to native APIs but rather deep-link integration with other native apps, or just certain market dynamics when it comes to attracting foot traffic and so on.

Basically there are many reasons to have empathy for teams that would love to go all in on PWAs but don't.

You're completely right, I'm making an argument from principles. Good point. What I'm saying boils down to: if your business model cannot be supported by open protocols, then you _ought_ not pursue that model, because otherwise you contribute to the downfall of many other things you may cherish.

(The latter point there makes it slightly more tactical than purely principled, but I'm also making some hidden empirical claims there, which is not too fair).

We all have places we won't go, business-model-wise. "I wish people would buy my photographs!" (Well they would if they were pornographic, but you have a red line there) "I wish people would pay to visit my blog!" (Well they would if you had ads, but again red line) "I wish people would use my PWA!" (Well they would if you had native deep-linking)

I admit my red line being on [this side] of open protocols is extreme, and alienates most legacy / fiat business models and software development practices... But I say: Fix the protocols, fix the world. And it's a hill I'm willing to defend and die on, economically.

People forget that web apps and mobile apps are just UIs to actual services. **Access** to the UI shouldn't be the product. That's an insane fiat mindset that we've allowed to keep in and it only benefits the gatekeepers

Typical pattern is PWA first, then add native as your userbase and commercials allow the added overhead. Historical examples include Tinder, Uber, Pinterest, Flipcard, Amazon, Starbucks and many more. You can find more examples here:

https://laffaz.com/progressive-web-app-history-examples/

Now it's gotta be said as well that Mobile Safari has become what Internet Explorer used to be; the lowest common denominator that makes it VERY hard to make PWAs almost as polished as native apps.

On purpose. Browsers are just awful for almost all things, on purpose.

And I suspect that building a native app can be done easier and faster than a web app, if they target sideloading instead of app stores approval process.

But I need to build few apps to make that argument with confidence.

Side loading is dead on arrival if we're talking about trying to make normie adoption more palatable.

Unless you want to build a very niche mobile app, you typically need a presence on the web, on ios and on android. If possible, build a PWA to validate your concept (and distribution/network effects). Then iterate and build your native apps when you are sure you have a product market fit. There are many reasons to love native stuff, sure. But being a platform "purist" seldom makes sense business wise.