zlacker

[return to "Apple’s refusal to support Progressive Web Apps is a detriment to the web"]
1. christ+q9[view] [source] 2017-07-27 12:43:31
>>jaffat+(OP)
I think a lot of commenters here are missing the point and getting distracted by push notifications (who wants a website spamming them with notifications?) and loading screens (hardly a feature).

Apple supporting PWA (Progressive Web Apps) is hugely important because it enables a future where web apps can natively support browser, Mac/Windows/Linux desktop, and mobile iPhone/Android/Windows native mobile with a single codebase of open technologies.

Why is that important? By fragmenting development effort, the overall product isn't as good on any platform.

There's an app I'm making on the side to keep track of your contacts (like a personal customer management system). This needs to store all your contacts offline, because it'd be too much friction to load everyone you've ever taken notes on over the network every time you open the app.

Right now, the only way for me to accomplish that on iOS is to make a native app. This means I had to learn an entirely new technology stack (React Native and XCode), completely rewrite my views, tie everything into my backend, and go through Apple's Byzantine approval process (which I still haven't done because I can't figure out why my app compiles and runs locally but complains about libraries not being linked when I try to archive it to upload to the app store).

This is unnecessary duplication of work that could've been spent writing new features, makes it harder to add new front-end features in the future (because now they have to be added in two places), and adds a huge lag in the time it takes me to push changes to the iOS client (weeks, vs. the seconds it takes to push a change to the web client).

If apple supported PWA, I would've spent my time making the database keep a local syncing copy on the browser (with minimongo or pouchdb), and then every platform would've benefited from faster page loads and offline syncing.

Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff.

◧◩
2. interp+9b[view] [source] 2017-07-27 13:02:24
>>christ+q9
But as an iOS user I expect you to use the technology stack provided by my preferred operating system. I don't want to use your app if you're targeting a lowest-common-denominator feature set.

When I change my preferred text size through accessibility settings, good native apps respond correctly. If I need voice over support, the operating system knows how to read the view hierarchy to me in a logical way.

When drag-and-drop becomes a thing in iOS 11, native apps will implement that feature well. I think it will take some time for web apps to implement it as nicely (if ever).

There are thousands of tiny details that your web app just won't have. Those details are more important than your familiarity with a tech stack or how long it takes you to deploy something.

You say that:

> By fragmenting development effort, the overall product isn't as good on any platform.

But I would say that:

> By building a web app, the overall product isn't as good on any platform.

I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.

◧◩◪
3. emsy+ie[view] [source] 2017-07-27 13:29:05
>>interp+9b
>I don't want to use your app if you're targeting a lowest-common-denominator feature set.

You might even use a hybrid app without it knowing. Many apps just need to show some buttons, input fields, images or a map and hit a web service. Brushing ALL hybrid apps off as useless is in my eyes just ignorant.

◧◩◪◨
4. interp+Tj[view] [source] 2017-07-27 14:05:55
>>emsy+ie
It's possible. I still use web apps (e.g., Slack client on macOS). But I dislike them compared to good native apps, mostly due to their lack of consistency with the platform and general sluggishness.

If I'm using a web app and not realising it, then I would happily keep using that app. I do not think I am, though.

Also, there are plenty of native apps which are terrible and not consistent with the platform. I do not like to use those either.

◧◩◪◨⬒
5. emsy+Xx[view] [source] 2017-07-27 15:35:30
>>interp+Tj
I get your point and do have a strong preference towards native apps too.

But there are other important factors to consider. I was working on a B2B app where users could see graphs and maps of a construction site in real time. The users were extremely happy how fast we could implement and release change requests and bug fixes. It was an ionic app. As far as I know, performance or lack of OS integration was never a problem. At the end of the day it's about choosing the right tool for the task.

◧◩◪◨⬒⬓
6. briand+AU[view] [source] 2017-07-27 17:44:15
>>emsy+Xx
They were happy because 80/100 is better than 0/100.

But how much happier would they be with 100/100. Just because you feed your guests chicken and they like it doesn’t mean that they would not like lobster more.

A good MacOS or Windows Dev can move just as fast as a web developer trying to make fake-native apps.

◧◩◪◨⬒⬓⬔
7. emsy+L51[view] [source] 2017-07-27 19:03:08
>>briand+AU
Yes, but one platform at a time. We served updates to Android and iOS users almost simultaneously. Again, I usually prefer native, non GCed apps. But I also don't try to fix problems where there are none.

If Android and iOS made it easier to share middleware libraries (C++ is a second class citizen for both), I think there would be a smaller incentive for HTML5 apps.

◧◩◪◨⬒⬓⬔⧯
8. fredsi+Y72[view] [source] 2017-07-28 06:04:38
>>emsy+L51
But the fact is that they would probably still be happier if you have served them native apps at the same rate because the native apps probably had been better in some way.

I get that sometimes it's not feasible to built native apps because you have to do the work twice in the same time and so on, but that is completely irrelevant to how good the product is. Is it good enough? That is a different thing entirely.

◧◩◪◨⬒⬓⬔⧯▣
9. Sacho+S82[view] [source] 2017-07-28 06:20:33
>>fredsi+Y72
But to circle back to the original topic - if users would be much happier with 100/100 instead of 80/100, then Apple's refusal to allow developers to achieve 90/100 with the same effort is crippling user happiness.
◧◩◪◨⬒⬓⬔⧯▣▦
10. fredsi+ra2[view] [source] 2017-07-28 06:50:57
>>Sacho+S82
Are they not allowing it? Do you mean that because you have to use their platform specific tech instead of some cross-platform tech, they are not allowing it? Maybe they don't believe that you can ever reach 100/100 with "webapps", except if you lower the general perception of what 100 is to what is actually 80?

I certainly don't believe so.

I think part of the gap is that some folks believe features are everything, and others believe that features are one thing, and quality, support, accessibility and other stuff is just as important, the stuff that in my mind makes good products in general, both in software and hardware, but also in wood-working and clothing and so on.

If features are everything, I can see why cross-platform is what you want, but that is so far away from anything that is Apple.

◧◩◪◨⬒⬓⬔⧯▣▦▧
11. emsy+zl2[view] [source] 2017-07-28 10:03:25
>>fredsi+ra2
It's not even that. I hate it when a website prompts me to install their stupid app for funtionality that could easily fit in a webapp. If this standard means I don't have to install an app for every website I would be very happy.
[go to top]