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.
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.
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.
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.
