4 ms·

> For example, breaking open standards like "you can't play more than one stream of audio", or "you're not allowed to play audio if your app isn't in the fore"?

> For example, breaking open standards like "you can't play more than one stream of audio", or "you're not allowed to play audio if your app isn't in the fore"? What standard requires these things? And even if one does, it's not clear that users would be well-served by that standard. Apple has a rich native API for background audio playing, which covers things like whether the output stream should mix with other apps, what should happen on route changes, etc. AFAIK the web audio specs are much weaker, so Apple is going to make the most conservative choices here. > iOS's new PWA support actually reloads your whole page - losing all context and execution - every time you bring it to the fore. It kills all execution when putting the app into the background. This is beyond security; it is actually hostile to users and developers. "Hostile" is much too strong. We don't know what's a deliberate decision, and what's just a limitation of the first iteration of this stuff. And as a user, unrestricted background JavaScript execution sounds horrible to me: I definitely do not want that on my iPhone. Apps on iOS are only allowed to execute in the background in controlled ways, and there's no web APIs providing similar coverage, outside of Service Workers. So what do you think Apple should do here? Two points I guess: 1. Native APIs will always be more capable, and have better platform integration, than cross-platform layers built on top of them, including web APIs. It's specious to build on a non-native API and then complain that its capabilities and platform integration are inferior to native. 2. Every tiny piece of web capabilities gets used in a user-hostile way, that is hard to anticipate. For example, AudioContext's authors did not anticipate its browser fingerprinting uses. PWAs invite more of this stuff into my devices. Apple is right to be very conservative with what it allows these apps to do, at least initially.

rrix2 9y ago
> So what do you think Apple should do here? - Support service workers on PWAs that Safari has added to the Springboard. - Support permissions-based model for reasonable user-facing features like background audio and camera. - Don't reload application context when backgrounding PWAs; this doesn't happen if you run the exact same page in Safari-proper. It's really not hard... Apple has had longer than Google to do this right and has repeatedly chosen to not add mobile APIs to Safari until the 11th hour, which only hampers adoption and makes them take longer to get to the 11th hour in the first place. > It's specious to build on a non-native API and then complain that its capabilities and platform integration are inferior to native. It's not, however, specious to compare to non-native APIs on other platforms which is the point of this entire article. > Apple is right to be very conservative with what it allows these apps to do, at least initially. The problem here is that last part, the fact that iOS has severely lagged behind in open web API adoption for the better part of its existence
pier25 9y ago
> it's not clear that users would be well-served by that standard It's irrelevant. Standards aren't set to satisfy a portion of users. Can you image the clusterfuck if there were different sizes of Bluray discs?

rrix2 9y ago

> So what do you think Apple should do here? - Support service workers on PWAs that Safari has added to the Springboard. - Support permissions-based model for reasonable user-facing features like background audio and camera. - Don't reload application context when backgrounding PWAs; this doesn't happen if you run the exact same page in Safari-proper. It's really not hard... Apple has had longer than Google to do this right and has repeatedly chosen to not add mobile APIs to Safari until the 11th hour, which only hampers adoption and makes them take longer to get to the 11th hour in the first place. > It's specious to build on a non-native API and then complain that its capabilities and platform integration are inferior to native. It's not, however, specious to compare to non-native APIs on other platforms which is the point of this entire article. > Apple is right to be very conservative with what it allows these apps to do, at least initially. The problem here is that last part, the fact that iOS has severely lagged behind in open web API adoption for the better part of its existence

pier25 9y ago

> it's not clear that users would be well-served by that standard It's irrelevant. Standards aren't set to satisfy a portion of users. Can you image the clusterfuck if there were different sizes of Bluray discs?