Live data from Hacker News

Private client-side-only PWAs are hard, but now Apple made them impossible

andregarzia.com

901–910 of 927 posts

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#901
post #897

Earlier quoted context omitted.

I actually suspect the reason the codepath is still enabled is probably to do with third parties running in a PWA context. That said I don’t see how this is actually all that flimsy of a mechanism, it avoids needing a special case. As it is you can’t really count on browser local storage alone for long-term storage; the same is actually true for Android and iOS apps too, who lose all of their local data when they are…

> Honestly, if my data really matters, I don’t want it to be stored only in a single place. That's all well and good except when you lose your emails that your wrote on the plane and didn't get a chance to send yet. I'm not arguing that you should _never_ synchronize the data off the phone, but where I store data on my phone should be as robust as possible. So far I have never had my phone delete an application I had…

Web apps are unreliable for sure, but I think that is where PWAs should come in. The problem is there’s just not a ton of them today, and parity just isn’t there. That having been said, I’ve never lost local storage on a PWA in any OS so far...

Also I am not saying programs and browsers should not make a best effort to reliably persist data locally... just that robust local storage only really needs to be so robust, because any more robust and you might be fooled into relying on it.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#902
post #555

Earlier quoted context omitted.

If there is, as they say, a dedicated counter on those home screen applications, what is the threshold? Will home page PWA apps not used often (say, for infrequent uses like travel) have first party data deleted after the icon isn’t clicked for some time? This is highly unclear and confusing.

The deletion occurs if you use the app for seven days and don't visit the site. Pinned sites cannot meet those criteria and will not trigger deletion.

How about pinned sites that have not been accessed for > 7 days? I neither use the app nor visited the site for e.g. 2 weeks.. what will happen to e data for e pinned site? Apple is being vague here.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#903

Earlier quoted context omitted.

That link is from 2011, and the referenced verbiage is nowhere to be found in the App Store terms. I believe that the current terms leave the App Store open to GPL software. Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement.

> I believe that the current terms leave the App Store open to GPL software Please read the following: https://github.com/nextcloud/ios/blob/master/COPYING.iOS https://news.ycombinator.com/item?id=12827624 https://www.fsf.org/blogs/licensing/more-about-the-app-store... > Also, Apple will only remove software if you notify them of copyright infringement; it's not their job to preemptively perform licensing enforcement…

> https://github.com/nextcloud/ios/blob/master/COPYING.iOS

I tend to think of this as reaction to GPL FUD; I know some people who have these so they never have to actually figure out the answer to this question.

> https://news.ycombinator.com/item?id=12827624

I have argued that a close reading of the TOS currently seems to allow GPL: https://news.ycombinator.com/item?id=21943994

> https://www.fsf.org/blogs/licensing/more-about-the-app-store...

Again, this is super old. Do you have anything newer?

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#904

Earlier quoted context omitted.

How do you use the iOS Keyring from within a PWA or website in Safari?

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

Right, but Cordova isn’t PWA.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#905
post #854

This is really in response to the irresponsible use of APIs for trackers. Evercookie is a stunning example of how far it can go... From their repo: - Standard HTTP Cookies - Flash Local Shared Objects - Silverlight Isolated Storage - CSS History Knocking - Storing cookies in HTTP ETags (Backend server required) - Storing cookies in Web cache (Backend server required) - HTTP Strict Transport Security (HSTS) Pinning (w…

You could permissionwall that stuff, just like iOS asks for permissions to ask your location. If a random website wants to mess with Local Storage I know that I need to turn around.

... however i'm afraid that 99% of all users (the non-techies) would just be annoyed by the popup and click "OK"

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#906

Earlier quoted context omitted.

> ... Consumers are another problem. ... You blame Apple, Google and your consumers, instead of just making native apps. Why?

As an iOS and Android developer myself, this doesn't effect me but I still think Apple and Google making things harder for PWA is bad because Apple and Google are the gate keepers for what goes on their native app stores. I can cut some slack for Google as they at least allow third party app stores but Apple doesn't. Either Apple should stop being the gate keeper or stop making life harder for web devs.

Maybe Apple could offer a compromise and allow users to sideload apps, but restrict non-App Store apps from accessing the file system or any kind of personal identification (like location etc.)

And improve their documentation to lower the barriers to native development.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#907
post #613

Earlier quoted context omitted.

Hi there, I'm the product manager for PWAs on the Chrome team. Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recentl…

Well, it would have been helpful to provide a simple example of a working pwa. The example at https://codelabs.developers.google.com/codelabs/your-first-p... was way too complicated as a first example, if all I wanted to know was how to make my app installable and is also broken as it uses some outdated tools. (don't remember the details) Also, it could have been mentioned somewhere, that when you serve from localhos…

Thanks for the feedback! This is now the reference "first PWA" example: https://web.dev/codelab-make-installable. Let me know if you find it easier for new devs to get started with. The other codelab and a lot of other scattered content will be removed once we finish the migration to web.dev.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#908

Earlier quoted context omitted.

They already explained that they are using Cordova. This bridges native APIs to web apps. What you deploy is a native app through the app store.

Right, but Cordova isn’t PWA.

Sure! In a PWA, storing login tokens in the keyring would not be possible. So as I said, on iOS the localstorage (and cookies) would be cleared in low disk space conditions anyway. So the PWA experience was already not good!

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#909
post #613

Earlier quoted context omitted.

Hi there, I'm the product manager for PWAs on the Chrome team. Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recentl…

More background services would be very nice even though it's a bit of a security nightmare. A request was opened almost 5 years ago for background geolocation services. Any plans for https://developers.google.com/nearby ? I don't want Google or central authorities to decide which PWAs are "trustworthy" directly to ask for certain permissions but there could be a way or compromise. I don't remember which feature it wa…

Background geo, including geofencing is challenging, but there may be a way forward. We're exploring this conceptually, but it's not in the plan for 2020. I'd certainly like to be able to improve the capabilities of web based ride sharing and similar apps that have a need for this.

Bluetooth discovery is an especially thorny area from a privacy perspective. What use cases did you have in mind?

Asking for permissions upfront has been found to be an anti-pattern in systems UXR. Research has found that users make better decisions and find the experience less interruptive when permissions are requested in context at runtime. For example, in a video chat app, it's better to ask for the camera/mic permission at the start of the first chat session, not when the app first starts. Mac OS, Android etc. and other platforms have all been moving in this direction over the past few years.

When the permission is requested, we're investigating ways that we can do more to communicate permission risks to the user. Nothing publicly shareable yet, but do expect experiments to be showing up in dev channels over the next few months while we try new things.

Re: Private client-side-only PWAs are hard, but now Apple made them impossible

#910
post #613

Earlier quoted context omitted.

Hi there, I'm the product manager for PWAs on the Chrome team. Very interested in hearing about pain points you've had building out PWAs, especially if there's features you were keen on that haven't been released. Easiest way to reach me is on Twitter: https://twitter.com/b1tr0t Fully agree with you that docs are all over the place. We've started to consolidate docs under web.dev, and the PWA section launched recentl…

Please consider contributing to MDN. It's the best source for web development and it would be great to keep everything there, properly cross-referenced, etc.

As another user mentioned, we do contribute to MDN. MDN is where we point devs for reference documentation. web.dev is for guides, how to's and other support docs.
Post reply on HN