5 ms·

I also wonder what's point of PWAs _only_ supported in WebKit. It feels like they trying to keep playing cat and mouse.

readams 3y ago
Mostly Apple wants to ensure that PWAs can't emerge as a viable option. As long as they're on WebKit, they can ensure that the apps are limited in their functionality.
- kemayo 3y ago
  If that's Apple's motivation, why have they been implementing PWAs at all? Killing them would be even simpler if they just weren't on iOS in the first place.
  - jamesgeck0 3y ago
    They’ve been on iOS since the beginning, predating the App Store. They were originally supposed to be the only public API for building 3rd party apps on iOS. For a long time they appeared to be in maintenance mode on iOS. They’re still years behind what Chrome allows PWAs to do.
    - dunham 3y ago
      Apple has also added PWA to Desktop Safari in the latest OS release (which seems to work well for Tana). So their Safari team is putting some continuing effort behind PWA in general. I used this when I was taking a break from chrome, because Firefox cancelled their PWA support for Desktop.
  - albert180 3y ago
    Because they are their go to excuse why the limitation to the App Store isn't a monopoly with the regulators.
    - burnerthrow008 3y ago
      So... you're saying that having PWAs is purely performative because nobody actually uses PWAs... meaning that the loss of PWAs has no impact on customers?
      - albert180 3y ago
        No, but they are obviously not equivalent in capabilities on iOS
  - realusername 3y ago
    As far as I'm concerned, it's just an argument for them to use in antitrust lawsuits. "See, they could have developed a web app if they aren't happy with our store". It's better to keep an option opened, especially if it's not good enough to be used.
- graftak 3y ago
  PWA’s can run a ServiceWorker in the background too, I can imagine Apple does not want anyone to be able to run code they don’t control as a background task as this may negatively affect overall performance and battery life.
  - agust 3y ago
    Apple not wanting PWA to work properly on iPhones has nothing to do with performance, security, privacy, battery life or whatever excuse they may officially come up with. The only reason Apple does not want PWA is because it threatens their App Store profit. More information: https://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/ https://open-web-advocacy.org/blog/apple-backs-off-killing-w...
    - robin_reala 3y ago
      These black and white takes are boring. It can be all of the above.
      - Sammi 3y ago
        Only one of the options affects the bottom line of Apple. Incentives incentives incentives. When you want to understand what and why people do what they do, always find out the incentives.
        robin_reala 3y ago
        Then why would they have bothered adding any support in the first place? There are market incentives in at least appearing to be modern.
        Sammi 3y ago
        Misalignment of the company bottom line (incentives) and employees bottom line (incentives). Company gets money from variable App Store revenue which is directly threatened by PWAs. Employees get money from fixed monthly salary, which is only indirectly threatened by PWAs. Employees take money and do what is required of them, and otherwise do what they think is awesome. Employees think PWAs are awesome so PWAs happen... until they threaten almighty App Store then it stops.
- scarface_74 3y ago
  Like they have emerged as a viable option on Android?
  - sangnoir 3y ago
    Yes. Would you rather install a full-on app for a once-off event (concert, festival or conference) or would you rather just install a light-weight PWA or just use the website?
    - ryandrake 3y ago
      Just one user's opinion. I'd just use the web site for a one-off event. But if I had to install something for some reason, I probably wouldn't care what technology it was made with and would only care if there was a functionality or performance difference. Honestly, nobody but web developers cares about PWAs. If you put a gun to my head and made me choose between Native and PWA, I guess I'd choose a native app that looks and feels like a native app, performs like a native app, uses native controls and UX idioms, and has the security guarantees of a native app. I honestly don't think users's really care about this PWA vs. Native App war that web developers insist on making a big deal over.
    - Tteriffic 3y ago
      AppClip would be best
    - scarface_74 3y ago
      Well, and that all works on Safari… And that’s not what most people consider a PWA.
      - sangnoir 3y ago
        I have attended conferences that can be described as "scrappy": flakey oversubscribed wifi, lots of interesting talks and multiple "streams" in different rooms over 2-3 days in a foreign country where my visit was too short to bother to buy a SIM card. Being apple to see the schedule offline would have been a boon, a problem that can be effectively solved by PWAs. Any app that's geared towards visitors or tourists is better served as a PWA - think of the apps used to pay for transit, or parking in a city you're visiting. A website is Ok, but offline access and a shortcut on the homescreen would be better.
