4 ms·

> The whole reason they are low usage on PWAs is because of a lack of investment from Apple and a lack of parity This is a trite argument that hasn’t been true

• jchw 3y ago
  That's kind of the point, PWAs don't have parity on any platform, but Apple's platforms are the only ones where it is being positioned as a legitimate alternative; Android has "sideloading", Windows has REGULAR loading. It doesn't matter who joined Apple when and did what, PWAs on iPhone are not like native apps, it's not even really close. It's good that this pathetic line of argument wasn't much of a deterrence for the EU. What people want isn't PWAs, they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it.
  • turquoisevar 3y ago
    > That's kind of the point, PWAs don't have parity on any platform That’s not true, nor what I posited. PWAs have almost all the native features, if not all, depending on the platform. Plenty of “pro-PWA” people go out of their way to demonstrate this[0]. I’m talking about install rates and usage by end users in a way similar to using a native app. Whether you agree on parity or not, you seem to concede that PWAs aren’t wildly adopted the way native apps are. As such, it makes sense that Apple wouldn’t want to waste engineering resources on it by rewriting the underlying architecture, which is the topic at hand. That in and of itself ends the debate. You then go on, OT, about whether Apple should or shouldn’t position websites and PWAs as legitimate alternatives. Saying: > but Apple's platforms are the only ones where it is being positioned as a legitimate alternative Specifically, Apple states[1]: > If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too. An alternative isn’t, as you seem to imply, an identical option; instead, it is simply understood to mean a different choice, usually a choice different from what is usual. One might say, "In the absence of a better alternative, we’ll have to proceed with our original plan.” This use in and of itself implies that one option is better than another, thus not identical. Whether something is “legitimate” or, more specifically, a “legitimate alternative” entirely depends on the person making the consideration and the value judgment they make based on their needs and wants. I might consider soda a “legitimate alternative” to coffee because I’m just looking for a beverage, whereas a different person might not deem it a legitimate alternative. After all, they are solely interested in a warm beverage. With that in mind, I consider web pages, particularly PWAs, a legitimate alternative to native apps because most native functions are available to PWAs on iOS. You might not because your need might be one of the few things PWAs can’t provide. That doesn’t make it a bad-faith argument on Apple’s part; they never claimed that PWAs are an identical option to native apps via their App Store. They offered up an alternative that can provide some, if not most, of what a native app can provide. You continue with your OT by presenting a false equivalence > Android has "sideloading", Windows has REGULAR loading. It’s a false equivalence because neither Google nor OEMs present sideloading as a legitimate alternative; it simply exists, but it’s not promoted as an alternative option. Google specifically likes to write copious amounts of words in blog posts[1] and whatnot, talking about how great PWAs are while wearing their Chrome hat. Meanwhile, the PWA experience on Android is marginally better than that on iOS, provided you use Google’s browser. Where is your indignation for that? They’re promoting PWAs harder than Apple will ever do. For that matter, Microsoft also doesn’t call “regular loading” a legitimate alternative, so again, your equivalence makes no sense. > It doesn't matter who joined Apple when and did what Of course it does; if you don’t go OT, that is. Whether Safari is or isn’t suitable for PWAs is essential to assess if PWAs are used in meaningful quantities. If someone posits that Safari doesn’t properly support PWAs when that isn’t true, like GP did, then it’s important to point that out and provide context on when that changed. It doesn’t matter to you because you’re having an entirely separate discussion. > PWAs on iPhone are not like native apps Yes, they are. As stated above, they’re not identical, but they are similar to, or if you prefer, “like” native apps. > it's not even really close This is a value judgment because it requires that you and I agree on the definition of “close.” I argue that they’re pretty close because they can do about 90% of what native apps can do. > It's good that this pathetic line of argument wasn't much of a deterrence for the EU. Let’s keep it classy and within HN guidelines. > What people want isn't PWAs Hence, the low install rate of PWAs and why it’s not weird that Apple didn’t decide to spend engineering resources on rewriting the underlying architecture for PWA installs. Again, that, in and of itself, ends the debate. > they just want the kind of capabilities that computers have had for decades, including many of Apple's current computers for sale today. To be able to install an application and run it. I’m not sure what you base this on. From here, it looks like you’re projecting your own wants onto the average iPhone user base at large. Do you have anything that expands on how many iPhone users share your vision? The commercial success of iPhones suggests that not many seem to care for this. I suppose alternatively, you could argue that the fact that Android dominates globally indicates there is a demand for this in the smartphone market[2]. Still, the obvious question then becomes why those iPhone users wouldn’t just join in Android’s dominance and switch over, particularly those who feel so strongly about this that they’d spend their time online lamenting its absence. 0: https://whatpwacando.today https://whatpwacando.today 1: https://developer.apple.com/app-store/review/guidelines/#introduction https://developer.apple.com/app-store/review/guidelines/#int... 2: This is simplified, of course; one feature wouldn’t be the sole driver of Android’s dominance
    • jchw 3y ago
      I'm not going to go point by point on this one, but I do have some remarks. I am not "projecting", I own multiple Apple devices, therefore, I am very well within my right to talk about what I want as an owner of Apple hardware and on behalf of likeminded users, even if people on Hacker News don't like that fact as is evident from time to time. Wanting "sideloading" aka regular loading is not wildly off topic, it's literally MORE on topic than PWA vs native app parity, which is really not relevant to the EU DMA compliance issues at hand. And on that note, of course PWAs do not have parity with native applications. They're quite a lot slower, for starters. Is anyone shocked? No... it's not weird that it is much slower when you are going through Webkit instead of native APIs like Metal, in WebAssembly and JavaScript instead of C and Swift. That's disregarding the fact that both policy-wise and in what APIs are available, clearly PWAs have significantly more limited access to integrate with their host platforms, which again, is hardly surprising for glorified bookmarks.
• szasamasa 3y ago
  web apps are websites with standalone the name "install" is bad and the wording is NOT a web standard, NOTHING is installed the question is web capabilities one core capability is caching and offline via service workers no need for "install" for this "installing" a web app does not even need anything anymore, not even offline or service workers... it is ONLY switch to standalone and get a launch button or be integrated into app launchers on OS behind "install" is a bad and immature web app manifest api, it is a draft... the wording install must go it is one of MANY possible web capabilities for a web domain to be able run standalone and get a button apple cannot ban this since a shortcut to chrome cannot be deemed unsafe, where then CHROME decides to run standalone or not the real problem is NOT that safari kills standalone they try to kill a lot of web capability, like service workers, and NOT JUST FOR SAFARI I mean this will not stand, you CAN stay apple-level-safe (whether it is more or less than other platforms) by CHOOSING safari it is an obvious CHOICE to be granted to trust google, mozilla or microsoft and their web security model to stay safe with THEM on the web no argument why this should not be allowed if other native apps are allowed and come on, even mac os is safe with service workers in chromium