[bowsamic]

> Nothing inside a system can ever have parity with its parent container. If it could, it would be the system itself.

I have no idea what you mean by this, can you give some justification? It sounds kind of nonsensical

> you should always want to be closer to the metal at the cost of convenience or portability.

Right but that isn't really a thing anymore. Even machine code is very abstract compared to the actual physical processes going on inside. Bare metal programming is an illusion for pipelined CPUs with speculative execution

[palata]

> Right but that isn't really a thing anymore.

"Wanting to be closer" does not mean "needing to be at the lowest theoretical level". In this case it just means that native mobile frameworks are one layer of abstraction lower than web frameworks, and it is better (not cheaper, not easier, but better).

[bowsamic]

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

[palata]

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.

[bowsamic]

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.

[Klonoar]

The JIT aspect is merely one component of the larger picture. With PWA’s specifically you have the entire browser stack to move around. Native code simply does not have this constraint.

They are (IMO) correct that having less layers between you and the lowest layer is ideal. The browser is an engineering marvel but it’s still a nuisance to work around.

[palata]

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.

[bowsamic]

Sure but the person I originally implied to was not talking about capabilities alone, they were saying how being closer to the metal is strictly better, but there is no inherent link between being closer to the metal and capabilities. It's a mistake to connect the two.

[kmbfjr]

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.

“Closer to metal”? Not sure you are wrong to ask if there is a line given SwiftUI. That is some very high abstraction.

[bowsamic]

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.