4 ms·

I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. For years they've real

by cronix 4y ago

I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. For years they've really been holding up progress with PWA. I think a majority of the apps we see are really just glorified wrappers around websites anyway, or not needing more resources/tech than a website would, except bloated up to 100megs for each app because we can't just use the web browser already installed and all of the time and money wasted getting it into the app store when it should be just freely accessible via the web.

sublinear 4y ago
> should be just freely accessible via the web Yes this is a significant hammer blow against native apps on iOS, but I don't think this would reduce cost for the consumer. I might be misunderstanding what you mean by "freely accessible" though. Definitely is more convenient for the same web app to be available everywhere.
- nine_k 4y ago
  Freely accessible as in not vetted by Apple. No approval process, no need to pay $100/year, no need to buy a Mac. (Also, gone would be the 30% Apple tax on "in-app" payments.)
  - geysersam 4y ago
    No need to maintain multiple versions of applications for different platforms.
    - deleted 4y ago
      [deleted]
  - ffritz 4y ago
    Let’s see if they still do want your $100 by requiring it for their Push Notifications API.
    - yamtaddle 4y ago
      You'll need an app-specific cryptographic key to connect to the push service, unless that's changed. And you'll need some system for registering and de-registering push tokens (unless that's also changed).
- dmitriid 4y ago
  > Yes this is a significant hammer blow against native apps on iOS Funny how this significant blow never happened on the world's most dominant OS where all the restrictions that HN loves to whine about don't exist.
cma 4y ago
Meta's PWA announcement was pretty shocking: they are going to take a 30% cut from PWAs and require they go through their Quest store.
WastingMyTime89 4y ago
> I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. The EU is forcing them to allow side loading so they are racing against the clock to try to bring WebKit to a point where everyone is not just going to switch to Chrome overnight when that happens.
- fabrice_d 4y ago
  In general yes, but web push is kind of the exception there because this API needs OS level support to wake up apps. Switching to a blink based browser would not help with that.
  - yoavm 4y ago
    Why not? If you run Chrome (or Firefox) on iOS, can't the app ask for notification access using the normal OS API? It will then "lend" this functionality to websites, so that when they have an update you'll get a notification from Chrome saying "Website X: Hello world".
    - yamtaddle 4y ago
      That'd require a whole other push system operating on top of the normal iOS push system. Web app users would have to go through some Google-hosted push clearinghouse that wrapped some new format within the existing Apple push protocol, and it'd only work for Chrome. [EDIT] Web app developers, that is—users of the push system. And it means when end users have 20 sites sending them pushes that they don't want, they'd have to figure out how to disable them in Chrome's settings, rather than their normal system push settings. It'd be a total mess.
      - yoavm 4y ago
        Isn't this literally how it's done with every browser on earth? I'm using Linux. Websites don't use DBus and notify-send, they use native Web APIs to talk with the browser. The browser then uses the OS notifications API to translate them, and yes, it manages all the subscriptions too.
jonny_eh 4y ago
> because we can't just use the web browser already installed True on Mac, not on iOS. Apple doesn't let you ship custom web renderers. You need to use the system's built-in one. This applies to browsers such as Chrome and Firefox too!
- throw03172019 4y ago
  I believe they are goi g to allow custom engines going forward. Source: https://www.macrumors.com/2023/02/07/mozilla-developing-non-webkit-version-of-firefox/ https://www.macrumors.com/2023/02/07/mozilla-developing-non-...
deleted 4y ago
[deleted]

by cronix 4y ago

sublinear 4y ago

> should be just freely accessible via the web Yes this is a significant hammer blow against native apps on iOS, but I don't think this would reduce cost for the consumer. I might be misunderstanding what you mean by "freely accessible" though. Definitely is more convenient for the same web app to be available everywhere.

nine_k 4y ago
Freely accessible as in not vetted by Apple. No approval process, no need to pay $100/year, no need to buy a Mac. (Also, gone would be the 30% Apple tax on "in-app" payments.)
- geysersam 4y ago
  No need to maintain multiple versions of applications for different platforms.
  - deleted 4y ago
    [deleted]
- ffritz 4y ago
  Let’s see if they still do want your $100 by requiring it for their Push Notifications API.
  - yamtaddle 4y ago
    You'll need an app-specific cryptographic key to connect to the push service, unless that's changed. And you'll need some system for registering and de-registering push tokens (unless that's also changed).
dmitriid 4y ago
> Yes this is a significant hammer blow against native apps on iOS Funny how this significant blow never happened on the world's most dominant OS where all the restrictions that HN loves to whine about don't exist.

cma 4y ago

Meta's PWA announcement was pretty shocking: they are going to take a 30% cut from PWAs and require they go through their Quest store.

WastingMyTime89 4y ago

> I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. The EU is forcing them to allow side loading so they are racing against the clock to try to bring WebKit to a point where everyone is not just going to switch to Chrome overnight when that happens.

fabrice_d 4y ago
In general yes, but web push is kind of the exception there because this API needs OS level support to wake up apps. Switching to a blink based browser would not help with that.
- yoavm 4y ago
  Why not? If you run Chrome (or Firefox) on iOS, can't the app ask for notification access using the normal OS API? It will then "lend" this functionality to websites, so that when they have an update you'll get a notification from Chrome saying "Website X: Hello world".
  - yamtaddle 4y ago
    That'd require a whole other push system operating on top of the normal iOS push system. Web app users would have to go through some Google-hosted push clearinghouse that wrapped some new format within the existing Apple push protocol, and it'd only work for Chrome. [EDIT] Web app developers, that is—users of the push system. And it means when end users have 20 sites sending them pushes that they don't want, they'd have to figure out how to disable them in Chrome's settings, rather than their normal system push settings. It'd be a total mess.
    - yoavm 4y ago
      Isn't this literally how it's done with every browser on earth? I'm using Linux. Websites don't use DBus and notify-send, they use native Web APIs to talk with the browser. The browser then uses the OS notifications API to translate them, and yes, it manages all the subscriptions too.

jonny_eh 4y ago

> because we can't just use the web browser already installed True on Mac, not on iOS. Apple doesn't let you ship custom web renderers. You need to use the system's built-in one. This applies to browsers such as Chrome and Firefox too!

throw03172019 4y ago
I believe they are goi g to allow custom engines going forward. Source: https://www.macrumors.com/2023/02/07/mozilla-developing-non-webkit-version-of-firefox/ https://www.macrumors.com/2023/02/07/mozilla-developing-non-...

deleted 4y ago

[deleted]