Live data from Hacker News

PWAs wont replace native iOS apps

app.campsite.co

231–240 of 268 posts

Re: PWAs wont replace native iOS apps

#231
post #138

Earlier quoted context omitted.

Native libraries are already an huge abstraction. Anyone can write a GUI framework, even on iPhone. I don’t understand where the line is being drawn here

I am not the OP, but my line here is between the APIs provided by Apple and the third-party abstractions. As an iOS developer, the "lowest" you can get is the Apple framework. PWAs are a third-party abstraction on top of that, which come with all the risks/limitations of both third-party dependencies and abstractions.

I just don't really agree, almost all modern JS engines compile to machine code, so it's as "low" as writing Swift or Objective-C.

Re: PWAs wont replace native iOS apps

#232
post #166

Earlier quoted context omitted.

Native libraries are already an huge abstraction. Anyone can write a GUI framework, even on iPhone. I don’t understand where the line is being drawn here

Lets start with a browser based application that struggles with basic IOS capabilities. Not entirely a web app’s fault, but dealing with badges and push notifications will most certainly be a better experience in a native app. I admit that I am not saddened by this hurdle. The moment that becomes a thing, further enshitification will ensue with every web site trying to drop and icon and start pushing messages. “Close…

I agree that Apple make it so that unless you use their frameworks then you can't use certain functionalities of the OS, but that has nothing to do with being "lower" or "higher". It's just that Apple has a specific abstraction that you must use in order to access those features. It could just as easily be the other way around and have it so that only web apps can access those features and so-called "native" apps cannot. It just has nothing to do with the level of abstraction.

If you wrote pure machine code without system calls you can't even read a file. You have to call into the kernel, which could even be written in javascript, in order to do that.

Re: PWAs wont replace native iOS apps

#233
post #199

Earlier quoted context omitted.

Can I run an Android emulator on my musl-based system? Can I even run Android-Studio on OpenBSD? What about Plan9? Should I complain to Google because they don't support all the platforms under the sun? If I want to develop with Qualcomm boards, I need to sign all sorts of NDAs, and they don't even have emulators for development. Do you think that should be illegal? I wish we tried to honestly make the difference bet…

Asking Apple to properly support CSS is crying abuse? What comment did you read? Could you reply to mine , if you're replying to me? Specifically my reply in the context of the OP (is emulation necessary, when your web view of your OS just...does what it's supposed to?)

Safari supports CSS just fine, other than bleeding edge stuff where they lag a bit.

Re: PWAs wont replace native iOS apps

#234
post #215
post #131

Earlier quoted context omitted.

> I think developers need to clearly put blame on Apple for PWA not working. I think that developers need to choose technologies that work on the platform they want to support, instead of blaming the platform. It is totally valid for Apple to say "if you want to develop an iOS app, use the iOS native framework". > If the user bought the phone expecting web push to work then they can probably return it and buy an Andr…

The surfboard analogy is silly; it’s reasonable that the user expects the iPhone to be a general computing device (since it’s a powerful computer).

I exaggerated to make my point. It's absolutely not reasonable to expect to run on an iPhone. Otherwise I can extend it to anything. Would you say that "If the user bought the phone expecting to have root access then they can probably return it" is reasonable? If yes, just try to return your iPhone and see :-).

Re: PWAs wont replace native iOS apps

#235

Earlier quoted context omitted.

For quick access without cluttering browser tabs and bookmarks.

Why would you need quick access to one restaurant’s menu? If you go there infrequently, I don’t understand why you would clutter up any part of my phone - bookmarks or Home Screen - with its menu. If you go there frequently… you already know the menu?

Also if they have online menus or ordering they usually have a QR code on the table or nearby. No need to bookmark or save anywhere.

Re: PWAs wont replace native iOS apps

#236
post #138

Earlier quoted context omitted.

I am not the OP, but my line here is between the APIs provided by Apple and the third-party abstractions. As an iOS developer, the "lowest" you can get is the Apple framework. PWAs are a third-party abstraction on top of that, which come with all the risks/limitations of both third-party dependencies and abstractions.

I just don't really agree, almost all modern JS engines compile to machine code, so it's as "low" as writing Swift or Objective-C.

