Hacker News Reader

Comment by anonymouse008 | Hacker News Reader

I'm wondering if webapps are achieving parity with native apps. My intuition says that most of the use cases today could transfer over if they really wanted to.

Does anyone have any insight into the major differences between native and web app in 2021?

The biggest disparity between webapp and native used to be Notifications - but with Twilio, it appears trivial to make an arguably better notifications user flow through SMS and direct link to user content.

For the rest of the differences, it feels like much of the benefit Apple brings to the table (view management, security, continuity between devices, distribution, ...), does appear to carry a premium when placed in comparison to building a monolith web app.

View on HN

Not on iOS. The biggest issue are indeed native notifications which I don’t believe will ever happen (unless Apple is forced to by legislation). Web Bluetooth is also unlikely to happen. Storage is another issue that is heavily restricted on iOS and in my experience offline use is completely unreliable.

> The biggest disparity between webapp and native used to be Notifications - but with Twilio, it appears trivial to make an arguably better notifications user flow through SMS and direct link to user content.

Oh god please no.

I can turn off app-level notifications. I don't want to have to deal with app-level texts instead.

> I can turn off app-level notifications. I don't want to have to deal with app-level texts instead.

Ha!! See, I think SMS notifications are still stellar! Because right when the offender steps in, in the height of righteous anger, you can yell (text) "STOP" and by law it must bug off!!

Not to mention the cool new commands that could emerge like, "give me a week" or other conversational ways to interact with your notifications on a person level... which to me, is what it was all about in the first place!

> you can yell (text) "STOP" and by law it must bug off!!

Is that the law everywhere in the world?

> Not to mention the cool new (…) conversational ways to interact with your notifications

Which you could achieve by allowing replies from within the notification itself, like Messages on macOS.

And SMSs cost money. It doesn’t matter how cool your conversational interactions are, no one would be happy being charged for international text messages to respond to a bot, especially when the norm today is automated assistants barely understand what you mean.

In practice, the lion share of revenue on the App Store is made by games.

Running games as web apps is technically possible, but performance tend to be an issue, even for simple 2D games.

I don't think Apple is embracing Webassembly enough to facilitate this transition, this is not their best interest.

TikTok, Starbucks, and Lyft all have fully capable webapps. If you have an Android phone, you can "install" them directly from their websites to have a completely equivalent UX to a native app. This is super interesting when you consider the primary argument in the article (that most download funnels are driven by the app developer, not Apple).

I've yet to encounter a webapp whose UX made me as happy as native apps do. The platform simply doesn't offer enough affordances for it.

Write once, run everywhere has a cost, and one that is largely borne by users.

For my personal use cases (visible or invisible) push messages are the major missing feature for replacing native with web apps. And I doubt it’s possible to do without platform support.

Twilio or other SMS based services aren’t a solution as in lots of countries they still cost $0.10 per 160 characters, require an active SIM card and cannot be opened into an app.

Maybe something can be done with websockets but that will also require platform support to improve battery life and allow web apps to run in the background.

> Does anyone have any insight into the major differences between native and web app in 2021?

No general insight, but Telegram has two web apps that try to emulate the native app [1]. They do work fairly well but are definitely glitchier than the native app (or any native chat app).

> For the rest of the differences, it feels like much of the benefit Apple brings to the table (view management, security, continuity between devices, distribution, ...), does appear to carry a premium when placed in comparison to building a monolith web app.

That might be true, but the value free apps like WhatsApp bring to the iPhone is unmeasurable and WhatsApp pays exactly 100$ a year to Apple for access to all the tooling.

[1]: https://telegram.org/blog/payments-2-0-scheduled-voice-chats...

No choice in graphics API and no general purpose compute on the GPU. WebGL is a start but it's missing major features.

If you want to build a competitive game engine or do any sort of machine learning on device then it has to be native.

This is why I'm optimistic about WebAssembly, beyond time and investment, what prohibits it from achieve performance parity with native?

Apple support?

There's no JIT for WebAssembly on iOS (at least last time I looked last year), so it's going to be much slower than it could otherwise be.

Are you sure about that? Why wouldn't WebAssembly in Safari support JIT?

Politics.

This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack.

https://adobe-flash.github.io/crossbridge/

"Unreal Engine 3 Support for Adobe Flash Player - Unreal Tournament 3"

https://www.youtube.com/watch?v=UQiUP2Hd60Y

