7 ms·

Partially agree. I understand security concerns; we shouldn't allow random web apps to freely access privileged operations, for example. (Should we allow web ap

• rolha-capoeira 9y ago
  > 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. There's a bigger story to this, one could assume. I'll be the first to say that iOS and Safari (particularly on iOS) has generally lagged behind the community in adopting standards. But this seems like a feature, not a bug, to me. What if the user has 10 PWAs open in Safari? Should they all maintain state as the user goes elsewhere in the OS? If I put an app into the background, I want it to stop its execution, unless I've given it permission to do a limited set of things. This goes double for websites — no way do I want them to continue using the OS in the background.
  • judah 9y ago
    Imagine if you install Pandora as a PWA. It's now on your homescreen. You launch it. You start playing some music. Now you switch over to Twitter. Woops! The audio stopped playing. You bring Pandora back to the fore. It reloads and starts playing a different song. Worse, there's no way to fix that. That's how it's supposed to work. This is the state of PWAs on iOS.
    • scarface74 9y ago
      And Pandora chose that it was worth the trade off in time and resources to create a better native experience it seems like a win for users.
    • hamiltonkibbe 9y ago
      Imagine you install $ANYTHING as a PWA. It's now on your homescreen, you launch it. You do $THING. now you switch to twitter. Now the PWA -- in the background -- loads some ad with an autoplaying video and now theres ad audio coming from ... well, you're not sure where, but it doesn't seem like it's coming from twitter. now you have to go find it and stop it. Meanwhile bitcoinminer.js is burning through your battery in the background because those video ads just weren't quite enough revenue. I'm not sure which one sounds worse.
      • judah 9y ago
        Stepping back a moment, it's worth noting that this was Steve Jobs' original vision for the iPhone: “The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.” Here we are, a decade later, and Apple has not only abandoned that vision, they are actively working against it by preventing web apps from becoming first-class citizens on their platform. I mean, consider an app that does 2FA. "To sign in, please enter the code sent to your mobile device." You switch over to Messenger, and...wooops! Your app just reloaded its home page, and the auth prompt is gone. Surely, any rational person can see this is too restrictive. Perhaps Apple will loosen these restrictions in the future. Yes, as you point out, there is the potential for abuse. But that's already there with native apps. The things you just mentioned can -- and have -- been done with native apps.
        • saagarjha 9y ago
          > it's worth noting that this was Steve Jobs' original vision for the iPhone One which they quickly backtracked on after realizing that it needlessly restricted what apps could do, and one which they could not shoehorn security into.
        • hamiltonkibbe 9y ago
          So now there's some awesome PWA api giving you all those native features, and a permissions model, and so you install SUPERPHONE app, and that needs access to your contacts and to make and receive calls, and you say "ok, yeah this is a better phone app so those are reasonable". Now everything running JS in the context of $SUPERPHONE_DOMAIN or whatever has these new permissions. superphone pwa's calls to window.PwaGetContacts() and window.PwaMakeCall() work and everyone's happy, and your phone really is super now. the app shows a banner ad from google and you're cool with that because it was free, and hey, developers need to eat too. Someone who makes ads figures out that ads can run JS. So your app pulls down an ad from some ad network and that ad has some cool JS that detects that those functions are available and starts calling all your friends from your phone and telling them that "`window.PwaGetOwnerName()` is really excited about LinkedIn and wants you to be their contact" after uploading your contact list to every 3rd party data broker that would pay for it. well, that sucks, maybe there's a better way to limit the code that can run on your phone with specific permissions
    • FridgeSeal 9y ago
      If I wanted functionality past the most basic kind, then I would use the full, native app. Web apps are not a sufficient replacement for a proper application and if a developer can't be bothered building an app properly then they shouldn't be surprised when I don't use it.
      • thomasz 9y ago
        This is circular reasoning. Web Apps are not a replacement for a proper application because they are being sabotaged.
        • FridgeSeal 9y ago
          Ok, put it this way: they should be sabotaged if they're never going to be as good as native apps. Seeing as they're not going to be, and Apple has standards for how it's phone behaves and the quality of the ecosystem, I have no problems with them essentially insisting that developers build proper apps.
          • TheCoelacanth 9y ago
            They're never going to be as good because Apple is sabotaging them. A web app has many advantages over a native app. That is why people visit websites instead of installing an app for every website.
            • FridgeSeal 9y ago
              Almost literally by definition, a webapp isn't going to be as good as a proper application. If one of the advantages is "front end guys don't have to learn another language" I'm starting to be of the opinion that that's their reticence to use the proper tools, rather than the inherent superiority of JS. People visit websites because many of them don't need to be apps. I don't need an app (webapp or otherwise) for each of the half/dozen sites I visit once a week. That's just clutter and wasted space, and in the case of a web-app, clutter, wasted space and a shitty app that's no better than simply visiting the website directly.
• Silhouette 9y ago
  Mobile Safari's support for modern web standards has made IE look good for some time now. It seems very clear that Apple doesn't want a good experience for web users on its devices. It's very frustrating, because we keep getting requests from users for features we're happy to look into or even already working on... but then discover the user has an iPhone, where the necessary web technologies are supported poorly if at all. Unfortunately, since Apple also won't let anyone else supply a real browser to run on its devices, there's also no meaningful competition to force them to do better. Maybe monopoly/anti-competition regulations should be adapted so the same principles apply to platforms in this sort of controlling position.
  • scarface74 9y ago
    It isn't Apple that needs to do better for its users the developers need to invest the time and resources so that the users have the best experience. If you aren't willing to offer it, I'm sure someone will.
    • Silhouette 9y ago
      If you aren't willing to offer it, I'm sure someone will. Given that some of the services my businesses offer are in various niche markets, and as far as we know they are totally unique and have no direct competition after several years on the market, apparently you are mistaken.
      • saagarjha 9y ago
        > as far as we know they are totally unique and have no direct competition after several years on the market That's what every company says right before they get their lunch eaten by a startup that comes out of nowhere ;)
        • Silhouette 9y ago
          No doubt, but I've done this a few times now with a few different businesses that are still going several years later, so I'll take my chances. :-) But seriously, there seems to be this almost universal assumption that if a market is worth serving in business, there will always be competition. That makes little sense to me, because if the modern online world has taught us anything, surely it is that our societies are incomprehensibly diverse and have countless niche interests and small communities within them. Those in turn create countless business opportunities, as long as you admit the possibility of smaller businesses that serve such markets in some useful and commercially viable way yet have no hope or ambition to become the next unicorn. The most profitable things I've worked on typically weren't in that category, but most of the best-received things I've ever worked on were. But sometimes that sort of market is only big enough for one player to really do well, or maybe there's only one player willing and able to invest in setting something up to cater to that particular market anyway.
• millstone 9y ago
  > 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