zer00eyz 3y ago
I have been making the argument that apple pulling back on this was a "security" issue. Browsers are more code than most OS's they run on. Hell a browser IS its own operating system for all intents. One that can access the network and do all sorts of bad things on its own. This matters for the phone. Its a device many people take with them everywhere, bathrooms, bedrooms etc. Locking PWA's to web kit likely has some underlying security issues. If you dont think browsers aren't full of holes and permissions issues go look at the LAST compromise, Edge snarfing Chrome tabs. All that said, there are a lot of places where PWA's still suck, because browsers suck.
- kmeisthax 3y ago
  The underlying problem is that when you pin a site to your home screen, that site gets a separate application identity and storage container[0]. SpringBoard shows it as a separate icon and window in the multitasking view and Settings shows a separate settings page for it, too. If you squint a little, you'll notice that this sounds a little like the problem Craig Federighi cited with Xbox's cloud app. Namely that Apple doesn't want multiple apps wearing the same 'trenchcoat', so to speak. But they also don't want to actually implement the APIs necessary for an app to break itself apart in the UI and pretend to be multiple apps. So you can't have multiple icons on the home screen, or launch with different storage containers and permissions depending on what app was touched. You can't even have a dependency that gets shared across multiple apps, like what Microsoft wanted with the streaming and authentication code for Xcloud. Ship multiple copies. Personally this still smells like malicious compliance. Apple does literally all of the things I just mentioned and has been doing them since iPhone OS 1.0. Any security issue caused by an app having two icons can be remedied by the exact same review process that Apple insists they need to be the kings of anyway. [0] On Apple "device" OSes, each installed app has it's own sub-home directory inside the user's home directory (/var/mobile). This is called a container. Originally the container had both the app install and it's data; but those were split around iOS 9 so that apps could write to shared containers. That's also why some apps don't actually show up on the Storage view in Settings, and instead there's a separate entry for the developer as a whole. Containers don't exist on macOS. Mac App Store apps and iOS apps on macOS live in /Applications and write to your user home directory.
fredoralive 3y ago
IIRC "Web Apps" pinned to the homescreen (which was the thing being broken) are hosted by Springboard (the shell), not Safari as part of the magic so they appear as separate apps. Rather than rework this to allow rendering engine switching, they obviously just decided to turn it off, at least at first.
- rezonant 3y ago
  That part was still present: You could still add a web app to your home screen. It was that it didn't run as a PWA, with the additional features PWAs get.