Here we are 10 years later with WebAssembly still mostly stuck at MVP 1.0, browsers that bork WebGL experience thanks blacklisting, which no matter what will never go beyond OpenGL ES 3.0.

Even if WebGPU gets released tomorrow, I would like to point out that WebGL 2.0 was released in 2017 and still isn't available across all browsers.

Then there are all other native capabilities that I glanced over.

> This is what Flash was already capable of doing in 2011 with CrossBridge, their C++ compiler stack.

Then why was the Android Flash experience so bad that it got quickly killed off?

There was a time where Adobe could have shown a performant, stable version of mobile Flash, and Apple would have had to find a way to accept it. But it never got there, on any mobile OS.

Politics.

While everyone was celebrating iOS victory over Flash, they were playing Flash games on iOS, AOT compiled to native code without knowing it.

Adobe eventually let it go thanks to the competition of Cocos, Unreal and Unity.

> This is why I'm optimistic about WebAssembly, beyond time and investment, what prohibits it from achieve performance parity with native?

It's cross-platform VM-enabled bytecode? Approaching native performance very closely is the best plausible outcome. Measured on all metrics and not just pure number-crunching (start-up time generally, "cold" start-up, memory use, memory use over time, et c., all in real-world applications and not bespoke benchmarking programs) it's unlikely it'll even get very close. Close enough? Maybe, but I'm skeptical that there is such a (realistic) achievable state as "close enough" on a platform that runs on a small battery. Look at Android's decades of playing catch-up on performance & power use, for instance.

[EDIT] Down-voters, please comment: do first-year CS principles and direct observation of existing, long-lived, real-world cross-platform VM systems (the JVM, for example) somehow not apply to WebAssembly?

> what prohibits it from achieve performance parity with native?

On what axes are you measuring performance? I care about how quickly and smoothly something runs, but also how much battery, memory, and bandwidth it consumes.

I'd like to hear the thoughts on this of people who are arguing with me in another thread that "Apple planned for web apps to be the only apps for the iPhone until they just happened to come up with the idea for the store full of native apps".

Honestly, if you believe that Apple ever planned for iPhone to be web only you've got to buy this bridge from me. No kidding.

Apple used the "web only apps" angle as a stopgap until their SDK was ready. Then they did everything they could to ensure that web apps ran like crap without making it too obvious.

Sure thing.

Apple told developers that webapps were the solution. They didn’t give any public indication that this would change. Now, one could argue that this was just cover while they got the native SDK ready, but that Bertrand Serlet email from the other thread was the point at which they even officially decided to have a native SDK at all (months after telling devs to write webapps).

I think the real issue is with the phrase “Apple planned”, because Apple is not one person, and the people disagree on “the plan”. We mythologize them sometimes as an all-planning “the Vatican thinks in centuries” kind of organization. But as emails like that one and others show, there are often legitimate arguments within Apple. In this case, some folks[0]were arguing that native apps would be too much of a security nightmare to be worth it, and that anything that needed to be native could just be built by Apple themselves.

So in conclusion: “Apple” planned nothing, some people at Apple had clear plans to push through a native SDK from day zero, and some people at Apple spent months being deadset that that would never happen.

[0] I’m too lazy to look up these sources right now, check out Melton and Ganatra’s multi-part interview on the Debug podcast.

Nobody, especially not Apple, decides something like that in one email or even a single conversation. Also this is the company that goes to great pains to hide what everybody can see about their plans. Keep that in mind.

Obviously, This is something that has been discussed over and over and over since they started planning the iPhone. I've watched Apple work, they don't hash out what their products are going to do through emails.

Sorry, but you're wrong. The idea had clearly occurred to them way before any of these emails that you're referencing.

The point is not that the email came up with the idea and they decided it on the spot. But the email show that there was an open discussion, there was a point where they weren't sure.

It really seems that was the original plan. An email from the Apple vs Epic trial where Steve Jobs gives the go ahead for the app store in October 2007. They had to rush to get the sdk done in three months.

https://twitter.com/TechEmails/status/1400270458608664577

No it doesn't. Not even a little bit.

That's a go ahead email. That's not an email showing the conception of the idea.

We already had app stores on phones before this. You think they didn't come up with the idea until that email? It's perhaps the most obvious idea in the world.

Sorry, y'all are just wrong. This email is evidence that its all been discussed many times before the "go ahead".

The iPod never had an app store, an Apple are known to prefer to be in control of the experience. How can you be so sure they were planning an app store all along?

Reply on news.ycombinator.com