I think you're not talking about the same thing. What I am saying is that if you depend only on Apple and their framework, then you have all the improvements as soon as they exist and you don't really have the risk that Apple stops developing iOS (or if they do, then iOS is most likely dead).

If you depend on, say, Qt-for-iOS, then you need Qt to integrate the new features (with more or less success, taking more or less time), and you have a much higher chance that Qt will stop working on iOS some day (or that some important feature never reaches Qt, or that it is super painful to use with iOS).

Removing third party dependencies reduces your risk.

Re: PWAs wont replace native iOS apps

#237
post #25

PWAs will never be as good as native, definitionally. There is always API drift. There is always runtime cost. Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself. People's experience with hardware and physical objects matters. If you accept that, you should always want to be closer to the metal at the cost of convenience or portability.

PWAs can absolutely be as good as native, however they aren't being given a chance due to reasons unrelated to technology. I personally believe it is the protection of Apple's fees that is driving its poor implementation of web technologies (even though their original plan was to only have web apps, with a small number of native apps for very specific things). The money they could extract from the app store made them change their tune re web apps, and they've managed to convince every Apple fan it's for their benefit. Unfortunately, this goes unchallenged by the average Apple user, who lacks the tech knowledge or desire to question Apple.

Re: PWAs wont replace native iOS apps

#238

Earlier quoted context omitted.

Looks like Apple is just going to blame the EU. They are officially pulling PWA support on iOS in Europe. So fuck me I guess :( https://9to5mac.com/2024/02/15/ios-17-4-web-apps-european-un...

You seem to be conflating "PWA" with the Safari + Home Screen integration that allowed users to add a web[site|app] (PWA or not) to the iOS Home Screen. Apple had to remove this to comply with the DMA. It's now the responsibility of alternative browser engine vendors to integrate with Shortcuts so that you can add PWAs and other web[sites|apps] to the Home Screen using your browser engine of choice. The additional be…

Using shortcuts might be a solution in the future. Would be much better if Apple updated their PWA support so that users could select a browser engine instead.

Re: PWAs wont replace native iOS apps

#239
post #216
post #122

Earlier quoted context omitted.

I think it is debatable. Can I make an iOS app in pure Python, and should Apple make it possible? I think Apple has the right to decide what kind of API they provide to their users. Just like nobody is forcing Tesla to allow running Windows "because some developers would like to run Windows apps in their Tesla". I can see a problem with the monopoly on the App Store given the dominant position of Apple. But if Apple…

Why do they have a right to decide what kind of API users can use? I know that's not exactly how you worded it, but on other computing platforms like Windows, Microsoft provides APIs but doesn't prevent developers putting in other APIs. You should be able to write an iOS app in pure Python, but maybe with reliance that someone else provides the bindings so that you can display the graphics. iOS and Android locking ou…

> Why do they have a right to decide what kind of API users can use?

Because they make a product that they sell. If you make a speaker, you can decide if it has Bluetooth, WiFi or nothing. If you want a speaker that has Bluetooth, you need to buy a speaker that has Bluetooth. Not buy one that doesn't and go ask the EU to force the manufacturer to add Bluetooth.

> iOS and Android locking out whole possible ecosystems with "only we can decide what code is allowed to run" really sucks.

That's a perfectly valid opinion. Others will say that not having root access and having a checked App Store increases the security (and that is true). You can try a Linux phone, if you want freedom.

Re: PWAs wont replace native iOS apps

#240

Earlier quoted context omitted.

The DMA requires that Apple not favor Safari. A direct integration between Safari and Home Screen favors Safari, and so is not allowed under the DMA.

So...they're tearing out all OS features that favor Safari? or just the features they're motivated not to offer a path to using for other publishers? (Like, webapp support)

From Apples own documentation I get the feeling that someone discovered that there was no easy way to allow their PWA support to work with other browser engines. Due to a lack of priority, running out of time and general malicious compliance they just nuked PWAs instead of fixing them.

I wonder if the DMA contains some sort of requirement that features not be removed. To force Apple to make PWAs interoperable with other browser engines instead of just nuking them.

Post reply on HN