mmis1000 3y ago
Because it's technically a separate app in ios system, with all storage separation, permission… etc. enforced by the system itself. And ios don't actually allow any app to install another app unlike Android. The pwa install process is a somewhat backdoor build into safari and ios for this specific usage and never made public at first place. To make this work with another browser. They would need to fix this, make a safe public api for it, and publish it in new ios version. (Which they think it's way too much work and rather want to get rid of it instead)
- adrr 3y ago
  Browser can do the exact same thing as a PWA app. It's using the same web APIs. Edit: don't know why I am getting downvoted. A web page can do exaxt same thing as a PWA. Access camera,mic, files system, Bluetooth etc, send push notifications here's an example. https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
  - yurishimo 3y ago
    Not to access native push notifications which was the one feature that Apple only just added in 2023. Sure, Webkit and mobile safari have supported things like service workers for years and years, but we just freaking got notifications and so it felt like they were yanking it back. But to make push notifications happen, you need a central push server. How do you handle that with a third party browser engine? Where does the browser app request notification access? But then how is that delegated to a separate PWA if you have notifications turned off for the browser specifically? Currently, notifications run through Apple servers on iOS. With third party engine support, that opens a can of worms needed to proxy the requests into an iPhone.
    - adrr 3y ago
      PWAs on ios couldn't send them until the it was supported in webkit and safari. Talking security concerns about a PWAs which is the same risk as allowing users browser the internet since it's using the exact same APIs. Banning PWAs security reasons wouldn't make sense unless you just banned users from browsing the internet on the device as well. It's the same security threat.
brookst 3y ago
It’s super well documented if you care to look. PWA’s rely on a Safari service worker running as a system process. Under the current iOS PWA architecture, any browser hosting a PWA can ignore app sandboxing. I don’t understand why people speculate weird conspiracies rather than doing a bit of research to see the actual issue. We can still pile on Apple for a bad design, lack of foresight, and unwillingness to totally rebuild the PWA architecture.
deleted 3y ago
[deleted]

Mostly Apple wants to ensure that PWAs can't emerge as a viable option. As long as they're on WebKit, they can ensure that the apps are limited in their functionality.

kemayo 3y ago
If that's Apple's motivation, why have they been implementing PWAs at all? Killing them would be even simpler if they just weren't on iOS in the first place.
- jamesgeck0 3y ago
  They’ve been on iOS since the beginning, predating the App Store. They were originally supposed to be the only public API for building 3rd party apps on iOS. For a long time they appeared to be in maintenance mode on iOS. They’re still years behind what Chrome allows PWAs to do.
  - dunham 3y ago
    Apple has also added PWA to Desktop Safari in the latest OS release (which seems to work well for Tana). So their Safari team is putting some continuing effort behind PWA in general. I used this when I was taking a break from chrome, because Firefox cancelled their PWA support for Desktop.
- albert180 3y ago
  Because they are their go to excuse why the limitation to the App Store isn't a monopoly with the regulators.
  - burnerthrow008 3y ago
    So... you're saying that having PWAs is purely performative because nobody actually uses PWAs... meaning that the loss of PWAs has no impact on customers?
    - albert180 3y ago
      No, but they are obviously not equivalent in capabilities on iOS
- realusername 3y ago
  As far as I'm concerned, it's just an argument for them to use in antitrust lawsuits. "See, they could have developed a web app if they aren't happy with our store". It's better to keep an option opened, especially if it's not good enough to be used.
graftak 3y ago
PWA’s can run a ServiceWorker in the background too, I can imagine Apple does not want anyone to be able to run code they don’t control as a background task as this may negatively affect overall performance and battery life.
- agust 3y ago
  Apple not wanting PWA to work properly on iPhones has nothing to do with performance, security, privacy, battery life or whatever excuse they may officially come up with. The only reason Apple does not want PWA is because it threatens their App Store profit. More information: https://open-web-advocacy.org/blog/apple-backs-off-killing-web-apps/ https://open-web-advocacy.org/blog/apple-backs-off-killing-w...
  - robin_reala 3y ago
    These black and white takes are boring. It can be all of the above.
    - Sammi 3y ago
      Only one of the options affects the bottom line of Apple. Incentives incentives incentives. When you want to understand what and why people do what they do, always find out the incentives.
      - robin_reala 3y ago
        Then why would they have bothered adding any support in the first place? There are market incentives in at least appearing to be modern.
        Sammi 3y ago
        Misalignment of the company bottom line (incentives) and employees bottom line (incentives). Company gets money from variable App Store revenue which is directly threatened by PWAs. Employees get money from fixed monthly salary, which is only indirectly threatened by PWAs. Employees take money and do what is required of them, and otherwise do what they think is awesome. Employees think PWAs are awesome so PWAs happen... until they threaten almighty App Store then it stops.
scarface_74 3y ago
Like they have emerged as a viable option on Android?
- sangnoir 3y ago
  Yes. Would you rather install a full-on app for a once-off event (concert, festival or conference) or would you rather just install a light-weight PWA or just use the website?
  - ryandrake 3y ago
    Just one user's opinion. I'd just use the web site for a one-off event. But if I had to install something for some reason, I probably wouldn't care what technology it was made with and would only care if there was a functionality or performance difference. Honestly, nobody but web developers cares about PWAs. If you put a gun to my head and made me choose between Native and PWA, I guess I'd choose a native app that looks and feels like a native app, performs like a native app, uses native controls and UX idioms, and has the security guarantees of a native app. I honestly don't think users's really care about this PWA vs. Native App war that web developers insist on making a big deal over.
  - Tteriffic 3y ago
    AppClip would be best
  - scarface_74 3y ago
    Well, and that all works on Safari… And that’s not what most people consider a PWA.
    - sangnoir 3y ago
      I have attended conferences that can be described as "scrappy": flakey oversubscribed wifi, lots of interesting talks and multiple "streams" in different rooms over 2-3 days in a foreign country where my visit was too short to bother to buy a SIM card. Being apple to see the schedule offline would have been a boon, a problem that can be effectively solved by PWAs. Any app that's geared towards visitors or tourists is better served as a PWA - think of the apps used to pay for transit, or parking in a city you're visiting. A website is Ok, but offline access and a shortcut on the homescreen would be better.

zer00eyz 3y ago

I have been making the argument that apple pulling back on this was a "security" issue. Browsers are more code than most OS's they run on. Hell a browser IS its own operating system for all intents. One that can access the network and do all sorts of bad things on its own. This matters for the phone. Its a device many people take with them everywhere, bathrooms, bedrooms etc. Locking PWA's to web kit likely has some underlying security issues. If you dont think browsers aren't full of holes and permissions issues go look at the LAST compromise, Edge snarfing Chrome tabs. All that said, there are a lot of places where PWA's still suck, because browsers suck.

kmeisthax 3y ago
The underlying problem is that when you pin a site to your home screen, that site gets a separate application identity and storage container[0]. SpringBoard shows it as a separate icon and window in the multitasking view and Settings shows a separate settings page for it, too. If you squint a little, you'll notice that this sounds a little like the problem Craig Federighi cited with Xbox's cloud app. Namely that Apple doesn't want multiple apps wearing the same 'trenchcoat', so to speak. But they also don't want to actually implement the APIs necessary for an app to break itself apart in the UI and pretend to be multiple apps. So you can't have multiple icons on the home screen, or launch with different storage containers and permissions depending on what app was touched. You can't even have a dependency that gets shared across multiple apps, like what Microsoft wanted with the streaming and authentication code for Xcloud. Ship multiple copies. Personally this still smells like malicious compliance. Apple does literally all of the things I just mentioned and has been doing them since iPhone OS 1.0. Any security issue caused by an app having two icons can be remedied by the exact same review process that Apple insists they need to be the kings of anyway. [0] On Apple "device" OSes, each installed app has it's own sub-home directory inside the user's home directory (/var/mobile). This is called a container. Originally the container had both the app install and it's data; but those were split around iOS 9 so that apps could write to shared containers. That's also why some apps don't actually show up on the Storage view in Settings, and instead there's a separate entry for the developer as a whole. Containers don't exist on macOS. Mac App Store apps and iOS apps on macOS live in /Applications and write to your user home directory.

fredoralive 3y ago

IIRC "Web Apps" pinned to the homescreen (which was the thing being broken) are hosted by Springboard (the shell), not Safari as part of the magic so they appear as separate apps. Rather than rework this to allow rendering engine switching, they obviously just decided to turn it off, at least at first.

rezonant 3y ago
That part was still present: You could still add a web app to your home screen. It was that it didn't run as a PWA, with the additional features PWAs get.

mmis1000 3y ago

Because it's technically a separate app in ios system, with all storage separation, permission… etc. enforced by the system itself. And ios don't actually allow any app to install another app unlike Android. The pwa install process is a somewhat backdoor build into safari and ios for this specific usage and never made public at first place. To make this work with another browser. They would need to fix this, make a safe public api for it, and publish it in new ios version. (Which they think it's way too much work and rather want to get rid of it instead)

adrr 3y ago
Browser can do the exact same thing as a PWA app. It's using the same web APIs. Edit: don't know why I am getting downvoted. A web page can do exaxt same thing as a PWA. Access camera,mic, files system, Bluetooth etc, send push notifications here's an example. https://developer.mozilla.org/en-US/docs/Web/API/FileSystem https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
- yurishimo 3y ago
  Not to access native push notifications which was the one feature that Apple only just added in 2023. Sure, Webkit and mobile safari have supported things like service workers for years and years, but we just freaking got notifications and so it felt like they were yanking it back. But to make push notifications happen, you need a central push server. How do you handle that with a third party browser engine? Where does the browser app request notification access? But then how is that delegated to a separate PWA if you have notifications turned off for the browser specifically? Currently, notifications run through Apple servers on iOS. With third party engine support, that opens a can of worms needed to proxy the requests into an iPhone.
  - adrr 3y ago
    PWAs on ios couldn't send them until the it was supported in webkit and safari. Talking security concerns about a PWAs which is the same risk as allowing users browser the internet since it's using the exact same APIs. Banning PWAs security reasons wouldn't make sense unless you just banned users from browsing the internet on the device as well. It's the same security threat.

brookst 3y ago

It’s super well documented if you care to look. PWA’s rely on a Safari service worker running as a system process. Under the current iOS PWA architecture, any browser hosting a PWA can ignore app sandboxing. I don’t understand why people speculate weird conspiracies rather than doing a bit of research to see the actual issue. We can still pile on Apple for a bad design, lack of foresight, and unwillingness to totally rebuild the PWA architecture.

deleted 3y ago

[deleted]