Apple’s refusal to support Progressive Web Apps is a detriment to the web(medium.com)
medium.com
Apple’s refusal to support Progressive Web Apps is a detriment to the web
https://medium.com/philly-dev-shop/apples-refusal-to-support-progressive-web-apps-is-a-serious-detriment-to-future-of-the-web-e81b2be29676
450 comments
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.
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.
>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.
I would wager that the average quality of an iOS app written by someone like OP that "has a web experience and _has_ to learn iOS just to work on that platform" will probably be lower than if that person (with web experience) could just extend their web app natively with PWA.
I completely agree with you that the app should feel native to the platform (I actually quit a job a while back because they wanted me to theme our web Android experience as iOS for "consistency across all devices" instead of matching the user's device's design patterns), but there is huge value in giving the devs the tools they need to write the best product they can, and splitting codebases and requiring more work/knowledge/moving parts is actively detrimental to a quality end-product for everyone, unfortunately.
I would wager that the average quality of an iOS app written by someone like OP that "has a web experience and _has_ to learn iOS just to work on that platform" will probably be lower than if that person (with web experience) could just extend their web app natively with PWA.
I completely agree with you that the app should feel native to the platform (I actually quit a job a while back because they wanted me to theme our web Android experience as iOS for "consistency across all devices" instead of matching the user's device's design patterns), but there is huge value in giving the devs the tools they need to write the best product they can, and splitting codebases and requiring more work/knowledge/moving parts is actively detrimental to a quality end-product for everyone, unfortunately.
> iOS app written by someone like OP
That's a business choice that they made, and will suffer for. If a developer and business choose to half-ass the native iOS application, there's no reason to believe it would behave any better on iOS when written as a webapp.
> the tools they need to write the best product they can
The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs. There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
That's a business choice that they made, and will suffer for. If a developer and business choose to half-ass the native iOS application, there's no reason to believe it would behave any better on iOS when written as a webapp.
> the tools they need to write the best product they can
The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs. There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
"The best product that can be made will never be made with cross-platform tooling."
You're making a circular argument to the original point. If you pointlessly cripple the best "cross-platform toolset" (the web) then of course the products made with it won't be as good.
Native mobile apps belong in the same category as desktop apps - they are good when you need close-to-the-metal graphics but there's no reason you should have to open up a desktop app to read the news or even do some light word processing.
You're making a circular argument to the original point. If you pointlessly cripple the best "cross-platform toolset" (the web) then of course the products made with it won't be as good.
Native mobile apps belong in the same category as desktop apps - they are good when you need close-to-the-metal graphics but there's no reason you should have to open up a desktop app to read the news or even do some light word processing.
Even if web browsers were on the same page across all platforms and did everything front end dev's dreamed of, web apps are still not going to be as good as native for the fact that they do nothing to leverage what makes any particular platform good, and worse, will be developed around the least capable platform's feature set. In a world where web apps dominate and are the overwhelming majority, why should OS vendors even bother with furthering innovation on the OS level? Nothing would be taking advantage of it. They'd do just as well to boot straight into a generic grey browser environment and call it a day!
As for the web being the de facto solution for light tasks, I'm not sure I agree there either, at least with the web's present resource consumption problems. There's no reason, for instance, for a word processor that barely matches modern WordPad or Word 95 in terms of features to be as heavy as it is (Google Docs).
If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
As for the web being the de facto solution for light tasks, I'm not sure I agree there either, at least with the web's present resource consumption problems. There's no reason, for instance, for a word processor that barely matches modern WordPad or Word 95 in terms of features to be as heavy as it is (Google Docs).
If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
>web apps are still not going to be as good as native for the fact that they do nothing to leverage what makes any particular platform good, and worse, will be developed around the least capable platform's feature set
We already see this (and solve for this) on desktop and platforms with a lot of variance in capability like Android. Just because people out there run 2.3 Android doesn't mean my 7.1 apps are going to be any less quality, even if they still work on the least-capable platform's featureset.
The obvious solution to this is to exclude or disable features from devices that can't handle them, which is also possible and encouraged on the web (with some decent precision through identification and fingerprinting provided by a myriad of things like service workers). Your banking site probably works in IE8 (barely), but that doesn't mean your up-to-date Chrome/Safari/whatever is going to be a worse experience.
>If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
Web apps are focused on optimizing _different_ resources than native apps, that's all. Google Drive, for example, offers me an experience with no local installation cost in storage, virtually unlimited storage space for files, ancillary services like backups/authentication/sharing/etc handled for "free", native-like responsiveness while working offline, a low barrier-to-entry (unlike downloading/installing an app), a smoother experience across multiple devices, etc etc. These are all qualities that a web experience does better, and I think these are all qualities that people (myself included) value over the separate benefits of traditional native apps.
We already see this (and solve for this) on desktop and platforms with a lot of variance in capability like Android. Just because people out there run 2.3 Android doesn't mean my 7.1 apps are going to be any less quality, even if they still work on the least-capable platform's featureset.
The obvious solution to this is to exclude or disable features from devices that can't handle them, which is also possible and encouraged on the web (with some decent precision through identification and fingerprinting provided by a myriad of things like service workers). Your banking site probably works in IE8 (barely), but that doesn't mean your up-to-date Chrome/Safari/whatever is going to be a worse experience.
>If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
Web apps are focused on optimizing _different_ resources than native apps, that's all. Google Drive, for example, offers me an experience with no local installation cost in storage, virtually unlimited storage space for files, ancillary services like backups/authentication/sharing/etc handled for "free", native-like responsiveness while working offline, a low barrier-to-entry (unlike downloading/installing an app), a smoother experience across multiple devices, etc etc. These are all qualities that a web experience does better, and I think these are all qualities that people (myself included) value over the separate benefits of traditional native apps.
> the best "cross-platform toolset"
I've used Electron apps where no such restrictions have been put in place; it has lead me to believe HTML/CSS/JavaScript is nowhere near the best "cross-platform" toolset. It's more accurate to say that it's the lowest common denominator. Electron desktop apps today look and act like Java apps from ten years ago.
I'd say that the onus is on web developers to prove that it is capable of creating cross-platform apps that are even as good as, say, Eclipse, before attempting to call themselves "the best".
> do some light word processing.
Due to how much latency affects typing and interaction with an editor, I absolutely do want a native desktop app - neither Atom nor VSC react quickly enough for my editing uses, and Google docs is aggravating to write more than a page or two in.
I've used Electron apps where no such restrictions have been put in place; it has lead me to believe HTML/CSS/JavaScript is nowhere near the best "cross-platform" toolset. It's more accurate to say that it's the lowest common denominator. Electron desktop apps today look and act like Java apps from ten years ago.
I'd say that the onus is on web developers to prove that it is capable of creating cross-platform apps that are even as good as, say, Eclipse, before attempting to call themselves "the best".
> do some light word processing.
Due to how much latency affects typing and interaction with an editor, I absolutely do want a native desktop app - neither Atom nor VSC react quickly enough for my editing uses, and Google docs is aggravating to write more than a page or two in.
> Due to how much latency affects typing
How much latency are we talking about here? I can't imagine how latency would affect typing..
> and interaction with an editor
Agreed, but again, how much latency are we talking about here? The projects I've used VSCode on have never had latency issues.
How much latency are we talking about here? I can't imagine how latency would affect typing..
> and interaction with an editor
Agreed, but again, how much latency are we talking about here? The projects I've used VSCode on have never had latency issues.
Have you tried VScode? It feels native. Much more so than Java apps of old (especially Swing).
>The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs.
This is hard to argue for/against, because having one (native or cross-platform) generally precludes you from simultaneously having both (necessary for a proper comparison).
Of note: I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow. There are also benefits I know exist (as a dev) that I don't see (as a user) like shared code that shouldn't be discounted just because the end-user can't see them -- they indirectly result in a better product for the end-user by making it easier to add new features and maintain existing code.
Also: I've never had any issues with Minecraft's cross-platform java client either. Would it be any better as separate native apps targeted at each platform?
This is hard to argue for/against, because having one (native or cross-platform) generally precludes you from simultaneously having both (necessary for a proper comparison).
Of note: I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow. There are also benefits I know exist (as a dev) that I don't see (as a user) like shared code that shouldn't be discounted just because the end-user can't see them -- they indirectly result in a better product for the end-user by making it easier to add new features and maintain existing code.
Also: I've never had any issues with Minecraft's cross-platform java client either. Would it be any better as separate native apps targeted at each platform?
> I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow
That says nothing except the sad state of the other native apps you use in your workflow.
The truth is that yes, indeed, I can find a lot of native apps that are just about as "good" as slacks native Mac (and iOS - it's really bad too) app, and I can also find a lot that are a lot worse. But why compare to them at all? We should be measuring how good an app is by comparing it to, in this case, the best of the best native apps on the particular platform, or across all platforms, if so desired.
That says nothing except the sad state of the other native apps you use in your workflow.
The truth is that yes, indeed, I can find a lot of native apps that are just about as "good" as slacks native Mac (and iOS - it's really bad too) app, and I can also find a lot that are a lot worse. But why compare to them at all? We should be measuring how good an app is by comparing it to, in this case, the best of the best native apps on the particular platform, or across all platforms, if so desired.
Slack for Mac: Want to right-click a word to look it up like nearly every other Mac application? Nope, you don't get to do that. Want to turn off smart quotes or something similar using the standard method of right-clicking the text entry field? Nope.
These things _used_ to work in the Slack app. What happened?
These things _used_ to work in the Slack app. What happened?
FWIW, I don't have any of those issues in the Linux client. As of right now (in 4 orgs), it's using <10% memory as well, which is a common complaint on other platforms. At least on this platform, I am pleasantly surprised at the quality compared to native apps. I hope it improves on other platforms if there are issues there.
The general problem is that there are some APIs which work differently enough between platforms that they leak sufficiently that it makes a difference above the stuff they're supposed to abstract. The browser is [sadly] as close as we've been in recent history to having APIs which mostly work across platforms by leveraging the browser (which is consequently made by the OS developers on mobile OSes) for abstraction over OS stuff. Combined with how "everything is in the cloud" and the decline of the importance of stuff like local file management for average users (now you can lose all your stuff in GDrive just as easily), it's becoming a good-enough choice for making software that works on whatever thing people try to run it on.
Java on a phone is nothing new, but the Java for Symbian you'd write probably wouldn't work very well on a desktop. VC++ for Windows Mobile apps wouldn't work well on a desktop either. The web is the lowest common target, even though it's quite a high level to target. We still run into plenty of HCI issues (why is there a big fat + button in the lower-right on my laptop in GDocs instead of "New" or File -> New action? Because Material is mobile-first and applied thoughtlessly to non-touch experiences), but if you play your cards right, it's now possible to have a codebase, and truly the same app, running on whatever OS and architecture the user has, without specifically building and packaging for 30 different target combinations.
Java on a phone is nothing new, but the Java for Symbian you'd write probably wouldn't work very well on a desktop. VC++ for Windows Mobile apps wouldn't work well on a desktop either. The web is the lowest common target, even though it's quite a high level to target. We still run into plenty of HCI issues (why is there a big fat + button in the lower-right on my laptop in GDocs instead of "New" or File -> New action? Because Material is mobile-first and applied thoughtlessly to non-touch experiences), but if you play your cards right, it's now possible to have a codebase, and truly the same app, running on whatever OS and architecture the user has, without specifically building and packaging for 30 different target combinations.
There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
I feel the same way about Jupyter. Sure it's very clever to run it in a browser but it is clunky as hell compared to native RStudio (free) or MathCAD (commercial).
I feel the same way about Jupyter. Sure it's very clever to run it in a browser but it is clunky as hell compared to native RStudio (free) or MathCAD (commercial).
> The best product that can be made will never be made with cross-platform tooling.
Never is a pretty strong word. Have you tried some of the apps on the site pwa.rocks? Flipboard and AliExpress are non-trivial examples of PWAs that do a good job. Who knows what app development will be like in 5-10 years?
As a developer I would much prefer a cross-platform way to write apps.
Have you looked into the web components spec yet? I think a combination of PWAs + Polymer (or React with web components) has a pretty good shot at easing cross platform development. It already has the support of most browser vendors and is relatively easy to pick up.
Never is a pretty strong word. Have you tried some of the apps on the site pwa.rocks? Flipboard and AliExpress are non-trivial examples of PWAs that do a good job. Who knows what app development will be like in 5-10 years?
As a developer I would much prefer a cross-platform way to write apps.
Have you looked into the web components spec yet? I think a combination of PWAs + Polymer (or React with web components) has a pretty good shot at easing cross platform development. It already has the support of most browser vendors and is relatively easy to pick up.
> My proof for this? Java programs. TCL programs. Electron programs.
Do you feel the same way with QT?
There's a reason all of those you cited failed. That reason is not "a cross platform environment can not be good".
Do you feel the same way with QT?
There's a reason all of those you cited failed. That reason is not "a cross platform environment can not be good".
Do you feel the same way with QT?
Yes!
Qt is a nice library, and was almost certainly the right choice for an open-source application like Wireshark that had previously used the execrable GTK lib on non-X11 platforms, but Qt tries really hard to make water not wet in MANY cases.
Just look at what it takes to get a Mac Qt application to work well in full-screen mode on multiple monitors. Or handling keyboard-focus changes when a notification window pops up (especially one for iMessages). Or any number of things where the underlying platform libs on Windows, MacOS, and X11 differ significantly.
People who've only programmed web applications don't understand how weird platform GUI libraries are or how many corner-cases they have, especially when dealing with multi-window applications, keyboard focus changes, and notification & tool windows. Programming an application to this stuff is tricky - wrapping it in a cross-platform lib is nearly impossible!
Qt exactly proves the point that cross-platform libraries will NEVER give you the same high-quality experience that native applications written to the platform libs will.
Yes!
Qt is a nice library, and was almost certainly the right choice for an open-source application like Wireshark that had previously used the execrable GTK lib on non-X11 platforms, but Qt tries really hard to make water not wet in MANY cases.
Just look at what it takes to get a Mac Qt application to work well in full-screen mode on multiple monitors. Or handling keyboard-focus changes when a notification window pops up (especially one for iMessages). Or any number of things where the underlying platform libs on Windows, MacOS, and X11 differ significantly.
People who've only programmed web applications don't understand how weird platform GUI libraries are or how many corner-cases they have, especially when dealing with multi-window applications, keyboard focus changes, and notification & tool windows. Programming an application to this stuff is tricky - wrapping it in a cross-platform lib is nearly impossible!
Qt exactly proves the point that cross-platform libraries will NEVER give you the same high-quality experience that native applications written to the platform libs will.
Qt is better than the other toolkits in your quote, but on macOS, Qt apps still feel somewhat out of place and inferior to true native apps.
Would be interested in the reason. Haven't seen a good Electron program yet. Slack is just painfully slow.
I don't know the reason. I just know enough to discard the "portable applications must be bad" hypothesis.
If I'd have to guess, I'd say that all of your examples sucked in different ways and it is not a general trend.
If I'd have to guess, I'd say that all of your examples sucked in different ways and it is not a general trend.
Three common ways of sucking, I find, about cross-platform apps is that they are often slower, more resource heavy and "a bad citizen" on the platform. Not all cross-platform apps falls under any one or all of those things, but many does, in my experience, and those that don't always suck in another way.
The best I've worked with has been platform independent business logic in C++, with a thin platform-dependent UI layer. This works across mobile and desktop. C++ has the benefit of being callable on all major mobile and desktop platforms.
That way, the bulk of your team maintains the business logic, and you can get away with much smaller teams for the platform-specific bits.
That way, the bulk of your team maintains the business logic, and you can get away with much smaller teams for the platform-specific bits.
> The best product that can be made will never be made with cross-platform tooling
True or not, this is only relevant if it's indubitable that every app has to be 'the best product that can be made' in terms of platform-centric gold-plated polish. But it's not. Values often clash and tradeoffs are made. For some apps I would prioritise cross-platform availability far above platform polish. For others the converse is true. Some products don't merit the effort or expense of being 'the best product that can be made'. Others do.
True or not, this is only relevant if it's indubitable that every app has to be 'the best product that can be made' in terms of platform-centric gold-plated polish. But it's not. Values often clash and tradeoffs are made. For some apps I would prioritise cross-platform availability far above platform polish. For others the converse is true. Some products don't merit the effort or expense of being 'the best product that can be made'. Others do.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[deleted]
This hits the nail right on he head. I can see developers wanting to have one codebase, but as a user I want apps that can take advantage of everything iOS offers. There is no Picture-in-picture or metal in PWA.
> I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
I wonder how much of that is an intrinsic problem with web apps conceptually, or a result of the various limitations and design fuck-ups of the browser vendors.
I wonder how much of that is an intrinsic problem with web apps conceptually, or a result of the various limitations and design fuck-ups of the browser vendors.
The fuck-ups aren't just on the browser vendor site.
The entire front-end ecosystem is currently worse than enterprise Java at its peak and the quality issues stem from all sides.
The entire front-end ecosystem is currently worse than enterprise Java at its peak and the quality issues stem from all sides.
The best web app I use daily is Slack (wrapped in its native app "shell" on macOS). But it still feels pretty poor.
On iPad it's worse. On iPhone strangely, it's not too bad.
On iPad it's worse. On iPhone strangely, it's not too bad.
If slack is the best, it really goes to show why nobody should be making non-native apps. Slacks Mac client (and their iOS client) is really, really bad.
> 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.
How many details does an app that doesn't get written have compared to a website?
> I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
There are a lot of websites I like using. There are very few apps I like using so much I want to install.
How many details does an app that doesn't get written have compared to a website?
> I have yet to find a "web app" that I delight in using, though I love many web sites and native apps.
There are a lot of websites I like using. There are very few apps I like using so much I want to install.
You can't get pixel-perfect (including android) between all devices, but to the extent that a manufacturer enables a "better" experience, it gets much closer and more consistent behaviour compared to native apps:
https://webkit.org/blog/3709/using-the-system-font-in-web-co...
...and even if you get pixel-perfect between android and ios, you sacrifice "cultural-correctness" (ie: floating buttons v. top bar v. bottom bar, etc.).
Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself.
Making a PWA which gets 90% of the way there, and integrates as well as possible with the system (ie: fonts, location, notifications, accelerometer, etc.) is generally _less_ expensive than doing a single native app well, and has the chance to get you 90% of the way there on desktop and your "alternate" mobile platform.
PWA can be incredibly powerful (along w/ manifest.json-style support as android has), and I'm waiting for the day apple catches up to android on this one.
https://webkit.org/blog/3709/using-the-system-font-in-web-co...
...and even if you get pixel-perfect between android and ios, you sacrifice "cultural-correctness" (ie: floating buttons v. top bar v. bottom bar, etc.).
Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself.
Making a PWA which gets 90% of the way there, and integrates as well as possible with the system (ie: fonts, location, notifications, accelerometer, etc.) is generally _less_ expensive than doing a single native app well, and has the chance to get you 90% of the way there on desktop and your "alternate" mobile platform.
PWA can be incredibly powerful (along w/ manifest.json-style support as android has), and I'm waiting for the day apple catches up to android on this one.
"and even if you get pixel-perfect between android and ios"
Nobody but designers who think too highly of themselves wants this. Everyone else wants the app to fit in with the platforms toolkit. This requires the designs to be different.
"Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself."
Which is why I don't do it the way you described. I embrace what makes each platform unique.
Nobody but designers who think too highly of themselves wants this. Everyone else wants the app to fit in with the platforms toolkit. This requires the designs to be different.
"Writing two pixel+cultural perfect apps on two platforms, keeping them in sync, making sure they're not buggy, attempting to share code, attempting to keep them both secure is incredibly expensive. If you don't believe me then do it yourself."
Which is why I don't do it the way you described. I embrace what makes each platform unique.
I think PWAs are fine. I just wouldn't encourage them to be used side-by-side with native apps (e.g., deploying them to the home screen). It creates the expectation that they should culturally fit in with native apps, and they won't.
I'm okay with them living in the browser and gaining the performance advantages, offline support and push notifications.
I'm okay with them living in the browser and gaining the performance advantages, offline support and push notifications.
Theres something about this comment that winds me up but I don't have the time to unravel.
> 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).
All these things the browser should be able to do well, if they wanted.
> 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).
All these things the browser should be able to do well, if they wanted.
Given that web apps still fail to do drag-and-drop (and copy and paste) as nicely as native apps — and these things have been a staple of Mac interaction since forever — I do not hold out much hope.
Well yeah, it's "if they wanted". Apple has the same incentive to not turn Safari into a viable app platform that Microsoft had with IE in the 90's.
Maybe because they don't believe it's the best route to go for them and their users? I'm inclined to agree, although I'd like to see the open web succeed, but I will weep if I have to use web apps instead of native apps for anything that couldn't be a website.
But they don’t.
> But as an iOS user I expect you to use the technology stack provided by my preferred operating system.
As an iOS user I don't expect Apple to mandate your preferences for me
> 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.
They are more important to you. They may not be to me if they prevent an app I need being made, or being available cross-platform (much more important to me than it being perfect on any one), or being affordable (to me).
The notion that every app must be the perfect gold-plated 'delightful' experience is corporate marketing drivel. It is relevant to some (people and apps), but not others. We don't need the personal tastes of some precious souls to be mandated for all of us by the platforms we happen to use (today).
As an iOS user I don't expect Apple to mandate your preferences for me
> 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.
They are more important to you. They may not be to me if they prevent an app I need being made, or being available cross-platform (much more important to me than it being perfect on any one), or being affordable (to me).
The notion that every app must be the perfect gold-plated 'delightful' experience is corporate marketing drivel. It is relevant to some (people and apps), but not others. We don't need the personal tastes of some precious souls to be mandated for all of us by the platforms we happen to use (today).
I disagree that it's marketing drivel. Wanting everything to be consistent is the entire reason I was driven to the Mac as a platform in the first place many years ago.
Being on a platform where users and developers care about exactly what shade of grey their menu bar icon was, or matching the platform characteristics, adopting system-wide services, making apps accessible, is very important to me.
You may not care, but that's how I choose a platform. It's not marketing, it's personal preference.
I'm going to push for iOS and macOS to develop in this direction by supporting developers who try their very best to make thoughtful and consistent software.
Your argument works against yourself: "cheap cross-platform apps are relevant to some, but we don't need the personal tastes of some precious souls to be mandated for all of us." (I'm not making this argument against you, but try to see how cross-platform is your own personal preference that you are trying to push onto others. In my opinion it degrades a platform even if you don't use any cross-platform apps.)
Being on a platform where users and developers care about exactly what shade of grey their menu bar icon was, or matching the platform characteristics, adopting system-wide services, making apps accessible, is very important to me.
You may not care, but that's how I choose a platform. It's not marketing, it's personal preference.
I'm going to push for iOS and macOS to develop in this direction by supporting developers who try their very best to make thoughtful and consistent software.
Your argument works against yourself: "cheap cross-platform apps are relevant to some, but we don't need the personal tastes of some precious souls to be mandated for all of us." (I'm not making this argument against you, but try to see how cross-platform is your own personal preference that you are trying to push onto others. In my opinion it degrades a platform even if you don't use any cross-platform apps.)
Could not agree more. How does a PWA use ARKit? How does a PWA integrate with the camera? How about the accelerometer? What about iCloud, Handoff, or any number of iOS technologies? Perhaps Metal or other iOS graphics technology? What about TouchId? Bluetooth?
I also find the comment about needing to learn a new stack “React Native and Xcode” to be ridiculous– no, what needs to be learned is Swift and Xcode.
Far too many “web” developers consider native mobile to be some kind of subset of web development and thus expect to use the same tools as they use for web.
Web is a different medium! If you want to program embedded systems, then the first question isn’t “how can I do this with JavaScript?” They would learn the correct language for the platform, perhaps embedded C. You don’t launch a Linux server and then ask “how can I make this server run Windows? I guess I should write a JavaScript library for that!” It’s ludicrous.
With iOS, developers often just think of it as a “native” website rather than an actual application. It seems like some developers will do everything possible to avoid simply learning Swift and making actual apps that fully exploit the power of the device.
React Native – if that is considered “good” then we have major problems. Facebook applications are horrible at power management; they suck power at phenomenal rates compared to other applications. The smoothness of the UI isn’t as “native” as actual Swift apps coded correctly. There always seem to be a slight amount of glitch in the experience. Facebook has famously avoid actually coding real native apps – from the beginning of their mobile experience they have seemingly embraced doing everything except writing actual Swift or Objective C. It is almost a religious opposition to it – and despite being a multi-billion dollar company, some tiny app studio in Poland could write higher quality apps. It should be an embarrassment, but they’re Facebook so everyone just accepts the status quo of less than perfect. No person here can say that the Facebook apps are perfect. But they should be. They have a gazillion dollars and can hire almost anyone they want, so they have no excuse for anything less than perfection. At the very least get power management right!
There’s always this argument that x-Native is “good enough” – if, as a company you want “good enough,” then keep making apps that conform to the lowest common denominator. If you want to make extraordinary applications that move the needle of quality, then use Swift and build it correctly.
This will likely get downvoted into oblivion because the HN crowd seems to be exhaustingly enamored with React Native, however, regardless of how it’s framed, writing PWAs or using some cross-platform “solution” is a cop-out. It’s lazy and it provides users with an experience that is worse than they deserve.
iOS is better than Android in so many ways, yet developers insist on making iOS apps that are really just cross-platform compromises.
My tiny bootstrapped company is working to release our iOS app, with Android soon to follow – if we can do it, there seems little excuse for actual funded companies to skimp on providing the best experience for users. Those arguing that PWA or x-Native cross platform systems are just as good as actual native, well there is no amount of argument that will change your minds. Which is sad. Rather than trying to make React Native, etc. “better” why not just use what is already better? Why not let users enjoy the full power of their devices instead of writing these average “good enough” compromises. It’s like this ridiculous trend of using Electron or, in the past Adobe Air. Nowhere near the quality of writing an actual native app. Looking at you Slack. Slack is even proud to have made a “native app with web technologies.” WHY? Damnit make a native app with native technologies! Can you not hire two actual MacOS developers? Why should making Electron apps be celebrated? It’s sloppy. It’s lazy. It’s a disservice to users. Why use some Electron-wrapped webpage and just not the webpage?
Every day it seems on HN people are posting about <some language> but very few posts about Swift. Is there some opposition that I am missing? Why must JavaScript be the language of everything? what ever happened to picking the right language for the job rather than trying to force a web peg into a native hole.
By the way, my exact arguments could be made for Android development as well. Android users are also being short-changed by these pseudo-native cross platform “solutions.”
I also find the comment about needing to learn a new stack “React Native and Xcode” to be ridiculous– no, what needs to be learned is Swift and Xcode.
Far too many “web” developers consider native mobile to be some kind of subset of web development and thus expect to use the same tools as they use for web.
Web is a different medium! If you want to program embedded systems, then the first question isn’t “how can I do this with JavaScript?” They would learn the correct language for the platform, perhaps embedded C. You don’t launch a Linux server and then ask “how can I make this server run Windows? I guess I should write a JavaScript library for that!” It’s ludicrous.
With iOS, developers often just think of it as a “native” website rather than an actual application. It seems like some developers will do everything possible to avoid simply learning Swift and making actual apps that fully exploit the power of the device.
React Native – if that is considered “good” then we have major problems. Facebook applications are horrible at power management; they suck power at phenomenal rates compared to other applications. The smoothness of the UI isn’t as “native” as actual Swift apps coded correctly. There always seem to be a slight amount of glitch in the experience. Facebook has famously avoid actually coding real native apps – from the beginning of their mobile experience they have seemingly embraced doing everything except writing actual Swift or Objective C. It is almost a religious opposition to it – and despite being a multi-billion dollar company, some tiny app studio in Poland could write higher quality apps. It should be an embarrassment, but they’re Facebook so everyone just accepts the status quo of less than perfect. No person here can say that the Facebook apps are perfect. But they should be. They have a gazillion dollars and can hire almost anyone they want, so they have no excuse for anything less than perfection. At the very least get power management right!
There’s always this argument that x-Native is “good enough” – if, as a company you want “good enough,” then keep making apps that conform to the lowest common denominator. If you want to make extraordinary applications that move the needle of quality, then use Swift and build it correctly.
This will likely get downvoted into oblivion because the HN crowd seems to be exhaustingly enamored with React Native, however, regardless of how it’s framed, writing PWAs or using some cross-platform “solution” is a cop-out. It’s lazy and it provides users with an experience that is worse than they deserve.
iOS is better than Android in so many ways, yet developers insist on making iOS apps that are really just cross-platform compromises.
My tiny bootstrapped company is working to release our iOS app, with Android soon to follow – if we can do it, there seems little excuse for actual funded companies to skimp on providing the best experience for users. Those arguing that PWA or x-Native cross platform systems are just as good as actual native, well there is no amount of argument that will change your minds. Which is sad. Rather than trying to make React Native, etc. “better” why not just use what is already better? Why not let users enjoy the full power of their devices instead of writing these average “good enough” compromises. It’s like this ridiculous trend of using Electron or, in the past Adobe Air. Nowhere near the quality of writing an actual native app. Looking at you Slack. Slack is even proud to have made a “native app with web technologies.” WHY? Damnit make a native app with native technologies! Can you not hire two actual MacOS developers? Why should making Electron apps be celebrated? It’s sloppy. It’s lazy. It’s a disservice to users. Why use some Electron-wrapped webpage and just not the webpage?
Every day it seems on HN people are posting about <some language> but very few posts about Swift. Is there some opposition that I am missing? Why must JavaScript be the language of everything? what ever happened to picking the right language for the job rather than trying to force a web peg into a native hole.
By the way, my exact arguments could be made for Android development as well. Android users are also being short-changed by these pseudo-native cross platform “solutions.”
Yep. There are also, as I'm sure you're aware but for the benefit of the less-familiar, plenty of "hybrid" ways to build "native" apps for mobile: https://github.com/auth0/blog/blob/master/_posts/2017-01-11-...
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 after over 30 years of experiencing cross platform "write once run anywhere* technologies do developers still think that's the best user experience? Yes it makes life easier for the developer but it's rarely best for the user.
Why after over 30 years of experiencing cross platform "write once run anywhere* technologies do developers still think that's the best user experience? Yes it makes life easier for the developer but it's rarely best for the user.
I think this is the crux of the matter. Apple supporting PWA means lower quality apps for its users, and Apple has the market share to demand apps be native code.
I'm not trying to argue that it is the BEST user experience. I'm trying to say that it is hurting small dev shops and startups because they are being forced to learn a completely new tech stack in order to play ball. I could have spent that time implementing new features that users would actually use and in turn improve their business, or in this case, reach and help more people with valuable medical advice.
In the end, Apple got what they wanted. I needed a feature that PWA's can give me - but Apple hasn't added support for them in mobile safari, so I paid the $100 to get access to the app store, and was forced to learn a completely different language.
Yes, the end product has an arguably better and 'native-like' experience, but it took me longer to do and it is lacking some of the features that I could have rolled out if I was able to use PWA's. And it would have worked on Android out of the box as well.
I don't regret learning React Native. It was actually really, really fun. The community is great, and being able to write native apps now feels really good.
But its the principal of the matter. Holding back innovation for your company's own selfish reasons is a shitty thing to do.
In the end, Apple got what they wanted. I needed a feature that PWA's can give me - but Apple hasn't added support for them in mobile safari, so I paid the $100 to get access to the app store, and was forced to learn a completely different language.
Yes, the end product has an arguably better and 'native-like' experience, but it took me longer to do and it is lacking some of the features that I could have rolled out if I was able to use PWA's. And it would have worked on Android out of the box as well.
I don't regret learning React Native. It was actually really, really fun. The community is great, and being able to write native apps now feels really good.
But its the principal of the matter. Holding back innovation for your company's own selfish reasons is a shitty thing to do.
Yes, the end product has an arguably better and 'native-like' experience, but it took me longer to do and it is lacking some of the features that I could have rolled out if I was able to use PWA's. And it would have worked on Android out of the box as well.
So am I as an end user suppose to be upset that you were forced to make a better product.
Holding back innovation for the company's selfish reasons?
Back in 2008 they said the same thing about Apple not supporting Flash and Java.
If anyone is being selfish to try foist cross platform apps that you admitted weren't as good, it isn't Apple.
So am I as an end user suppose to be upset that you were forced to make a better product.
Holding back innovation for the company's selfish reasons?
Back in 2008 they said the same thing about Apple not supporting Flash and Java.
If anyone is being selfish to try foist cross platform apps that you admitted weren't as good, it isn't Apple.
GMail was (and maybe keeps being) a much better user experience than native email clients for desktop PCs.
I can’t disagree more. I find gmail to be a perfect example of why web apps are playing to the lowest common denominator and result in poor user experiences everywhere. Just my opinion though, I realise most people love it.
What feature of native apps do you wish web-GMail had?
I'm on a Mac and mostly come from Mail.app, but many of these things would apply on Windows/Linux as well in slightly different forms.
- Speed. It's sluggish compared to the FastMail web UI, and slow compared to Mail.app on my Mac.
- System provided UI editing controls which would bring richer editing and consistent controls
- Consistent hotkeys - I know Gmail has rich hotkeys, but all my other software uses a fairly consistent set which can also access a wider range of keys than a browser can do.
- Automation - I use automation and tools like Alfred (/Quicksilver/Gnome Do/etc) and these can interface with native apps much more effectively through things like AppleScript.
- Drag and drop (you can drag and drop much more than you might think on a Mac, and I use it extensively)
- Centralised notification control in system preferences
- Better (and faster) layout – you're constrained to a web browser so there's less you can do in terms of good use of screen real-estate.
- Prettier – it might sound superficial, but I enjoy using apps that have a nicer design and Gmail, compared with many native clients, looks pretty terrible.
- Real multi-window support - using new tabs doesn't provide the same interface or interaction patterns.
- Real right-click support, with the options I'd expect for any other system app.
That's most of what I'd like to see. Note that an Electron app like Slack doesn't exhibit many of these.
- Speed. It's sluggish compared to the FastMail web UI, and slow compared to Mail.app on my Mac.
- System provided UI editing controls which would bring richer editing and consistent controls
- Consistent hotkeys - I know Gmail has rich hotkeys, but all my other software uses a fairly consistent set which can also access a wider range of keys than a browser can do.
- Automation - I use automation and tools like Alfred (/Quicksilver/Gnome Do/etc) and these can interface with native apps much more effectively through things like AppleScript.
- Drag and drop (you can drag and drop much more than you might think on a Mac, and I use it extensively)
- Centralised notification control in system preferences
- Better (and faster) layout – you're constrained to a web browser so there's less you can do in terms of good use of screen real-estate.
- Prettier – it might sound superficial, but I enjoy using apps that have a nicer design and Gmail, compared with many native clients, looks pretty terrible.
- Real multi-window support - using new tabs doesn't provide the same interface or interaction patterns.
- Real right-click support, with the options I'd expect for any other system app.
That's most of what I'd like to see. Note that an Electron app like Slack doesn't exhibit many of these.
It's better in that it required no configuration. But from a UI perspective it feels inferior. For example, native clients can just show you a list of all your messages, but GMail still paginates like a late-90s PHP site.
Believe it or not, in my experience, Exchange + Outlook 2016 stomps all over GMail. I find that its faster, searches quicker, and takes up _WAY_ less memory. I don't do any fancy things other than basic email, scheduling meetings, etc so YMMV.
Completly disagree.
I only use GMail as gateway to aggregate my email accounts and synchronize with my Android devices, native mail client.
On Windows and GNU/Linux systems at home, I happily keep using Thunderbird.
I only use GMail as gateway to aggregate my email accounts and synchronize with my Android devices, native mail client.
On Windows and GNU/Linux systems at home, I happily keep using Thunderbird.
Without specifics there's not much to discuss.
E.g. Thunderbird apparently only introduced threaded conversations 7 years after GMail did.
E.g. Thunderbird apparently only introduced threaded conversations 7 years after GMail did.
I hate threaded conversations, so that isn't something I even value.
Even if you personally dislike it, I think you can agree that it's one of the UX choices that made it storm over the alternatives at the time.
Not all our individual tastes align with what's most popular, obviously.
Not all our individual tastes align with what's most popular, obviously.
Not really, I guess many jumped on it, because it was a free email server from Google.
I still manage my own email servers.
I still manage my own email servers.
[deleted]
I never quite understood the complaint about having to learn a new tech stack to write native apps. As a native app dev, it feels kind of like getting angry that your skills in motorcycle mechanics don't transfer to building rockets.
And this complaint practically always comes from the front end web crew... every other type of developer I've met has zero issues with learning the technologies relevant to a particular platform.
And this complaint practically always comes from the front end web crew... every other type of developer I've met has zero issues with learning the technologies relevant to a particular platform.
I'm a scientific programmer who just wants to have a few tools available across my devices, mobile as well as desktop.
PWAs are a great idea for me. Getting an Apple developer license is not.
PWAs are a great idea for me. Getting an Apple developer license is not.
Then don't develop for Apple platforms. We don't want your "apps" anyway.
I want them for me and my friends/family on Apple devices.
WebRTC support is arriving soonish so I'm getting what I want despite the downvotes :)
WebRTC support is arriving soonish so I'm getting what I want despite the downvotes :)
You can make a a native app, which will always be better than a webapp. As an iOS user, I have no intention of ever using webapps (including things like Cordova apps). If you can’t be bothered to make a iOS-native app with iOS native look, feel and features then just don’t bother.
But it means learning something other than JS!
It feels like many developers are adamant to never leave their comfort zone. Hence, JS everywhere.
It feels like many developers are adamant to never leave their comfort zone. Hence, JS everywhere.
Coders like to code. Product builders want to build products with a minimum of fuss.
Then they should use other technologies in the first place because web development ecosystem adds too much fuss to the process.
Also product builders usually want to provide good user experiences. You may be saving yourself from some additional code but delivering battery draining solutions with non-native UI patterns and broken accessibility to your users.
Also product builders usually want to provide good user experiences. You may be saving yourself from some additional code but delivering battery draining solutions with non-native UI patterns and broken accessibility to your users.
A native app will never have instant install, or update without download. A native app will never be available on all platforms.
Sometimes a native app is better, sometimes it is worse. It's certainly better if all you care about is fancy animations.
Sometimes a native app is better, sometimes it is worse. It's certainly better if all you care about is fancy animations.
> A native app will never have instant install, or update without download.
So ? Updates happen automatically anyway.
> A native app will never be available on all platforms.
I don’t need it on all platforms, I only use iOS.
So ? Updates happen automatically anyway.
> A native app will never be available on all platforms.
I don’t need it on all platforms, I only use iOS.
Instant install is just a better experience. Going in and out of the App Store is a pointless step.
So because you want to provide a better UX for the one time you install the app, you want to sacrifice the UX of every single time you actually use the app. That makes no sense at all.
I'm not sure what you're referring to. Which UX issues are insurmountable in a web app?
Generally speaking, they can all be worked around by a good designer. The inferior install, update, and cross platform experience for native apps can't be worked around.
Are you talking about like realtime video authoring apps or games? I'll admit in those categories the web is often not the best choice.
Generally speaking, they can all be worked around by a good designer. The inferior install, update, and cross platform experience for native apps can't be worked around.
Are you talking about like realtime video authoring apps or games? I'll admit in those categories the web is often not the best choice.
> I'm not sure what you're referring to. Which UX issues are insurmountable in a web app?
You can get close to the look & feel of native app, but you can never get there.
You can get close to the look & feel of native app, but you can never get there.
Is anyone demanding instant install or updates ?
I can download 95% of apps in under 30 seconds and all of my apps update whilst I am sleeping. And nothing is stopping you downloading new content in a native app which is where the majority of use cases stem from.
I can download 95% of apps in under 30 seconds and all of my apps update whilst I am sleeping. And nothing is stopping you downloading new content in a native app which is where the majority of use cases stem from.
No one will demand it. You're just giving your users a worse experience. App store developers are people who have given up on speed. Y'all think a 30 second delay between screens with several pointless clicks is an acceptable user experience. It's sad.
As an iOS user, do you ever use websites that are more than plain hypertext, even if they don't try to have an iOS native look?
A website is not an app. Not sure why I need to explain that.
Sure they are. Web sites are a subset of apps.
No they aren’t. Websites are a subset of documents, not apps.
C++ files are documents too.
You're using one right now as a forum, to communicate your thoughts.
Because some websites like forums, email clients, chats, calendars, stores, etc. are definitely applications, even though they're still websites and not native apps.
I think for most people, the answer is a resounding yes.
> 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.
If 'a single codebase of open technologies' is so important then the same argument says Apple should abandon their platforms in favor of linux/AOSP. I'm sure a number of people here believe that (and strongly) but ... (1) Apple has a few hundred billion counterarguments sitting in the bank and (2) the entire industry has greatly benefited from Apple's efforts at pushing their closed platforms.
And if 'a single codebase of open technologies' isn't the be all end all then the argument reduces to "Apple should subsidize the technology I'm invested in". I bet turnip farmers think Apple should buy lots of turnips too.
If 'a single codebase of open technologies' is so important then the same argument says Apple should abandon their platforms in favor of linux/AOSP. I'm sure a number of people here believe that (and strongly) but ... (1) Apple has a few hundred billion counterarguments sitting in the bank and (2) the entire industry has greatly benefited from Apple's efforts at pushing their closed platforms.
And if 'a single codebase of open technologies' isn't the be all end all then the argument reduces to "Apple should subsidize the technology I'm invested in". I bet turnip farmers think Apple should buy lots of turnips too.
Reverse the discussion:
I'm a C and C++ programmer with a background in embedded systems. My idea of a development framework is a Makefile, a bunch of headers and .a files. I've got an investment in a lot of libraries I've already written over the years. I want to develop great web applications. Should I feel frustrated that it's not straightforward to use my preferred toolset to build this web app? Should I blame browsers for not accommodating my development preferences? No! I need to bite the bullet and learn JS and HTML.
You need to pick the appropriate tools for the platform you're targeting, get out of your comfort zone and take the time to learn them.
I'm a C and C++ programmer with a background in embedded systems. My idea of a development framework is a Makefile, a bunch of headers and .a files. I've got an investment in a lot of libraries I've already written over the years. I want to develop great web applications. Should I feel frustrated that it's not straightforward to use my preferred toolset to build this web app? Should I blame browsers for not accommodating my development preferences? No! I need to bite the bullet and learn JS and HTML.
You need to pick the appropriate tools for the platform you're targeting, get out of your comfort zone and take the time to learn them.
Could always apply to OkCupid. They, crazily enough, build their website with C++.
> Apple supporting PWA is hugely important because it enables a future where web apps can natively support (...)
But it is not in Apple's interest to support these kinds of apps. They make money on the app store, and like to keep developers within the walls of their ecosystem.
But it is not in Apple's interest to support these kinds of apps. They make money on the app store, and like to keep developers within the walls of their ecosystem.
You can definitely build that contacts app as a web app on mobile safari. HTML5 appcache lets you take it offline, localstorage gives you 5 mb of storage, web sql or indexeddb gives you 50 mb. You can use something like pouchdb to give you a clean wrapper.
Yes, service workers would be nicer, but you don't have to go native to do an offline app on iOS. I built one years ago, appcache is good enough.
Yes, service workers would be nicer, but you don't have to go native to do an offline app on iOS. I built one years ago, appcache is good enough.
What are you storing in your contacts database that's so huge that it can't be loaded over the network every time?
Are you hand-writing notes and storing the notes as images?
I use Apple/Google's built-in notes fields on the default addressbooks and it works just fine. I can't imagine having huge write-ups on individual contacts unless it was for some business purpose. In that case, I'd move to a dedicated note-taking application anyway.
Are you hand-writing notes and storing the notes as images?
I use Apple/Google's built-in notes fields on the default addressbooks and it works just fine. I can't imagine having huge write-ups on individual contacts unless it was for some business purpose. In that case, I'd move to a dedicated note-taking application anyway.
He is probably concerned about users who cannot use a network all the time or have slow connections. Many phones have LTE but trying to load some modern websites over slower 4G, or even slower 3G, is a nightmare, not just from the size but also if they're not on a proper CDN.
Maybe developers should focus on the subset of platforms that they know they can deliver a first rate experience on, instead of forcing support for every platform imaginable.
It's a sad state of affairs for the web when we see articles claiming that one company's failure to adopt a standard amounts to threatening the web. The open web supports and should encourage competition, not blind homogeny.
I don't think it's misguided for a company to hesitate in supporting a platform which will enable its users to jump ship to another competing company.
It's a sad state of affairs for the web when we see articles claiming that one company's failure to adopt a standard amounts to threatening the web. The open web supports and should encourage competition, not blind homogeny.
I don't think it's misguided for a company to hesitate in supporting a platform which will enable its users to jump ship to another competing company.
> This is unnecessary duplication of work that could've been spent writing new features
I bet that's how Apple feels about implementing PWA.
I bet that's how Apple feels about implementing PWA.
So put your web app in a Cordova bundle and you can send push notifications. No need to learn react or write native code. Not a huge problem to solve.
Thank you Christian. This is what I was trying to say. I think I could have better job at making my point more clearly. But you got it.
> 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
It's not the only way - you can create a hybrid app with something like Ionic (obviously this is compiled to a native app at build time, but you never touch a line of XCode yourself).
One of the big selling points of hybrid apps is that you can use your existing Javascript/Typescript skills to create apps that look and feel like native apps.
It's not the only way - you can create a hybrid app with something like Ionic (obviously this is compiled to a native app at build time, but you never touch a line of XCode yourself).
One of the big selling points of hybrid apps is that you can use your existing Javascript/Typescript skills to create apps that look and feel like native apps.
Downvoter care to comment? Seems a bit random.
It seems like at some point we're just going to end up re-writing Java - But for the web.
"By fragmenting development effort, the overall product isn't as good on any platform."
At the same time, you're no longer focusing on what makes each platform unique, and just giving them all a lowest common denominator. That's not really good either.
"This means I had to learn an entirely new technology stack"
Learning new things is good.
"Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff."
This is absolutely wrong, and is just an excuse. You can make great stuff, and people can use it. You just need to put in effort.
At the same time, you're no longer focusing on what makes each platform unique, and just giving them all a lowest common denominator. That's not really good either.
"This means I had to learn an entirely new technology stack"
Learning new things is good.
"Until Apple adds PWA support, I can't make as good stuff, and people can't use the better stuff."
This is absolutely wrong, and is just an excuse. You can make great stuff, and people can use it. You just need to put in effort.
Screw new features, using JavaScript and HTML/CSS for apps must die.
The DOM and CSS are good underlying principles. It would be nice if there was an alternative to HTML, like something encoded in JSON.
As to JavaScript, with WebAssembly coming, there may be options in the future.
As to JavaScript, with WebAssembly coming, there may be options in the future.
> something encoded in JSON
Those who do not learn the lessons from XML are doomed to repeat XML.
The DOM is simply an in-memory representation of an XML structure, and any attempts to populate a DOM with JSON (or YAML or ProtoBuffers or...) will simply re-create XML. CSS is a language for writing XML transformations (i.e. XSLT).
Of course, we already have JSON versions of schemas, transformations, xpath, namespaces, and incompatible decoders, so perhaps it is already too late for JSON.
Those who do not learn the lessons from XML are doomed to repeat XML.
The DOM is simply an in-memory representation of an XML structure, and any attempts to populate a DOM with JSON (or YAML or ProtoBuffers or...) will simply re-create XML. CSS is a language for writing XML transformations (i.e. XSLT).
Of course, we already have JSON versions of schemas, transformations, xpath, namespaces, and incompatible decoders, so perhaps it is already too late for JSON.
Honestly, we could have a cleaner XML. There's plenty of cruft there, the language could be easier to parse and navigate. We could also have a cleaner XSLT while keeping it's completeness.
We could have a better DOM too. It could be more semantic, and more modular. The good thing is that on this one we are moving in the right direction.
CSS would gain by becoming Turing complete. It also could be aware of runtime values.
But yes, JSON, YAML, and ProtoBuffers are all worsened versions of it. The good news is that we abandoned SOAP, but at the cost of abandoning service directories too.
We could have a better DOM too. It could be more semantic, and more modular. The good thing is that on this one we are moving in the right direction.
CSS would gain by becoming Turing complete. It also could be aware of runtime values.
But yes, JSON, YAML, and ProtoBuffers are all worsened versions of it. The good news is that we abandoned SOAP, but at the cost of abandoning service directories too.
Flow-oriented markup is meant for documents not GUI.
Very much agree with this.
Having developed many websites and many apps, HTML and CSS are really quite terrible when compared to something like iOS' auto-layout system, or even something like a DockPanel in Xaml (WPF on windows)
However, you wouldn't want to layout a document in Xaml or auto-layout either. Different strengths for different original purposes.
Personally I feel like a non-trivial part of why "web apps" (i.e websites pretending to be apps) generally suck comes down to this impedance mismatch
Having developed many websites and many apps, HTML and CSS are really quite terrible when compared to something like iOS' auto-layout system, or even something like a DockPanel in Xaml (WPF on windows)
However, you wouldn't want to layout a document in Xaml or auto-layout either. Different strengths for different original purposes.
Personally I feel like a non-trivial part of why "web apps" (i.e websites pretending to be apps) generally suck comes down to this impedance mismatch
I think it's also about the tooling.
With most "native" platforms you can have a WYSIWYG UI editing (because those markup languages were designed with that in mind). You visually define the layout (with mouse/trackpad), drop components there, and it's all nice and easy to use. Surely, you can code your UI as well, but to best of my knowledge no one in their sane mind does this, unless they have some very good reasons.
With web apps (progressive or not), the usual approach is to code stuff by hand, and see the results in the synchronized preview pane (or nearby browser window), patching the code until it all fits. Even if there's some tool/IDE somewhere that would let me bootstrap a React/React Native/Elm/whatever app with a mouse - by dropping a button on a pane and connecting an event listener with another mouse click (like I had it in Delphi, 15 years ago), I think it would be an exception, not a rule.
Or maybe I'm just unaware about how things are really done and have false beliefs, heh.
With most "native" platforms you can have a WYSIWYG UI editing (because those markup languages were designed with that in mind). You visually define the layout (with mouse/trackpad), drop components there, and it's all nice and easy to use. Surely, you can code your UI as well, but to best of my knowledge no one in their sane mind does this, unless they have some very good reasons.
With web apps (progressive or not), the usual approach is to code stuff by hand, and see the results in the synchronized preview pane (or nearby browser window), patching the code until it all fits. Even if there's some tool/IDE somewhere that would let me bootstrap a React/React Native/Elm/whatever app with a mouse - by dropping a button on a pane and connecting an event listener with another mouse click (like I had it in Delphi, 15 years ago), I think it would be an exception, not a rule.
Or maybe I'm just unaware about how things are really done and have false beliefs, heh.
The problem appears when there is only one kind of flow. Otherwise, flow-oriented markup is quite good.
Safari engineers have attended all service worker working group meetings, and they do contribute. However, I do share the frustrations over transparency.
It's tough to get developers to care about things like offline-first, because it's tough for them to convince managers to allow them to spend time on a feature that won't work on iOS (since it won't work in Safari, and Apple has banned other browser engines on their platform).
Ultimately it's users that lose out but also the web as a platform, as it pushes people, like the author of the article, towards walled-garden solutions like native apps.
Apple is looking for service worker use-cases, so if it's something you're interested in, let them know https://lists.webkit.org/pipermail/webkit-dev/2017-July/0292....
It's tough to get developers to care about things like offline-first, because it's tough for them to convince managers to allow them to spend time on a feature that won't work on iOS (since it won't work in Safari, and Apple has banned other browser engines on their platform).
Ultimately it's users that lose out but also the web as a platform, as it pushes people, like the author of the article, towards walled-garden solutions like native apps.
Apple is looking for service worker use-cases, so if it's something you're interested in, let them know https://lists.webkit.org/pipermail/webkit-dev/2017-July/0292....
This is not surprising of Apple. They've always been a walled garden, that's why I don't buy their products. I like to own products that give me full control as a user.
When the iPod came out, I never understood why I couldn't just drag the music files directly onto the device and I had to get iTunes and use iTune's tedious interface.
Now they have the app store; another unnecessary restriction. As a developer, it's nice to own an Android phone because I can just run whatever code I want on it and I don't need to buy any special licenses, hardware or proprietary SDKs to do that.
When the iPod came out, I never understood why I couldn't just drag the music files directly onto the device and I had to get iTunes and use iTune's tedious interface.
Now they have the app store; another unnecessary restriction. As a developer, it's nice to own an Android phone because I can just run whatever code I want on it and I don't need to buy any special licenses, hardware or proprietary SDKs to do that.
The "walled garden" is what prevents the horrendous disjointed mess that is the Android phone market. Sure, for a guy who likes hacking around stuff, it's fun for you. But for everyone else, there is a thousand different phones, with a thousand different interfaces, all running different versions of the Android OS, that will never be updated by the phone manufacturer.
I understand where you're coming from, I do. But when it comes to a phone, I greatly prefer the standardized hardware/interface/OS over the free for all. I hate to use the "it just works" nonsense, but that is exactly what it does.
Working in the Enterprise, the iPhone is infinitely easier for us to troubleshoot, and manage. Because everyone is running the same thing.
I understand where you're coming from, I do. But when it comes to a phone, I greatly prefer the standardized hardware/interface/OS over the free for all. I hate to use the "it just works" nonsense, but that is exactly what it does.
Working in the Enterprise, the iPhone is infinitely easier for us to troubleshoot, and manage. Because everyone is running the same thing.
The walled garden is not what prevents having multiple manufacturers of phones. Apple could easily tear down their walled garden and let users install whatever software they want on their own phones - and they'd still be the only one manufacturing iPhones.
Your argument seems to indicate that you just like iPhones better. Otherwise, I think you would have said "I'd prefer that our company either standardize on one model of Android phone or the iPhone." because both would have the same effect - things would be easier to troubleshoot and manage since everyone would be running the same thing.
Anyway, currently as an iPhone user I think Apple comes up massively short on basic features. For instance - on an $800 phone they're missing a physical message-waiting indicator light! That's completely absurd to me. Some others: You can't have multiple users (and this is big for the Enterprise). You can't put app icons wherever you want, you have to stick them all together in one big pile on the screen. You can't see the time a text message came in until you perform a non-obvious gesture. You can't see anything useful in the call history list until you click an item. You can't even change the default browser!
It's no wonder to me why Enterprise customers don't standardize on the iPhone - they'd be giving up all control to Apple.
Your argument seems to indicate that you just like iPhones better. Otherwise, I think you would have said "I'd prefer that our company either standardize on one model of Android phone or the iPhone." because both would have the same effect - things would be easier to troubleshoot and manage since everyone would be running the same thing.
Anyway, currently as an iPhone user I think Apple comes up massively short on basic features. For instance - on an $800 phone they're missing a physical message-waiting indicator light! That's completely absurd to me. Some others: You can't have multiple users (and this is big for the Enterprise). You can't put app icons wherever you want, you have to stick them all together in one big pile on the screen. You can't see the time a text message came in until you perform a non-obvious gesture. You can't see anything useful in the call history list until you click an item. You can't even change the default browser!
It's no wonder to me why Enterprise customers don't standardize on the iPhone - they'd be giving up all control to Apple.
> they're missing a physical message-waiting indicator light!
I do use an Android phone on a regular basis, and there it's useful, since it only pops up when important messages arrive (read: on-call stuff).
But my daily driver is an iPhone, and sorry - this would be an absolute mess with the amount of apps installed trying to notify me of things. It's virtually impossible to determine what notifications or messages are important. Is a waze notification that a friend will almost arrive important? Not really. Is a waze notification that I should leave in 10 minutes important since the traffic isn't optimal? Absolutely. Relying on such an indicator simply doesn't work the moment you have dozens and dozens of apps installed that all send you mostly mundane low priority messages, but from time to time want to tell you something you really want to know.
In my case, a light like that would be on all the time or off when you actually have a pretty important notification - which would mean you simply cannot rely on it. Notifications are already too complex, and at the same time too limited. Simplifying it into a colored light is just adding to that mess.
I do use an Android phone on a regular basis, and there it's useful, since it only pops up when important messages arrive (read: on-call stuff).
But my daily driver is an iPhone, and sorry - this would be an absolute mess with the amount of apps installed trying to notify me of things. It's virtually impossible to determine what notifications or messages are important. Is a waze notification that a friend will almost arrive important? Not really. Is a waze notification that I should leave in 10 minutes important since the traffic isn't optimal? Absolutely. Relying on such an indicator simply doesn't work the moment you have dozens and dozens of apps installed that all send you mostly mundane low priority messages, but from time to time want to tell you something you really want to know.
In my case, a light like that would be on all the time or off when you actually have a pretty important notification - which would mean you simply cannot rely on it. Notifications are already too complex, and at the same time too limited. Simplifying it into a colored light is just adding to that mess.
If there was a single manufacturer of Android phones, with the seamless ecosystem that Apple provides. I would absolutely consider their phones. Right now, it's a mess, and the reason Apple is the only alternative.
> The "walled garden" is what prevents the horrendous disjointed mess that is the Android phone market. Sure, for a guy who likes hacking around stuff, it's fun for you. But for everyone else, there is a thousand different phones, with a thousand different interfaces, all running different versions of the Android OS, that will never be updated by the phone manufacturer.
This is a non-sequitur. Fragmentation of Android OS versions isn't caused by Android letting you use web apps.
This is a non-sequitur. Fragmentation of Android OS versions isn't caused by Android letting you use web apps.
I was responding to the first two lines of their comment. If they are going to divert that way, then I'm going to respond to it.
You're not making sense to me. u/jondubois dislikes the walled garden, which is the inability to run apps that don't go through Apple's app store (with the corresponding review and fees).
You respond to those two lines by saying that the walled garden prevents fragmentation.
It does not.
* If you were unable to run apps other than via the Google Play Store in Android phones, the OS versions would still be fragmented. App developers have nothing to do with that.
* If only Google manufactured and updated Android phones (hence no fragmentation), you would still be able to run whatever you wanted in the phone. "Walled garden" doesn't mean "closed source".
You respond to those two lines by saying that the walled garden prevents fragmentation.
It does not.
* If you were unable to run apps other than via the Google Play Store in Android phones, the OS versions would still be fragmented. App developers have nothing to do with that.
* If only Google manufactured and updated Android phones (hence no fragmentation), you would still be able to run whatever you wanted in the phone. "Walled garden" doesn't mean "closed source".
The walled garden absolutely prevents fragmentation.
Apple has on multiple occasions over the years removed apps from the stores that weren't updated to use the latest iOS SDK. This meant that since all apps are targeting the latest iOS there is little impediment to moving the entire platform forward.
Apple has on multiple occasions over the years removed apps from the stores that weren't updated to use the latest iOS SDK. This meant that since all apps are targeting the latest iOS there is little impediment to moving the entire platform forward.
Ah OK, I see that point now. But Android's fragmentation isn't due to the users being unwilling to update, to keeps their apps working. It's because it used to cost a lot to OEMs and carriers to port their drivers etc to the new versions.
[deleted]
I just want to note that as a developer you can run any code you want on your iPhone through XCode for free. You just can't distribute it in the App Store without a license ($100 a year). You can distribute the code though, and users can compile and install it. This is how Kodi distributes on Apple platforms.
This is a newish change though, within the last couple of years.
This is a newish change though, within the last couple of years.
You can run any code you want on your iPhone through XCode for free as long as you have a Mac, which is much more expensive than the app store license.
Many entitlements still require you to buy a certificate from Apple. You cannot, for example, compile and run your own VPN software.
Buy? I've never seen anything to suggest that special entitlements from Apple (KEXT signing on Mac, Network Extension usage on iOS, etc.) requires any payment besides the $100/yr developer program fee
Network Extension doesn't require special entitlement anymore?
Not true.
Please correct me if I'm wrong, but I was under the impression you would then be required to reinstall each app every 7 days. In addition, I've read online claims that they limit you to something like 3 App IDs per week on a personal account.
Doesn't mean you have to reinstall all your apps every week?
Doesn't mean you have to reinstall all your apps every week?
It's especially ironic once you remember that iOS 1 didn't even have apps: Steve said everything would be done on websites that would give a native experience...
Apple knew this wasn't true. They knew there was an public native SDK on the roadmap because web technologies didn't cut it.
The Stocks and Weather app were originally HTML/CSS/JS apps just like Dashboard widgets (note Steve Jobs actually describing these apps on stage as 'widgets'), but the performance just wasn't there so they got reimplented using native apis.
The Stocks and Weather app were originally HTML/CSS/JS apps just like Dashboard widgets (note Steve Jobs actually describing these apps on stage as 'widgets'), but the performance just wasn't there so they got reimplented using native apis.
That's only because he didn't see the opportunity and the ux. Not because he cared about freedom.
So how do you do playlists when you just drag files to folders? What if you wanted the same song in multiple playlists? How do you do smart playlist? All of this is not as popular now as it was during the iPods heyday but it was popular then.
iTunes' UI for creating playlists and letting me add and remove songs from the device by dragging and dropping the files could be perfectly compatible.
[deleted]
What is a M3U file
If you're creating a m3u file you aren't just copying files to the player.
I handle playlist creation on my computer, and clone my entire library onto my phone, my playlist files contain relative paths and its pretty seamless.
And you think that's easier than iTunes was in the heyday of the iPod?
Much easier, my music player handles the playlists. My file manager handles the upload.
iTunes is beyond irritating to use, I've not once fired it up and accomplished what I came to do without at least one google search.
iTunes is beyond irritating to use, I've not once fired it up and accomplished what I came to do without at least one google search.
>When the iPod came out, I never understood why I couldn't just drag the music files directly onto the device and I had to get iTunes and use iTune's tedious interface.
Because MTP is utter rubbish.
Really, people complain about iTunes? It's never failed me as slow as it is. Try using MTP...
Because MTP is utter rubbish.
Really, people complain about iTunes? It's never failed me as slow as it is. Try using MTP...
The iPod mounted as a perfectly-functional Firewire disk, yet you still had to use iTunes to put music on it for it to be playable on the device. (It was filed away in obfuscated filenames...)
USB sticks became popular more than a decade ago, and not once have I had one fail to copy or remove a file by dragging and dropping.
NO one said anything about MTP. Copying files > anything.
Copying files... how? Emulating a FAT32 disk? That sucks. exFAT? Patents. MTP? Sucks. So how?
What's wrong with emulating a FAT32 disk?
I mean, the expected workflow is: I hook up the device to the computer, it shows up as a storage medium in my system. I can move files between the device and my computer as if it was an external disk or USB drive.
Anything on top of that is designed to be annoying.
I mean, the expected workflow is: I hook up the device to the computer, it shows up as a storage medium in my system. I can move files between the device and my computer as if it was an external disk or USB drive.
Anything on top of that is designed to be annoying.
FAT32 is a terribly outdated filesystem and should just not be used today, period. The filesize and name restrictions are awful. Mrkrabo does have a point.
[deleted]
The question about FAT32 was honest; thanks for the explanation. The rest of the comment (presenting storage in a normal, non-surprising way) is separate, and still stands.
Yeah, that's what irks me the most about iOS. Their whole idea of "the filesystem is an outdated concept" just never worked out and they refuse to give up on it. The greatest lie is that your iPad Pro can replace a PC, but you can't easily copy files from and to a flash drive. In the meantime, my wife's Surface accepts USB hardware just fine and she doesn't have to rely on awkward workarounds to get things done.
Ethernet over USB, FTP/SCP/SMB?
They're not looking as much as you think: https://twitter.com/othermaciej/status/885999233463009280
The overall vibes leaking from the Safari team on this matter have been arrogant, detached. I don't hold any hope.
The overall vibes leaking from the Safari team on this matter have been arrogant, detached. I don't hold any hope.
>Apple has banned other browser engines on their platform.
Can you elaborate on this a bit? I primarily use Chrome as my browser on iOS. Is it really just running the Safari engine under the hood?
Can you elaborate on this a bit? I primarily use Chrome as my browser on iOS. Is it really just running the Safari engine under the hood?
Yes. For this very reason, Mozilla was not porting Firefox to iOS for a very long time. Now, Firefox is also running iOS provided rendering engine.
Can you share more information about how the ban to other browsers works? Safari can do whatever they want but Apple banning competition is what hurts the web.
I think push notifications and offline support are the real killer features that Apple currently doesn't support.
It's kind of funny as a web developer because for the longest time Apple seemed to be the one pushing the mobile web forward but now that web apps are reaching for feature parity with native, Apple's initial momentum seems to be ancient history.
It seems Apple still thinks of the mobile web as a content delivery platform rather than an application platform. Their proprietary additions (mostly CSS) largely focused on making things prettier, their rationale for opting out of standard features (e.g. autoplay) often only work under the assumption that the only use for those features would be in the context of traditional content pages.
You want an app? Develop for our walled garden we tightly control to offer our users the best possible experience. If you want it on the web, stick to creating content our users can consume in Mobile Safari, our app for reading websites.
It's kind of funny as a web developer because for the longest time Apple seemed to be the one pushing the mobile web forward but now that web apps are reaching for feature parity with native, Apple's initial momentum seems to be ancient history.
It seems Apple still thinks of the mobile web as a content delivery platform rather than an application platform. Their proprietary additions (mostly CSS) largely focused on making things prettier, their rationale for opting out of standard features (e.g. autoplay) often only work under the assumption that the only use for those features would be in the context of traditional content pages.
You want an app? Develop for our walled garden we tightly control to offer our users the best possible experience. If you want it on the web, stick to creating content our users can consume in Mobile Safari, our app for reading websites.
A lot of people are already sick and tired of websites asking to be able to send push notifications in the browser. Annoying people isn't a "killer feature", it's an aggravation.
If a normal website can't do the job, and the developer isn't willing to develop a native app, then maybe the product simply isn't necessary.
If a normal website can't do the job, and the developer isn't willing to develop a native app, then maybe the product simply isn't necessary.
I've never, ever allowed a website to send me push notifications. I honestly didn't even know it was a "thing" until I started getting requests. Also, location-sharing requests are baffling to me on my desktop for anything other than something like a weather site (I still disallow- I have my favorites set).
>If a normal website can't do the job, and the developer isn't willing to develop a native app, then maybe the product simply isn't necessary.
That seems like circular logic. IMO, very few products are "necessary," and sure, right now developers have pretty much no choice but to support native walled gardens if they want to support the list of features PWA offers.
But what if users had a real choice? What if the web browser could offer an immersive user experience on par with native mobile apps? What if browser vendors actually put in effort to optimize for user preferences regarding PWA call-to-actions? What if PWAs were as widely promoted as native app stores?
That seems like circular logic. IMO, very few products are "necessary," and sure, right now developers have pretty much no choice but to support native walled gardens if they want to support the list of features PWA offers.
But what if users had a real choice? What if the web browser could offer an immersive user experience on par with native mobile apps? What if browser vendors actually put in effort to optimize for user preferences regarding PWA call-to-actions? What if PWAs were as widely promoted as native app stores?
Is there a reason for users to care about this at all? Because it seems to me that this just solves problems for developers while making the user experience worse or not as good as it could be. The same goes for Electron-based apps.
Push notifications? Every single messenger or anything that lets you set reminders. Note that features like push notifications are implemented with a discrete opt-in on every other platform already. Don't want notifications? Just say "Deny" when you're prompted.
Offline support? Only if you happen to live in the 99.99% of the world that doesn't have 24/7 perfect WiFi/4G coverage with unlimited data. If you've ever kept a page open in the background and wished the data would still be there when you come back, offline support could have helped with that.
The choice is not between a native and a web app. The choice is between a web app or no app. There are certainly apps that could cease developing platform specific native apps when PWAs are supported on iOS but the vast majority of apps that benefit from PWAs being supported universally are apps that simply would never be available as native apps (let alone native apps on more than one platform).
Offline support? Only if you happen to live in the 99.99% of the world that doesn't have 24/7 perfect WiFi/4G coverage with unlimited data. If you've ever kept a page open in the background and wished the data would still be there when you come back, offline support could have helped with that.
The choice is not between a native and a web app. The choice is between a web app or no app. There are certainly apps that could cease developing platform specific native apps when PWAs are supported on iOS but the vast majority of apps that benefit from PWAs being supported universally are apps that simply would never be available as native apps (let alone native apps on more than one platform).
All of these things are already available in native apps. Putting aside all the business reasons for why Apple wouldn't want to do this, why should Apple spend any time to enable this for web apps? You say the choice is between a web app and no app, and I'm sure on the margin this impacts companies that can't afford to create a native app, but why should Apple cater to the lowest common denominator? Steve Jobs' post on Flash addresses this specifically [1]:
>Sixth, the most important reason.
Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
[1] https://www.apple.com/hotnews/thoughts-on-flash/
>Sixth, the most important reason.
Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
[1] https://www.apple.com/hotnews/thoughts-on-flash/
that quote basically sums it up. third-party cross-platform solutions are good for developers but bad for Apple and all it's users. The reason I choose Apple is because they make these kind of user-first decisions.
> "We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform."
Yet those of us old enough to remember the 90s also recall how the openness of the web freed people from the monopolistic behavior of Microsoft. Sure, the web was bad for Microsoft, but great for users.
This whole argument is circular. Web capabilities lag because companies like Apple deliberately drag their feet. Then people like you cite all the advanced features of native development as a reason not to try and use the web. All of which suits Apple fine, since they get 30% of native, and 0% of the web. Apple hobbling PWA is the new "IE-only" website.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it." - Upton Sinclair
Yet those of us old enough to remember the 90s also recall how the openness of the web freed people from the monopolistic behavior of Microsoft. Sure, the web was bad for Microsoft, but great for users.
This whole argument is circular. Web capabilities lag because companies like Apple deliberately drag their feet. Then people like you cite all the advanced features of native development as a reason not to try and use the web. All of which suits Apple fine, since they get 30% of native, and 0% of the web. Apple hobbling PWA is the new "IE-only" website.
"It is difficult to get a man to understand something, when his salary depends on his not understanding it." - Upton Sinclair
I take it you didn't catch that that was all hypocritical bullshit :/. Steve Jobs can poke fun at Adobe all they want over Flash not adopting Cocoa and enabling developers to build applications using a third-party API layer over their platform, but it is totally duplicitous to do so without admitting that at the time iTunes was still written in Carbon and there was no timeline for that to change because their Windows implementation was ported to that platform as an API layer over the Win32 platform that allowed them to not have to maintain a truly native port of that product. To this day iTunes is written in that fashion; and, in fact, large amounts of it have been built on top of hybrid app web technologies so they can minimize how much stress they have to put on their increasingly abstract API layer. Seriously: go install iTunes on Windows and stare in awe at how Apple has essentially reimplemented OS X in a massive wad of DLLs so they can have iTunes sit on top. If Apple wants to be taken seriously, they should stop preaching and put their money where their mouth is and reimplement iTunes to work on both Windows and macOS as first-class native applications tied to the low-level APIs offered by the platform. The reality, of course, is that even a company as massive and successful as Apple understands the value proposition inherent in having one codebase that works on multiple platforms, and is willing to hamstring even their own macOS experience to make maintenance of their port to Windows easier. What is sad is that they can still tell these bold-faces lies about what their motives are, and people like you somehow still believe them :/.
This is a great post about why you should target iOS and macOS features specifically. But it misses the point,
> we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen.
Yes, that's what (you and) Apple want. But what developers really want is a simple cross platform framework to target all OSes and the widest user base possible with the least effort.
These applications can then enable custom features on macOS where they get a better experience if they have a need for that.
Remember OpenStep? Yellowbox? We want those tools; right now the web is an ok standin, and until there is something better, developers will keep demanding these features. It's about targeting the widest user base possible, not about making a single platform the most successful.
> we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen.
Yes, that's what (you and) Apple want. But what developers really want is a simple cross platform framework to target all OSes and the widest user base possible with the least effort.
These applications can then enable custom features on macOS where they get a better experience if they have a need for that.
Remember OpenStep? Yellowbox? We want those tools; right now the web is an ok standin, and until there is something better, developers will keep demanding these features. It's about targeting the widest user base possible, not about making a single platform the most successful.
Cool so then it just comes down to leverage. Developers who wants this have almost none and Apple has all of it. As a user who mostly doesn't care about the trials and tribulations that developers go through, my interests are aligned with Apple's.
As long as Apple continues to sell more product that dynamic isn't going to change.
As long as Apple continues to sell more product that dynamic isn't going to change.
> Cool so then it just comes down to leverage. Developers who wants this have almost none and Apple has all of it.
You are definitely right that Apple has a lot of leverage for now. I love my Apple products, as a user I have no intention of switching away from them (I stuck with them through their worst period, '96 - '00, because I was so excited for the coming of Unix). Again as a user I want them to succeed because I love the products.
As a developer though, I want my favorite tools and languages available. And I want to spend the least effort in targeting users...
You are definitely right that Apple has a lot of leverage for now. I love my Apple products, as a user I have no intention of switching away from them (I stuck with them through their worst period, '96 - '00, because I was so excited for the coming of Unix). Again as a user I want them to succeed because I love the products.
As a developer though, I want my favorite tools and languages available. And I want to spend the least effort in targeting users...
These are good arguments. But they apply verbatim to Java, HTML, and JavaScript in the times of Windows and IE3/4, if Bill Gates had been asked publicly.
The choice is between a web app or no app.
why do you assume that's a worse alternative?
why do you assume that's a worse alternative?
Watch the State of the Web talk from Google IO 2017. Certain native apps (Twitter, OLA) are 70-100MB in size when downloaded from the app stores. Their progressive web app version are 0.2-0.6MB. Extremely important in countries with very limited and/or expensive mobile data.
That doesn't have anything to do with native vs web though.
Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342
The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342
The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
https://sensortower.com/blog/ios-app-size-growth
According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter.
It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter.
It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
But now Facebook mobile app is a different tech. It's ReactNative, not Obj-C, right?
React Native under the hood uses Obj-C to bridge to native Cocoa frameworks. For example when you uses a <View> tag in JavaScript, it ends up calling iOS UIView.
Still, it's not the very same tech. Especially in this discussion, where we are talking about apps performance and languages, which need to get under the hood instead of talking directly with the engine, are presented as "worse".
Only a tiny fraction of the Facebook app is actually RN. Messenger uses none of it for performance reasons.
Huh? Isn't Facebook advertising their main app as no.1 use case of ReactNative?
Advertising is one thing, reality is different. The main, performant views are native. Some of the esoteric stuff is RN.
I'd say that's another issue. Duplicate frameworks in Facebook.app, monolithic tracking frameworks, etc. So much useless stuff prying on the user's privacy.
I remember Twitter.app had code to get the currently installed apps, to "better target ads." It's user hostile and we are paying with the multi gigabytes of data.
I remember Twitter.app had code to get the currently installed apps, to "better target ads." It's user hostile and we are paying with the multi gigabytes of data.
The argument can't go only one way, though. If a web app doesn't get the UI in tune with the OS' look and feel, "the developer should be bothered to create a native app". But if a native app is a massive bloat, "that's another issue".
0.6MB to launch the app, which downloads 100MB more resources as soon as it starts up.
Exactly. I don't want websites to send notifications. And I dislike websites with Offline support: I always have to refresh twice to make sure the content I'm seeing came from a fresh source and not from cache.
Why is your complaint specific to websites with offline support? I always get stale data when I open Twitter app. I have to go to the top and refresh to get new tweets (and then they serve you with even more stale tweets but that's another problem).
It's very specific and I realize I'm being privileged. I don't think my argument holds much ground.
My thing is: I visit a particular website to get the latest news on a topic but it's done with some kind of poorly coded implementation of offline cache. Despite my privileged, first-world, 4G-everywhere connection, it insists on loading stale data even though it looks exactly like a regular website. And this clashes with my vision of internet, which is, as others said, regular pages with hyperlinks, and a Refresh refreshes the page to get the newest version, even if it's stale. If things haven't changed, then they haven't and I instantly know nothing's new.
As I've said, pretty minor and I realize that Offline mode has much more pros than cons.
My thing is: I visit a particular website to get the latest news on a topic but it's done with some kind of poorly coded implementation of offline cache. Despite my privileged, first-world, 4G-everywhere connection, it insists on loading stale data even though it looks exactly like a regular website. And this clashes with my vision of internet, which is, as others said, regular pages with hyperlinks, and a Refresh refreshes the page to get the newest version, even if it's stale. If things haven't changed, then they haven't and I instantly know nothing's new.
As I've said, pretty minor and I realize that Offline mode has much more pros than cons.
Then just deny push notifications when the website prompts for them (exactly once). And simply refresh manually to make sure the offline-available website is fresh.
It's not like you're being force-fed notifications against your will. And it's not like offline content hurts you. Any inconvenience offline support causes to you pales in comparison to how much people benefit who actually need to be able to access content on spotty connections.
It's not like you're being force-fed notifications against your will. And it's not like offline content hurts you. Any inconvenience offline support causes to you pales in comparison to how much people benefit who actually need to be able to access content on spotty connections.
Offline makes sense, you are right. I'm being privileged.
But for notifications, even the only-once* prompt is an annoyance we never had to deal with before. It's like the European Cookies Law: great in essence, but when every website bugs you about it then the problem has been exacerbated, not solved. I don't care about receiving notifications for a website I visit once in a blue moon, and I especially don't care to be even asked. There should be an action that triggers the prompt, like some kind of opt-in.
Edit: same with "app banners"
*it never is, because cross platform, multiple devices, multiple browsers. A fucking pain.
But for notifications, even the only-once* prompt is an annoyance we never had to deal with before. It's like the European Cookies Law: great in essence, but when every website bugs you about it then the problem has been exacerbated, not solved. I don't care about receiving notifications for a website I visit once in a blue moon, and I especially don't care to be even asked. There should be an action that triggers the prompt, like some kind of opt-in.
Edit: same with "app banners"
*it never is, because cross platform, multiple devices, multiple browsers. A fucking pain.
>The same goes for Electron-based apps.
It might be faster than Atom, but it surely feels sluggish compared with other native editors on my system.
I only put up with it due to being the editor with the best support for Rust plugins.
The day I can have the same experience on Emacs for Rust, VSCode gets kicked out.
I only put up with it due to being the editor with the best support for Rust plugins.
The day I can have the same experience on Emacs for Rust, VSCode gets kicked out.
Code is not native. Where is the accessibility support? Native tabs? Performance? Look and feel?
Compared to something like BBEdit, Code is a joke.
What you fail to understand is that what is good for developers is good for users. Instead of spending resources on maintaining many different code bases, developers can focus on providing a more solid set of features for one.
For instance, maybe instead of being an always online application, they can put in effort at caching for offline use instead of duplicating features across different platforms.
I did my senior project in Electron and there was no way we could have implemented as much as we did if we had to build a native solution for every platform.
For instance, maybe instead of being an always online application, they can put in effort at caching for offline use instead of duplicating features across different platforms.
I did my senior project in Electron and there was no way we could have implemented as much as we did if we had to build a native solution for every platform.
I've never met a single end user who wants desktop notifications for web "apps," including myself. In fact I wish I could turn it off globally and more easily.
I'm sure there are a number of legitimate uses but as of now, every craptastic "news" website I visit now wants to pester the hell out of me with notifications when they post new clickbait.
I'm sure there are a number of legitimate uses but as of now, every craptastic "news" website I visit now wants to pester the hell out of me with notifications when they post new clickbait.
Im comfortable with the current system where websites request permission for notifications, but they are as useful as phone notifications. Message in a webchat, new email, new private notification on Twitter, &c.
It should always be opt in, but it is a useful thing for many use cases.
It should always be opt in, but it is a useful thing for many use cases.
Can't reply to FussyZeus, but in Firefox, you can permanently disable notifications for all websites (though it is not exposed in the UI).
Go to about:config, search for dom.webnotifications.enabled, set it to false.
Go to about:config, search for dom.webnotifications.enabled, set it to false.
Thank you, and thank you, Mozilla.
I've never met a single end user who wants desktop notifications for web "apps," including myself. In fact I wish I could turn it off globally and more easily.
In Firefox, just open "about:config", search for dom.webnotifications.enabled, then double-click it.
If using other browsers, don't :)
(PS: I like desktop notifications for Slack, but since I'd prefer not to use Slack in the first place, I'm not sure I count)
In Firefox, just open "about:config", search for dom.webnotifications.enabled, then double-click it.
If using other browsers, don't :)
(PS: I like desktop notifications for Slack, but since I'd prefer not to use Slack in the first place, I'm not sure I count)
In chrome: settings -> advanced -> content settings
Also dom.push.enabled = false, apparently.
From what I understand, the previous config kills all desktop notifications, overriding that config, which is just about push notifications.
Ironically, they frequently don't give RSS feed. Which I'd be happy to subscribe to.
OK: today you have met one. I have notifications turned on in desktop Safari for Facebook, Twitter, Slack, a handful of news sites that I like to keep up on, and probably some other stuff I am not remembering right now; and no: the idea of installing a native application for any of these services sickens me for numerous reasons (everything from concrete reasons of security and convenience to philosophical objections related to wanting to maintain an open, searchable, and hyperlinkable web).
Agree 100%
I'd be OK with a small icon in the address bar to indicate push notifications are available on a site but even one pop up asking for permission is too many.
I'd be OK with a small icon in the address bar to indicate push notifications are available on a site but even one pop up asking for permission is too many.
Push notifications are the new pop-up window. When every app has and uses push notifications, it makes any app having them almost pointless unless you deny half of the push notification requests you get.
> I think push notifications and offline support are the real killer features that Apple currently doesn't support.
Technically Apple does support offline via the older manifests mechanism (and "Add to Home Screen" which invokes it remains prominent in the safari share sheet) though it's a lousy (and pretty buggy) experience.
Interestingly they don't support any sort of web notifications on iOS despite having added local notifications ( https://www.w3.org/TR/notifications/) in macOS 10.8 and remote Safari Push Notifications (built on APNS) in macOS 10.9.
Technically Apple does support offline via the older manifests mechanism (and "Add to Home Screen" which invokes it remains prominent in the safari share sheet) though it's a lousy (and pretty buggy) experience.
Interestingly they don't support any sort of web notifications on iOS despite having added local notifications ( https://www.w3.org/TR/notifications/) in macOS 10.8 and remote Safari Push Notifications (built on APNS) in macOS 10.9.
> web apps are reaching for feature parity with native
This is Papa Pear: https://king.com/game/papapear
The HTML5 version is compiled from the same source that the App that goes to the Apple App Store (https://itunes.apple.com/us/app/papa-pear-saga/id572542612?m...).
What's so different? It is literally the same code base (minus some platform specific code).
The HTML5 version is compiled from the same source that the App that goes to the Apple App Store (https://itunes.apple.com/us/app/papa-pear-saga/id572542612?m...).
What's so different? It is literally the same code base (minus some platform specific code).
I am talking about possibilities provided by iOS SDK and what is provided by web stack. It is amazing that React Native does not even have something UINavigationControll-ish.
UIKit alone gives stuff which is lightyears ahead of the web.
Even some more basic stuff: how easy it is to add accessibility to PWAs? Localization?
Most Frontend-Frameworks do have Localization-features so that's kind of easy to do. But other features like Bluetooth are nowhere to be seen (Blink Browser can do this - but it's far far away from a standard)
Web Bluetooth: https://webbluetoothcg.github.io/web-bluetooth/ (not yet standard, but supported by Chrome, for example).
A11y is also being taken seriously.
A11y is also being taken seriously.
If you're referring to the pre-App Store iPhone OS, have you considered the possibility that they were just late with the SDK?
Apparently according to the Jobs biography, Steve Really did oppose native apps
https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
> It seems Apple still thinks of the mobile web as a content delivery platform rather than an application platform.
Apple wants in-app purchases. Why deliver full flexed apps in the web were people pays using PayPal or VISA if you can force people to use your store?
This is the reason Apple killed Flash and is the reason why they may kill any other web technology.
Apple wants in-app purchases. Why deliver full flexed apps in the web were people pays using PayPal or VISA if you can force people to use your store?
This is the reason Apple killed Flash and is the reason why they may kill any other web technology.
When Apple decided not to put Flash on the iPhone, they had also decided that there would be no 3rd party native apps on the iPhone.
They later reversed that decision, of course. But the Flash decision was right at the beginning and had nothing to do with in-app purchases.
Note that Android never got Flash to work well on phones either. It just killed performance and battery life.
They later reversed that decision, of course. But the Flash decision was right at the beginning and had nothing to do with in-app purchases.
Note that Android never got Flash to work well on phones either. It just killed performance and battery life.
Native IOS apps can absolutely accept credit card payment. In app purchases are only required for content that is consumed in app.
While I'm sure there was also a financial motive, the primary was still that flash did (and does) suck. It sucks batteries, it sucks at security and it sucks at scaling for mobiles.
Not to defend Apple on this, but no, Flash was already dead by the time Apple implemented in-app purchases.
Conversely, Apple is in a perfect position to spearhead a web micropayment API standard, and has total control over the browser and thus the way users' use it.
They have already released Apple Pay for the Web.
My post clearly was missing the word "standard", which I've now added. Running in as many browsers as possible once something is completed is important for these things.
As an iOS user, I'm actually quite glad that websites can't send me push notifications on it. And app loading screens are a feature?
If people _insist_ on making phone apps as websites, there's Cordova and all that. Such apps are never very good, of course. I still haven't seen a website-based desktop/phone app that wasn't a clunky non-native-looking resource-hogging mess.
If people _insist_ on making phone apps as websites, there's Cordova and all that. Such apps are never very good, of course. I still haven't seen a website-based desktop/phone app that wasn't a clunky non-native-looking resource-hogging mess.
That exact argument can be applied to native apps. Should native apps have push notifications removed?
Why not? Because they can actually be extremely useful. Such as for receiving emails, Facebook messages, Slack pings, or news updates you've subscribed to. Maybe somebody tweeted you. Any of these apps could work as progressive webapps.
Regardless if the platform is native or web-based, the feature remains opt-in. If you don't want them, then don't subscribe to them.
Why not? Because they can actually be extremely useful. Such as for receiving emails, Facebook messages, Slack pings, or news updates you've subscribed to. Maybe somebody tweeted you. Any of these apps could work as progressive webapps.
Regardless if the platform is native or web-based, the feature remains opt-in. If you don't want them, then don't subscribe to them.
Yes but supporting the feature encourages developers to make web apps. Why would you want to encourage that?
Why wouldn't you want that? PWAs are seamless (no downloading/installing), allow native features, can be saved offline for later, run in a secure sandbox, and are completely open and cross-platform.
I don't really value cross-platform in the sense that the code I write for platform A can run on platform B. At least for applications.
I think it's valuable for games. Unity and Unreal engine have demonstrated that.
Applications necessarily intersect with the underlying platform in a way which games do not. Accessibility, system-wide services (e.g., dictionary), system-wide interactions (e.g., drag and drop). There are reasons I choose macOS, and when applications embrace the design philosophy and features of the platform they become great applications. PWAs will not do this to the same extent (and if they try to, the effort would be so significant they might as well go native).
I feel strongly that the platforms you develop for should be the platforms you love using. And so the things you develop should bring out the best and most valuable features of those platforms.
I would rather encourage developers to embrace each platform's strengths. I understand that many companies might not care — they want as many users as possible as cheaply as possible. But I do not appreciate that attitude at all.
I think it's valuable for games. Unity and Unreal engine have demonstrated that.
Applications necessarily intersect with the underlying platform in a way which games do not. Accessibility, system-wide services (e.g., dictionary), system-wide interactions (e.g., drag and drop). There are reasons I choose macOS, and when applications embrace the design philosophy and features of the platform they become great applications. PWAs will not do this to the same extent (and if they try to, the effort would be so significant they might as well go native).
I feel strongly that the platforms you develop for should be the platforms you love using. And so the things you develop should bring out the best and most valuable features of those platforms.
I would rather encourage developers to embrace each platform's strengths. I understand that many companies might not care — they want as many users as possible as cheaply as possible. But I do not appreciate that attitude at all.
And that was such a great experience with Java applets....
False equivalence. The points I listed above were not true for Java applets.
Applets were not seamless (requiring a plugin to be installed), did not allow most native features, and ran in anything but a secure sandbox.
They were open (by nature of the JVM), and cross-platform, but that's it.
Applets were not seamless (requiring a plugin to be installed), did not allow most native features, and ran in anything but a secure sandbox.
They were open (by nature of the JVM), and cross-platform, but that's it.
I'm pretty sure it boils down to "we're fancy iOS users who want nothing to do with those peasants over in the Android world". It seems like the majority of the comments opposing web apps oppose them because they're cross-platform and not written specifically for their chosen platform, which is a very silly stance to have.
There are some more coherent arguments in play, don't get me wrong (in particular, the argument that web apps are a bastardization of what the World Wide Web was intended to be for; I agree with that wholeheartedly), but a lot of the rhetoric around here really reeks of elitism.
There are some more coherent arguments in play, don't get me wrong (in particular, the argument that web apps are a bastardization of what the World Wide Web was intended to be for; I agree with that wholeheartedly), but a lot of the rhetoric around here really reeks of elitism.
I've written quite a few apps for both iOS and Android.
While I'm not an Android user, when I build an Android app I try to embrace the platform's strengths. I try to understand best practice, and follow the designs encouraged by Google. The resulting apps often look and behave completely differently between iOS and Android because the platforms are so different.
I have mixed opinions about a lot of Android's design philosophy, but there's no way I would build an Android app that didn't conform to the platform. Because I expect Android users enjoy consistency too.
There's probably some elitism in there. But there still is no web app on macOS or iOS that feels good, consistent and integrated in the same way that a good native app feels.
While I'm not an Android user, when I build an Android app I try to embrace the platform's strengths. I try to understand best practice, and follow the designs encouraged by Google. The resulting apps often look and behave completely differently between iOS and Android because the platforms are so different.
I have mixed opinions about a lot of Android's design philosophy, but there's no way I would build an Android app that didn't conform to the platform. Because I expect Android users enjoy consistency too.
There's probably some elitism in there. But there still is no web app on macOS or iOS that feels good, consistent and integrated in the same way that a good native app feels.
> But there still is no web app on macOS or iOS that feels good, consistent and integrated in the same way that a good native app feels.
Part of that though is because they _don't_ allow PWAs. Contrast that with Android, where it's now entirely possible to make a PWA so deeply integrated into the OS that the average user can't even tell it's not a native app: https://blog.chromium.org/2017/02/integrating-progressive-we...
Part of that though is because they _don't_ allow PWAs. Contrast that with Android, where it's now entirely possible to make a PWA so deeply integrated into the OS that the average user can't even tell it's not a native app: https://blog.chromium.org/2017/02/integrating-progressive-we...
> Contrast that with Android, where it's now entirely possible to make a PWA so deeply integrated into the OS that the average user can't even tell it's not a native app
Oh, but quite many will be able to tell after 5 seconds of using it. The rest will realize the moment the Internet connection drops temporarily.
Oh, but quite many will be able to tell after 5 seconds of using it. The rest will realize the moment the Internet connection drops temporarily.
> The rest will realize the moment the Internet connection drops temporarily.
Nope. A properly-written PWA will continue working just fine when the user goes offline, just like a native app would.
Nope. A properly-written PWA will continue working just fine when the user goes offline, just like a native app would.
Most native apps that rely on a web service backend are pretty unusable when the connection goes offline.
It's not. I feel the same way as 'interpol_p, and I'm an Windows/Linux + Android user.
The webapp ecosystem is making the same class of mistakes pure-Java UIs used to. They assume e.g. that a textbox is just a rectangle on a screen that you can type stuff in. But it's not just that; it's much more.
Each operating system has a large set of default UI behaviours and idiosyncrasies. Continuing the example, a native textbox may be a clickable rectangle accepting keyboard input, but it also has a set of well-defined behaviours for Tab-cycling, text navigation, right-click handling, keyboard shortcut handling, cut/copy/paste handling, etc. Web applications fail to replicate that functionality completely and consistently. And platform consistency is a feature - one that many users value.
On top of that add resource waste (spinning up a webview and parsing heavy markup languages just to show a bunch of buttons) and web-specific failure modes - many vendors do not care about making their webapp work correctly when connectivity is limited, spotty or lacking. Hence the occasional full-screen 404 or 501 or connection-lost error when you press a button.
I want my applications to be performant, platform-consistent and interoperable. Web apps fail at all three, hence I avoid them like the plague, and discourage everyone from developing them.
About the only benefit I, as a pro user, I get from web application is the relative ease one can reverse-engineer their backend APIs with.
The webapp ecosystem is making the same class of mistakes pure-Java UIs used to. They assume e.g. that a textbox is just a rectangle on a screen that you can type stuff in. But it's not just that; it's much more.
Each operating system has a large set of default UI behaviours and idiosyncrasies. Continuing the example, a native textbox may be a clickable rectangle accepting keyboard input, but it also has a set of well-defined behaviours for Tab-cycling, text navigation, right-click handling, keyboard shortcut handling, cut/copy/paste handling, etc. Web applications fail to replicate that functionality completely and consistently. And platform consistency is a feature - one that many users value.
On top of that add resource waste (spinning up a webview and parsing heavy markup languages just to show a bunch of buttons) and web-specific failure modes - many vendors do not care about making their webapp work correctly when connectivity is limited, spotty or lacking. Hence the occasional full-screen 404 or 501 or connection-lost error when you press a button.
I want my applications to be performant, platform-consistent and interoperable. Web apps fail at all three, hence I avoid them like the plague, and discourage everyone from developing them.
About the only benefit I, as a pro user, I get from web application is the relative ease one can reverse-engineer their backend APIs with.
>On top of that add resource waste (spinning up a webview and parsing heavy markup languages just to show a bunch of buttons)
Hold on - do you know what a progressive web app is? We're not talking about apps like Slack which bundle a browser inside of them - we're talking about webpages that behave like applications.
>many vendors do not care about making their webapp work correctly when connectivity is limited, spotty or lacking.
Offline support is a key feature of PWAs, so this point is moot.
>Each operating system has a large set of default UI behaviours and idiosyncrasies.
Browsers are completely able to define their own design language, so a text box need not look the same in every browser. As long as they conform to common standards, everything will work fine.
As such, you don't get the Java problem where everything must conform to the same style, and thus feels foreign in different environments.
>I want my applications to be performant, platform-consistent and interoperable. Web apps fail at all three
PWAs excel at all three. That's the whole idea.
Hold on - do you know what a progressive web app is? We're not talking about apps like Slack which bundle a browser inside of them - we're talking about webpages that behave like applications.
>many vendors do not care about making their webapp work correctly when connectivity is limited, spotty or lacking.
Offline support is a key feature of PWAs, so this point is moot.
>Each operating system has a large set of default UI behaviours and idiosyncrasies.
Browsers are completely able to define their own design language, so a text box need not look the same in every browser. As long as they conform to common standards, everything will work fine.
As such, you don't get the Java problem where everything must conform to the same style, and thus feels foreign in different environments.
>I want my applications to be performant, platform-consistent and interoperable. Web apps fail at all three
PWAs excel at all three. That's the whole idea.
Text boxes in the web have had the same look & feel as native text boxes since between one and two decades ago.
When I right-click on the one I'm typing in right now, on Chrome running on a Mac, I even get an option to "Add to iTunes as a Spoken Track", whatever that might be, same as with the native text boxes.
When I right-click on the one I'm typing in right now, on Chrome running on a Mac, I even get an option to "Add to iTunes as a Spoken Track", whatever that might be, same as with the native text boxes.
> Text boxes in the web have had the same look & feel as native text boxes since between one and two decades ago.
They would have if people weren't "improving" them with JavaScript as some sort of a rite of passage, or something.
They would have if people weren't "improving" them with JavaScript as some sort of a rite of passage, or something.
I'm an Android user, and I don't want these either. Mainly because they don't integrate with the native look & feel of the platform. And when a dev tries to, then inevitably make it look like iOS, and ignores Android look & feel.
"It seems like the majority of the comments opposing web apps oppose them because they're cross-platform and not written specifically for their chosen platform, which is a very silly stance to have."
But it's not. By not being written specifically for the platform, everyone is just getting a least common denominator approach. Nobody is getting anything that integrates with their platform. Nobody is getting anything that embraces what makes the platform special, or good.
"but a lot of the rhetoric around here really reeks of elitism."
No, it's more that we want developers to actually make an effort to embrace the platform they're trying to work on. And, quite frankly, use something that's not JavaScript. Learn a second language.
"It seems like the majority of the comments opposing web apps oppose them because they're cross-platform and not written specifically for their chosen platform, which is a very silly stance to have."
But it's not. By not being written specifically for the platform, everyone is just getting a least common denominator approach. Nobody is getting anything that integrates with their platform. Nobody is getting anything that embraces what makes the platform special, or good.
"but a lot of the rhetoric around here really reeks of elitism."
No, it's more that we want developers to actually make an effort to embrace the platform they're trying to work on. And, quite frankly, use something that's not JavaScript. Learn a second language.
Remember how Java applets and Java desktop applications took over the world?
A big part of the reason they didn't is the reason that people dislike these fake-native web-apps; they just don't feel right.
A big part of the reason they didn't is the reason that people dislike these fake-native web-apps; they just don't feel right.
Web apps (as in what we used to call websites that did stuff instead of just displaying content, not PWAs) did take over the world, enabling the (slow) downfall of Windows. They didn't feel like native Windows apps either, and the web stack was far worse back then.
There's two big differences:
- There was an unsatisfied need back then to move your apps and data with you as you moved to another PC. The phone moves with you.
- Microsoft couldn't prohibit Mozilla and Google from writing non-crippled Windows web browsers. Apple learned from that "mistake" and won't let it happen on iOS.
There's two big differences:
- There was an unsatisfied need back then to move your apps and data with you as you moved to another PC. The phone moves with you.
- Microsoft couldn't prohibit Mozilla and Google from writing non-crippled Windows web browsers. Apple learned from that "mistake" and won't let it happen on iOS.
Push notifications are opt in on every browser that supports them. I'm confident Apple could come up with a process that ensures you only get them if you want them and can easily opt out later.
Right, but as a user experience you get a phone that either annoys you into switching off all the features that can be used to bug you, or annoys you endlessly because you don't know how to switch it off, or doesn't have it on by default - in which case there's little point in implementing it all, because most will not even be aware they can switch it on.
Or you could do some kind of middle-ground like what Chrome is planning, where the user can only be prompted to enable notifications after they've reached some specific level of engagement with the site they're using: https://github.com/WICG/interventions/issues/49#issuecomment...
> If people _insist_ on making phone apps as websites, there's Cordova and all that. Such apps are never very good, of course
I strongly disagree. We use Ionic (which is based on Cordova) for line of business apps, and the results are as good as native apps, but with the benefit (amongst others) of having a single codebase for both Android and iOS.
Hybrid apps aren't a good match for all types of app - games in particular - but they do work well for many others.
I strongly disagree. We use Ionic (which is based on Cordova) for line of business apps, and the results are as good as native apps, but with the benefit (amongst others) of having a single codebase for both Android and iOS.
Hybrid apps aren't a good match for all types of app - games in particular - but they do work well for many others.
Yes, all you're saying is it is possible to make shitty native apps too. So that would explain your results. Native isn't a magic wand, but except for the simplest of things web will not be as good. The cracks still show in things like Google docs and sheets and overall those are pretty good as far as web goes.
> Yes, all you're saying is it is possible to make shitty native apps too
No, that's not what I said at all. I guess you're only going to read what you want to hear...
No, that's not what I said at all. I guess you're only going to read what you want to hear...
IMO convoluted JavaScript hacks aren't the solution to "cross platform development" I'd want to settle on. Do I really want my weather app to be running on top of the browser app? And as far as cross-platform compatibility goes, we're now at a point where websites tell you to please load them with Chrome for the "full experience", that just reminds me of when websites used to tell you to please use Internet Explorer. So much for "Apple mobile Safari is the new Internet Explorer", lol. Push notifications for browsers are a weird concept, anyway.
> convoluted JavaScript hacks aren't the solution to "cross platform development" I'd want to settle on
Walled gardens with one app per platform with 1000 different rules per platform so users don't spend more than 100ms to understand a layout shouldn't be the solution as well. Javascript apps being convoluted isn't even an objective observation.
> Do I really want my weather app to be running on top of the browser app?
It's yet another VM with more abstractions. What's the big deal?
> So much for "Apple mobile Safari is the new Internet Explorer", lol.
I never had any significant app work only on one browser since years but even if this was a big problem, why make it worse?
> Push notifications for browsers are a weird concept, anyway.
I don't see the big deal? You are asked to allow it, no?
Walled gardens with one app per platform with 1000 different rules per platform so users don't spend more than 100ms to understand a layout shouldn't be the solution as well. Javascript apps being convoluted isn't even an objective observation.
> Do I really want my weather app to be running on top of the browser app?
It's yet another VM with more abstractions. What's the big deal?
> So much for "Apple mobile Safari is the new Internet Explorer", lol.
I never had any significant app work only on one browser since years but even if this was a big problem, why make it worse?
> Push notifications for browsers are a weird concept, anyway.
I don't see the big deal? You are asked to allow it, no?
I'd love more contributions to cross-platform native UI toolkits and frameworks. Write once, run anywhere native apps have a place.
> convoluted JavaScript hacks
Yay for WebAssembly.
Yay for WebAssembly.
I hate using web apps. On desktop, mobile, wherever. The author's list of things they want supported by Mobile Safari is just aggravating:
> Here are a list of things you still can’t do with mobile safari due to Apple’s refusal to support them:
>
> Create an app loading screen
> Use push notifications
> Add offline support
> Create an initial app UI to load instantly
> Prompt installation to the home screen through browser-guided dialog
Why do I want these things, as a user. App loading screens?
I love the web. I love hyperlinks, text and images. The web of connections that lead you to information. Everything in that list is detrimental to a good experience on the web.
I don't want push notifications, I barely enable them for native apps. And it bugs the hell out of me when every second website in desktop Safari prompts to send me push notifications. No. Why would I want this on mobile?
Same thing with the home screen. I love the fact that the address bar in my web browser is my history, my reminders, my bookmarks, my open tabs. I start typing what I want and I'm there. Finding native apps on my home screen is only just getting to the same place with Spotlight, why would I want to make the web worse by sticking icons for pages on my home screen?
And browser-guided dialogs to put more icons on my home screen? Seriously?
This author's post is a great argument against web apps on mobile.
> Here are a list of things you still can’t do with mobile safari due to Apple’s refusal to support them:
>
> Create an app loading screen
> Use push notifications
> Add offline support
> Create an initial app UI to load instantly
> Prompt installation to the home screen through browser-guided dialog
Why do I want these things, as a user. App loading screens?
I love the web. I love hyperlinks, text and images. The web of connections that lead you to information. Everything in that list is detrimental to a good experience on the web.
I don't want push notifications, I barely enable them for native apps. And it bugs the hell out of me when every second website in desktop Safari prompts to send me push notifications. No. Why would I want this on mobile?
Same thing with the home screen. I love the fact that the address bar in my web browser is my history, my reminders, my bookmarks, my open tabs. I start typing what I want and I'm there. Finding native apps on my home screen is only just getting to the same place with Spotlight, why would I want to make the web worse by sticking icons for pages on my home screen?
And browser-guided dialogs to put more icons on my home screen? Seriously?
This author's post is a great argument against web apps on mobile.
Agreed -- squeezing these native app elements into the document-based paradigm of the web is a horrid, Frankenstein's monster of an idea. It's like doing app development in Excel.
If native web apps are to be more of a universal thing, I believe there ought to be a blank-canvas "meta-browser" layer that sits above the browser and that all web apps (including today's browsers) are built on top of. Basically a lightweight, sandboxed pseudo-OS that offers a robust standard library, a URL scheme and easy networking support, some sort of bytecode, maybe a UI toolkit, etc. Web apps would still take up the same amount of space and would still be able to run without installing, but they would now be endowed with native performance, app-specific features, and a consistent, functional UI. (Quiz: how often do your back/forward buttons fail when using, for example, your bank's website? The fact that these two ubiquitous controls simply break the web more often than not should be telling.)
Shoehorning all that stuff into a hyperlinked, navigable document browser is insanity, and you can always feel it unless your web-app has basically reimplemented the DOM from scratch[1]. The web is currently layered upside-down and I think web apps won't lose their reputation until this is fixed.
[1]: http://engineering.flipboard.com/2015/02/mobile-web
If native web apps are to be more of a universal thing, I believe there ought to be a blank-canvas "meta-browser" layer that sits above the browser and that all web apps (including today's browsers) are built on top of. Basically a lightweight, sandboxed pseudo-OS that offers a robust standard library, a URL scheme and easy networking support, some sort of bytecode, maybe a UI toolkit, etc. Web apps would still take up the same amount of space and would still be able to run without installing, but they would now be endowed with native performance, app-specific features, and a consistent, functional UI. (Quiz: how often do your back/forward buttons fail when using, for example, your bank's website? The fact that these two ubiquitous controls simply break the web more often than not should be telling.)
Shoehorning all that stuff into a hyperlinked, navigable document browser is insanity, and you can always feel it unless your web-app has basically reimplemented the DOM from scratch[1]. The web is currently layered upside-down and I think web apps won't lose their reputation until this is fixed.
[1]: http://engineering.flipboard.com/2015/02/mobile-web
I completely disagree, to be frank.
Why do I need a native binary, tens of thousands of lines of code, an app with a massive permissions access to my device...
To read a news article?
To book a flight?
To comment on an internet post?
Adding a few more "app features" to light web pages sounds a whole lot more attractive than banishing all useful functionality into the den of apps, where only larger teams and more experienced developers can roll out even basic functionality.
Why do I need a native binary, tens of thousands of lines of code, an app with a massive permissions access to my device...
To read a news article?
To book a flight?
To comment on an internet post?
Adding a few more "app features" to light web pages sounds a whole lot more attractive than banishing all useful functionality into the den of apps, where only larger teams and more experienced developers can roll out even basic functionality.
Why do I need a native binary, tens of thousands of lines of code, an app with a massive permissions access to my device...
You don't – but why do you need loading screens, push notifications, or any of that other stuff either?
The web is great in concept for document-oriented information and some application uses. Mobile applications are greater for richer user interfaces and more device integration. They both have their strengths, and I think it's okay to accept that.
You don't – but why do you need loading screens, push notifications, or any of that other stuff either?
The web is great in concept for document-oriented information and some application uses. Mobile applications are greater for richer user interfaces and more device integration. They both have their strengths, and I think it's okay to accept that.
> loading screens, push notifications
You seem to be laser-focused on this one tiny part of PWAs. There's way more too it than that, like offline support, background sync, etc. Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it.
Or what if you could write a comment while offline, and have it be automatically posted next time you have a connection. (Or optionally, have a notification pop-up next time you're online asking if you still want to post it.)
PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native.
You seem to be laser-focused on this one tiny part of PWAs. There's way more too it than that, like offline support, background sync, etc. Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it.
Or what if you could write a comment while offline, and have it be automatically posted next time you have a connection. (Or optionally, have a notification pop-up next time you're online asking if you still want to post it.)
PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native.
> Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it.
This is available on Safari, the same browser the author is bashing and comparing to IE.
And it's synced across macOS and iOS. It's called "reading list". It works with airplane mode and everything.
This is available on Safari, the same browser the author is bashing and comparing to IE.
And it's synced across macOS and iOS. It's called "reading list". It works with airplane mode and everything.
> And it's synced across macOS and iOS. It's called "reading list". It works with airplane mode and everything.
If only we had a standard way to do this...
If only we had a standard way to do this...
> If only we had a standard way to do this...
Well it seems like either each and every website could build offline support and background sync into their site, or you could use a browser that does it for you.
In the former case, if you rely on sites integrating it, you could be frustrated when some sites do not implement background sync and offline support (or do it badly).
Having the browser do it seems simpler. Especially given the real world use cases for this feature.
(I'm not against having these technologies on the web. Just seems more sensible for a browser to do your reading list — just like it manages your tabs.)
Well it seems like either each and every website could build offline support and background sync into their site, or you could use a browser that does it for you.
In the former case, if you rely on sites integrating it, you could be frustrated when some sites do not implement background sync and offline support (or do it badly).
Having the browser do it seems simpler. Especially given the real world use cases for this feature.
(I'm not against having these technologies on the web. Just seems more sensible for a browser to do your reading list — just like it manages your tabs.)
Yeah, that sounds like a great feature. The thing is though, that feature isn't going to go away just because PWAs are a thing. The only difference with PWAs would be that sites would _also_ have the option of building offline support into the application itself rather than having to rely on one specific browser to handle that feature for them.
Not to mention PWAs would allow for more complex offline features Safari doesn't support, like syncing the front page of a news site and all associated articles, or automatically downloading new articles as soon as they're posted.
Not to mention PWAs would allow for more complex offline features Safari doesn't support, like syncing the front page of a news site and all associated articles, or automatically downloading new articles as soon as they're posted.
PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native.
I think that's where we'll have to disagree in some sense.
Adding features to the web platform will of course mean that web applications have access to more features. Some of those are great – I'm really glad we have geolocation, for example.
The trade-off is that every feature added to the platform incurs cost and complexity. Trading these off is important; what is the point in web apps that do everything native apps do, but in a somewhat less good way?
There are obviously pros and cons here, and I'm not convinced that the use cases for more complexity are beneficial enough to justify it.
I think that's where we'll have to disagree in some sense.
Adding features to the web platform will of course mean that web applications have access to more features. Some of those are great – I'm really glad we have geolocation, for example.
The trade-off is that every feature added to the platform incurs cost and complexity. Trading these off is important; what is the point in web apps that do everything native apps do, but in a somewhat less good way?
There are obviously pros and cons here, and I'm not convinced that the use cases for more complexity are beneficial enough to justify it.
"You seem to be laser-focused on this one tiny part of PWAs."
We're laser focused on the annoying parts that we know will be abused to death.
"Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it."
Most browsers already do this.
"PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native."
Because we already have native apps to do these things. I don't want websites to do these things. I want a website to be a website.
We're laser focused on the annoying parts that we know will be abused to death.
"Imagine if you could press a button on the page to save that article you're reading for later, and have it available offline next time you need it."
Most browsers already do this.
"PWAs are just flat out _better_ than existing web apps. It's remarkable to me that so many people seem to be against these incredibly useful features just because the app they're using is web-based rather than native."
Because we already have native apps to do these things. I don't want websites to do these things. I want a website to be a website.
I get plenty of push notifications from native apps that I find useful: e-mail, twitter, calendar events, chat. I can block those I don't want. That developers can't write a web app if they want as much as the option is ridiculous.
Well, actually they can, as Twitter has shown. It looks like Apple is trying to pull an Internet Explorer on us though.
Well, actually they can, as Twitter has shown. It looks like Apple is trying to pull an Internet Explorer on us though.
I don't agree with this.
Web applications are fine, and have their place. I'd argue that place is not as frequently-used, heavily interactive applications; native apps exist for that, and are better in most ways.
This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content. Other publishers insist I use their shitty JS-HTML-Hybrid nonsense because they are too stingy to develop proper applications. I wish we could learn to more effective use technologies in the right places.
Web applications are fine, and have their place. I'd argue that place is not as frequently-used, heavily interactive applications; native apps exist for that, and are better in most ways.
This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content. Other publishers insist I use their shitty JS-HTML-Hybrid nonsense because they are too stingy to develop proper applications. I wish we could learn to more effective use technologies in the right places.
Why try to dictate what developer tools are available to frequently-used, heavily interactive apps, vs the other types?
> This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content.
That's exactly the problem PWAs solve. Those publishers want some features that on iOS are only available to native apps, and so have to make the experience suck for Apple users by using an installed native app instead of a web app. Both publishers and users have an aligned interest there for PWAs, which goes against Apple's own interest.
> This is the thing – some publishers insist on using their stupid application when all I want to do is browse some content.
That's exactly the problem PWAs solve. Those publishers want some features that on iOS are only available to native apps, and so have to make the experience suck for Apple users by using an installed native app instead of a web app. Both publishers and users have an aligned interest there for PWAs, which goes against Apple's own interest.
Wouldn't you at least consider this a useful use case: Purchase a flight online on a website, but then get a push notification if there is a flight change? Why should we force a user to download an app to support that use case.
Why not just use SMS instead? It's timely, and it works even if the target device is in an overcrowded airport and can't get mobile data.
For privacy reasons, some users would prefer not to give phone numbers. From a provider perspective, sms would become a significant cost if you're sending millions of texts, while push is essentially free.
I think we agree in some sense.
> To read a news article?
I refuse to use a native app for this (e.g., Apple News, Flipboard). I love reading my news on the web. In a browser. Where the page is the content and the browser is the convenience. Even better is having Safari's "Reader Mode" enabled constantly so every article is consistently and nicely formatted and I get just the text and links.
> To book a flight?
Same thing for booking a flight, last time I did that was on a web site. With some forms and a few "Next" links to go to the next page until I was done.
It was nice to get the boarding pass in Apple Wallet though and then use that to board.
> To comment on an internet post?
I'm commenting on this post right here in Safari. I wouldn't ever want to use an app for it.
I don't need more "app features" on light web pages. Especially not the ones mentioned in the article.
> To read a news article?
I refuse to use a native app for this (e.g., Apple News, Flipboard). I love reading my news on the web. In a browser. Where the page is the content and the browser is the convenience. Even better is having Safari's "Reader Mode" enabled constantly so every article is consistently and nicely formatted and I get just the text and links.
> To book a flight?
Same thing for booking a flight, last time I did that was on a web site. With some forms and a few "Next" links to go to the next page until I was done.
It was nice to get the boarding pass in Apple Wallet though and then use that to board.
> To comment on an internet post?
I'm commenting on this post right here in Safari. I wouldn't ever want to use an app for it.
I don't need more "app features" on light web pages. Especially not the ones mentioned in the article.
Now imagine if you could do all of that faster and offline, while still avoiding the need to install a native app. That's something PWAs would enable.
On reading news articles: I can do that offline and fast right now. I add things to my reading list as I browse the web and Safari downloads them in the background. Then I can read articles when I'm offline (like on a flight). I'm a pretty voracious user of the Reading List and Reader Mode features of Safari.
On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less. And not anything frustrating.
On commenting on an Internet post: Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less. And not anything frustrating.
On commenting on an Internet post: Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
> I add things to my reading list as I browse the web and Safari downloads them in the background.
Sure, but PWAs allow for so much more than that. For example, you could not only read the article offline, but also _comment_ on it offline and have your comment automatically posted next time you have a connection. Or you could click a button to have all future articles from a particular news site automatically synced in the background while you're on WiFi so they're available for reading next time you're out; no manual downloading of each individual article required.
> On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less.
A PWA would allow much faster interaction than that. Seconds or less? That's terrible compared to the performance you _could_ be getting out of a PWA (i.e. near instant, like what you'd expect from a native app).
> Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
Sounds to me like you're already content with the experience you're getting from the web. That's fine, but it's no reason to oppose features that would make the experience even better for those of us who do want them.
Sure, but PWAs allow for so much more than that. For example, you could not only read the article offline, but also _comment_ on it offline and have your comment automatically posted next time you have a connection. Or you could click a button to have all future articles from a particular news site automatically synced in the background while you're on WiFi so they're available for reading next time you're out; no manual downloading of each individual article required.
> On booking a flight: I'm not sure how doing this offline helps? Last time I did it, I did have to wait for pages to load after clicking links but it was on the order of seconds or less.
A PWA would allow much faster interaction than that. Seconds or less? That's terrible compared to the performance you _could_ be getting out of a PWA (i.e. near instant, like what you'd expect from a native app).
> Doing it offline is not really interesting to me, and I'm not sure how that would work (which is why I'm happy to do it in a browser). Hacker News is more than fast enough. It's really minimal.
Sounds to me like you're already content with the experience you're getting from the web. That's fine, but it's no reason to oppose features that would make the experience even better for those of us who do want them.
I don't think a native flight booking app would be "near instant" at all.
You'd hit "Next", the screen would push over instantly. But there'd be a loading indicator right in the middle of it until the server returned the necessary data. Asynchronous apps or web sites or web apps will always need to load data from somewhere. PWA doesn't magically make loading go away.
I'm okay with adding offline support, faster loading, and all of that for web apps and sites I use in my browser. None of those features sound bad to me. In the browser.
You'd hit "Next", the screen would push over instantly. But there'd be a loading indicator right in the middle of it until the server returned the necessary data. Asynchronous apps or web sites or web apps will always need to load data from somewhere. PWA doesn't magically make loading go away.
I'm okay with adding offline support, faster loading, and all of that for web apps and sites I use in my browser. None of those features sound bad to me. In the browser.
PWAs would enable me to book a flight and comment on an internet post offline?
Yep, provided the app's developer wanted to implement such a feature: https://developers.google.com/web/updates/2015/12/background...
Why on earth do you need loading screens, push notifications, home screen icons, etc for any of that?
I booked the holiday I'm currently on to China almost entirely on an iPad, I could easily have done all of it that way, with none of these features.
I booked the holiday I'm currently on to China almost entirely on an iPad, I could easily have done all of it that way, with none of these features.
But when everything is pushed to the web the same argument applies to your browser.
> Why do I need a web app, tens of millions of lines of code, a website with massive permissions to my browser.
> To read a news article?
> ...
> Why do I need a web app, tens of millions of lines of code, a website with massive permissions to my browser.
> To read a news article?
> ...
Because the web app is portable across OS'es to start with.
A lot of the time web apps aren't even portable across different browsers...so...YMMV in regards to the whole portability thing.
> A lot of the time
That was the case in the 90s, and hasn't been the case since. "Some times, that are so rare that people point to it and comment on it on forums", yes.
That was the case in the 90s, and hasn't been the case since. "Some times, that are so rare that people point to it and comment on it on forums", yes.
It's a day to day occurrence, within Web development teams who have different preferences in browser. I've witnessed it in multi companies over the last decade. If you've not noticed it, then it's highly likely you're not testing outside of a single browser. The fact that you think this is a 90s issue shows that you're either extremely junior and arrogant, or totally out of touch with modern Web development. Either that or in denial. Sorry if that sounds harsh, but if nobody says it too you then you're going to continue on in a sorry little bubble of ignorance.
If you're talking of the need to use polyfills, and test in multiple versions of multiple browsers before pushing to production, I think it's incomparable to having to write multiple native apps.
If you're talking about fonts rendering differently, or some line being some pixels further to the right, same thing; incomparable.
If you're talking about corporate web apps written for IE, those aren't accessible from a phone anyway, so the distinction between native and web app is meaningless for them.
If, instead, you're talking of websites that really don't work on a modern browser, and you stumble on them day to day, you just have an experience that's different from most other people. The easiest way to tell that what I'm telling you isn't just my individual experience is to compare what you see and read today from what used to be the case in the days of IE domination.
Acting like a dick that thinks people that disagree with you are in a sorry little bubble of ignorance is just a character flaw; nothing to do with this.
If you're talking about fonts rendering differently, or some line being some pixels further to the right, same thing; incomparable.
If you're talking about corporate web apps written for IE, those aren't accessible from a phone anyway, so the distinction between native and web app is meaningless for them.
If, instead, you're talking of websites that really don't work on a modern browser, and you stumble on them day to day, you just have an experience that's different from most other people. The easiest way to tell that what I'm telling you isn't just my individual experience is to compare what you see and read today from what used to be the case in the days of IE domination.
Acting like a dick that thinks people that disagree with you are in a sorry little bubble of ignorance is just a character flaw; nothing to do with this.
> I think it's incomparable to having to write multiple native apps.
It's not comparable to writing multiple native apps, but it's the exact same model as having to use cross-platform toolkits like QT. The web has just replaced OS with browser.
> taking about fonts rendering differently
This mimics what happens when using something like QT or Java since they at least try look kind of like the platform they're running on.
> talking about corporate web apps written for IE
IE & Chrome specific features are exactly kinds of things that make cross-browser development just like cross-platform development. Your site either has to use the lowest common denominator or be littered with platform ... err browser specific code -- exactly like native apps.
It's not comparable to writing multiple native apps, but it's the exact same model as having to use cross-platform toolkits like QT. The web has just replaced OS with browser.
> taking about fonts rendering differently
This mimics what happens when using something like QT or Java since they at least try look kind of like the platform they're running on.
> talking about corporate web apps written for IE
IE & Chrome specific features are exactly kinds of things that make cross-browser development just like cross-platform development. Your site either has to use the lowest common denominator or be littered with platform ... err browser specific code -- exactly like native apps.
There is that, and then there are performance intensive apps, and everything in between.
Apple is ensuring that most of its ecosystem is fast and pleasant.
Apple is ensuring that most of its ecosystem is fast and pleasant.
Fast and pleasant are useful tools to Apple's goal of making a lot of money, which is not bad per se.
The author got it right:
> Apple treats web apps like second class citizens because they don’t generate money like native apps in the app store.
There won't be good support for web apps unless they find a way to make money out of them. If the day comes that native apps don't make money anymore, maybe because everybody gives them for free as front end to services paid outside the Apple Store (think Slack), then Apple could improve Safari and live only with revenues from the hardware.
It's going to be a hard fight because the goals of Apple and the goals of developers (and maybe also the goal of their customers) are not aligned and they own the platform.
The author got it right:
> Apple treats web apps like second class citizens because they don’t generate money like native apps in the app store.
There won't be good support for web apps unless they find a way to make money out of them. If the day comes that native apps don't make money anymore, maybe because everybody gives them for free as front end to services paid outside the Apple Store (think Slack), then Apple could improve Safari and live only with revenues from the hardware.
It's going to be a hard fight because the goals of Apple and the goals of developers (and maybe also the goal of their customers) are not aligned and they own the platform.
Sometimes I, too, pine for the days of "hyperlinks, text and images"-only web. So I turn off Javascript.
You can too, if that's how you want to consume the web. That's the beauty of it - it allows for that by design.
What I don't like is the position you are taking that "because I only want to consume the web that way, the Web itself should be hamstrung to my limited view of how it should work." There is no good reason - when the capability exists - that the Web as a platform should be chaste with things like Offline-first and even push messages (which IMHO are a big privacy win over the current mode of getting updates about things you're interested in, because you can't ungive someone your email address but you can easily turn off notification channels.) "Because that's not the way I want to consume the web" is not a good enough reason to deny the rest of us who want to see the Web continue as a modern and relevant platform. If you feel like shouting "get off my lawn" at the kids using those things, just flip off JS.
You can too, if that's how you want to consume the web. That's the beauty of it - it allows for that by design.
What I don't like is the position you are taking that "because I only want to consume the web that way, the Web itself should be hamstrung to my limited view of how it should work." There is no good reason - when the capability exists - that the Web as a platform should be chaste with things like Offline-first and even push messages (which IMHO are a big privacy win over the current mode of getting updates about things you're interested in, because you can't ungive someone your email address but you can easily turn off notification channels.) "Because that's not the way I want to consume the web" is not a good enough reason to deny the rest of us who want to see the Web continue as a modern and relevant platform. If you feel like shouting "get off my lawn" at the kids using those things, just flip off JS.
That's true. I have started getting a militant attitude towards web apps and I really shouldn't think like that.
I use web apps every day (JIRA, CircleCI, Slack, Google Docs). And reflecting on it, Google Docs has always been pretty damn good.
But I get irked every single time I try to do something like paste an image, or drag-and-drop, or lookup in the system dictionary and it just fails or works weirdly. I let those annoyances blind me to the value that these web apps provide.
I want the web to continue as a modern and relevant platform. But I don't see the point of trying to "escape" the browser chrome, or trying to copy the look and feel of native apps. If web apps are going to be cross-platform then they should embrace not being truly integrated with any native platform.
The article we are commenting on feels focused on making web apps "more like" native apps. I do not like that direction at all. I don't need, or want, to pretend my web apps are just like native apps. Because they never will be, and putting them side-by-side on my home screen with launch images will just increase my expectations of them to behave natively, and my annoyance with them when they fail to do so.
I use web apps every day (JIRA, CircleCI, Slack, Google Docs). And reflecting on it, Google Docs has always been pretty damn good.
But I get irked every single time I try to do something like paste an image, or drag-and-drop, or lookup in the system dictionary and it just fails or works weirdly. I let those annoyances blind me to the value that these web apps provide.
I want the web to continue as a modern and relevant platform. But I don't see the point of trying to "escape" the browser chrome, or trying to copy the look and feel of native apps. If web apps are going to be cross-platform then they should embrace not being truly integrated with any native platform.
The article we are commenting on feels focused on making web apps "more like" native apps. I do not like that direction at all. I don't need, or want, to pretend my web apps are just like native apps. Because they never will be, and putting them side-by-side on my home screen with launch images will just increase my expectations of them to behave natively, and my annoyance with them when they fail to do so.
" ...I don't see the point of trying to "escape" the browser chrome, or trying to copy the look and feel of native apps. If web apps are going to be cross-platform then they should embrace not being truly integrated with any native platform."
I kinda feel you on that one - and to be honest, I'm not sure how you would "turn that off" but if memory serves I think it only happens if you opt to "add to home screen" which Chrome only prompts for things you visit a lot.
I kinda feel you on that one - and to be honest, I'm not sure how you would "turn that off" but if memory serves I think it only happens if you opt to "add to home screen" which Chrome only prompts for things you visit a lot.
I had an idea for a tiny app a while ago. It didn't have business potential and was certainly not something I would bother putting in the App Store (let alone trying to figure out how to make the equivalent in Java and submit to Play Store).
I could easily have made it in HTML and JS except it required access to the camera which Mobile Safari doesn't (well didn't, I think maybe it has changed now) allow. So I ended up doing nothing.
Now, that's obviously just an anecdote and the world is at worst one useless app down but I think it makes for a good example as to why arguing against these improvements is silly: it's not in order to make websites more app-like, it's to allow things that would otherwise not exist. Yes, we should all write everything natively if we could, but sometimes that will just mean that things won't be developed at all.
I could easily have made it in HTML and JS except it required access to the camera which Mobile Safari doesn't (well didn't, I think maybe it has changed now) allow. So I ended up doing nothing.
Now, that's obviously just an anecdote and the world is at worst one useless app down but I think it makes for a good example as to why arguing against these improvements is silly: it's not in order to make websites more app-like, it's to allow things that would otherwise not exist. Yes, we should all write everything natively if we could, but sometimes that will just mean that things won't be developed at all.
Look at it from the opposite perspective though: "because I only want to develop webapps, the web itself should be bloated to contain everything I need to create apps already possible elsewhere."
"Because that's not the way I want to develop" is not a good enough reason to increase complexity, security footprint, and unintended side effects.
"Because that's not the way I want to develop" is not a good enough reason to increase complexity, security footprint, and unintended side effects.
That's cheeky. "because I only want to develop webapps, the web itself should be bloated to contain everything I need to create apps already possible elsewhere."
I think the point is rather that single-codebase "productivity apps" that satisfy basic modern experience expectations (like "I could run it offline") are not possible elsewhere - but they should be. And they would be, if some browser vendors cared about the web more than their walled garden.
Also, the thing about expanding the Open Web Platform is that the new features that are available to me don't take anything away from you if you don't want to use them. Keep making static sites if that's what suits your purpose and don't register any ServiceWorkers or any other things you consider "bloat". (As an aside - As fashionable as it has become to moan about Web "bloat" let's strive to remember that the Web standards are debated and governed by committees of consummate experts mostly in the open.) If we expand the Web platform we can both develop "the way we want" (assuming you want to keep doing things the way you have and I want to use new features).
I think the point is rather that single-codebase "productivity apps" that satisfy basic modern experience expectations (like "I could run it offline") are not possible elsewhere - but they should be. And they would be, if some browser vendors cared about the web more than their walled garden.
Also, the thing about expanding the Open Web Platform is that the new features that are available to me don't take anything away from you if you don't want to use them. Keep making static sites if that's what suits your purpose and don't register any ServiceWorkers or any other things you consider "bloat". (As an aside - As fashionable as it has become to moan about Web "bloat" let's strive to remember that the Web standards are debated and governed by committees of consummate experts mostly in the open.) If we expand the Web platform we can both develop "the way we want" (assuming you want to keep doing things the way you have and I want to use new features).
It was a bit tongue in cheek, but I was trying to show that there's two sides to this: developers and consumers.
Developing for a single platform and being able to run everywhere is great. I'm not sure what your "not possible elsewhere" is referring to, though. Java is one example of a language that's possible to deploy pretty much everywhere. Or do you mean natively in a browser?
While it's true that as a developer I'm free to use or not use any newly-introduced features and standards, as a consumer I don't have that choice. I either continue to use the sites and services I did before they changed everything, or I have to find an alternative which may not exist. Remember all the sites that required flash to run? That's what I want to avoid with responsive web apps.
Developing for a single platform and being able to run everywhere is great. I'm not sure what your "not possible elsewhere" is referring to, though. Java is one example of a language that's possible to deploy pretty much everywhere. Or do you mean natively in a browser?
While it's true that as a developer I'm free to use or not use any newly-introduced features and standards, as a consumer I don't have that choice. I either continue to use the sites and services I did before they changed everything, or I have to find an alternative which may not exist. Remember all the sites that required flash to run? That's what I want to avoid with responsive web apps.
"I think the point is rather that single-codebase "productivity apps" that satisfy basic modern experience expectations (like "I could run it offline") are not possible elsewhere - but they should be."
Why?
"Also, the thing about expanding the Open Web Platform is that the new features that are available to me don't take anything away from you if you don't want to use them. "
As a user, they do. If you go whole hog on the PWA stuff, then I no longer have the regular website you used to have.
Why?
"Also, the thing about expanding the Open Web Platform is that the new features that are available to me don't take anything away from you if you don't want to use them. "
As a user, they do. If you go whole hog on the PWA stuff, then I no longer have the regular website you used to have.
There is one good reason. The web is a large ecosystem, and we're all living in it. You have a right to express your opinion about its development, and as a responsible inhabitant of that ecosystem, you should exercise that right.
Or, in other words, since we live in it, if the web turns into shit (even more than it already has), we'll have to live in that shit.
Or, in other words, since we live in it, if the web turns into shit (even more than it already has), we'll have to live in that shit.
I said they couldn't express their opinion? No - I even validated it by saying "sometimes I feel like that, too" and prescribed a simple remedy that would cure the problem: turn off JS.
My opinion, since we're expressing them as responsible inhabitants of the Web, is that bringing the web to feature parity with mobile apps - in a responsible and well-governed way as I believe the standards committees who worked on the ServiceWorker spec have done - does more to keep it relevant and provide good User Experiences than forcing devs to try to match user expectations without the facilities.
Since we're expressing opinions, here's another one: Apple is purposefully dragging their feet by not implementing these things fully on Safari because they want to protect their precious walled garden as long as they can to the detriment of everyone else using the web.
Back to the original point I made - if you are concerned about the things being bolted on to the web "turning it to shit" you can turn them off. Maybe the UA vendors should make that easier to do, or easier to do selectively? That's an opinion you could express to them.
My opinion, since we're expressing them as responsible inhabitants of the Web, is that bringing the web to feature parity with mobile apps - in a responsible and well-governed way as I believe the standards committees who worked on the ServiceWorker spec have done - does more to keep it relevant and provide good User Experiences than forcing devs to try to match user expectations without the facilities.
Since we're expressing opinions, here's another one: Apple is purposefully dragging their feet by not implementing these things fully on Safari because they want to protect their precious walled garden as long as they can to the detriment of everyone else using the web.
Back to the original point I made - if you are concerned about the things being bolted on to the web "turning it to shit" you can turn them off. Maybe the UA vendors should make that easier to do, or easier to do selectively? That's an opinion you could express to them.
I use the Facebook site added to my homescreen rather than a native app. Uses way less space & does everything I want Facebook to be able to do.
I don't want push notifications from every site, but in this case it's valuable.
I wish it worked offline-first, but I know it's something they're looking at.
I don't want push notifications from every site, but in this case it's valuable.
I wish it worked offline-first, but I know it's something they're looking at.
I'm the same - I've generally taking to avoiding native apps wherever it's possible. So I don't have the Twitter app anymore as Twitter is now a PWA: https://blog.twitter.com/engineering/en_us/topics/open-sourc...
Similarly Facebook is just fine without the app and I'm happy with it. It has notifications etc. I'd like it if it was offline first but I'm more than happy with it as is.
Similarly Facebook is just fine without the app and I'm happy with it. It has notifications etc. I'd like it if it was offline first but I'm more than happy with it as is.
As a counterpoint, I'm reading and commenting in this thread using a dedicated native app for reading HN. I find the whole experience to be better. Loading HN in a mobile browser is just painful by comparison.
Native apps are the new desktop apps. OK for gaming, overkill and gaping privacy hole for everything else.
Because web apps are certainly very good at protecting privacy.
"To read news on this site, you must give permission to:
Your phone
Your camera
All your files
"
I've never seen that on a web app, but it's de rigeur for native mobile.
Meanwhile webapps can potentially report on everything you do that touches your browser and at most you might have to acknowledge a cookie stored on your browser.
News readers requesting that level of access is bad, but at least they tell you when they're invading your privacy.
News readers requesting that level of access is bad, but at least they tell you when they're invading your privacy.
This mirrors my view as well. Using the browser as a terrible, partially functional app server as though it were some kind of gimpy VM is one of the worst things to have happened in this industry.
Building what should be simple dynamic websites as native apps is as bad. Many things that are "appified" seem to me to be too complicated when developed as web apps and have too simplistic a use case when developed as native ones for mobile.
Building what should be simple dynamic websites as native apps is as bad. Many things that are "appified" seem to me to be too complicated when developed as web apps and have too simplistic a use case when developed as native ones for mobile.
> Why do I want these things, as a user. App loading screens?
Maybe because it's a business app, and the loading screen checks whether you are on intranet (corp wifi) or not.
> I don't want push notifications, I barely enable them for native apps.
I would enable them for important apps (eg. business apps), so I want the technology, but I absolutely hate the popups on news sites for notifications.
So nobody wants that on mobile, but they still want to be able to use notifications when they start using an app from which they want to get notifications. It's that simple.
Let's say a fitness app. Let's say a basic simple fucking calendar app. Or a whatever run of the mill business workflow shit app, that requires your attention from time to time. And it'd be easier if there were no need to build for every fucking platform.
> why would I want to make the web worse by sticking icons for pages on my home screen?
Maybe people have great spatial memory (I like organizing icons on my home screen on Android), maybe you don't want to type?
> And browser-guided dialogs to put more icons on my home screen? Seriously?
Yeah. Consistent UX and security. Why not? It can be OS provided.
Maybe because it's a business app, and the loading screen checks whether you are on intranet (corp wifi) or not.
> I don't want push notifications, I barely enable them for native apps.
I would enable them for important apps (eg. business apps), so I want the technology, but I absolutely hate the popups on news sites for notifications.
So nobody wants that on mobile, but they still want to be able to use notifications when they start using an app from which they want to get notifications. It's that simple.
Let's say a fitness app. Let's say a basic simple fucking calendar app. Or a whatever run of the mill business workflow shit app, that requires your attention from time to time. And it'd be easier if there were no need to build for every fucking platform.
> why would I want to make the web worse by sticking icons for pages on my home screen?
Maybe people have great spatial memory (I like organizing icons on my home screen on Android), maybe you don't want to type?
> And browser-guided dialogs to put more icons on my home screen? Seriously?
Yeah. Consistent UX and security. Why not? It can be OS provided.
> Let's say a fitness app. Let's say a basic simple fucking calendar app. Or a whatever run of the mill business workflow shit app, that requires your attention from time to time. And it'd be easier if there were no need to build for every fucking platform.
Yeah I wouldn't have been a Mac or iOS user if I wasn't anal about every single app on my system being a good citizen. From the simple fucking calendar app, fitness app, or whatever. I expect the developers of those apps to be as passionate about the pixels I interact with as I am.
Attention to detail is a reason these platforms are so loved. Encouraging "simple fucking calendar" apps to disregard the platform in their design is exactly the opposite reason I chose this platform to begin with.
> And it'd be easier if there were no need to build for every fucking platform.
It's easier to build badly for every platform. But no matter what technology stack you choose, if you want to build well for every platform then you are in for a lot of work. Cross platform is not going to make it easier because writing code is not the hard part.
Yeah I wouldn't have been a Mac or iOS user if I wasn't anal about every single app on my system being a good citizen. From the simple fucking calendar app, fitness app, or whatever. I expect the developers of those apps to be as passionate about the pixels I interact with as I am.
Attention to detail is a reason these platforms are so loved. Encouraging "simple fucking calendar" apps to disregard the platform in their design is exactly the opposite reason I chose this platform to begin with.
> And it'd be easier if there were no need to build for every fucking platform.
It's easier to build badly for every platform. But no matter what technology stack you choose, if you want to build well for every platform then you are in for a lot of work. Cross platform is not going to make it easier because writing code is not the hard part.
With cross-platform [Web or even native but shimmed] APIs even the "badly" written apps could be better.
I want to be passionate, but - let's say - I know CSS/HTML/Java and a bit of C#, and so while I could spend time building an Android app and maybe fiddle a bit with a Windows Phone app, but there's no way in hell that I want to venture into OS X territory, ObjectiveC creeps me out more than Haskell and f#, so I can't. (Okay, Swift is nice, but I'm still not allowed in the closed garden, because I don't have access to Xcode.)
I would gladly pay the 100 USD for the Apple Store Developer privilege if I'd get to use nice Web APIs. It can be whitelisted on the Store settings, and it can even integrate into the store, that'd be almost better.
I want to be passionate, but - let's say - I know CSS/HTML/Java and a bit of C#, and so while I could spend time building an Android app and maybe fiddle a bit with a Windows Phone app, but there's no way in hell that I want to venture into OS X territory, ObjectiveC creeps me out more than Haskell and f#, so I can't. (Okay, Swift is nice, but I'm still not allowed in the closed garden, because I don't have access to Xcode.)
I would gladly pay the 100 USD for the Apple Store Developer privilege if I'd get to use nice Web APIs. It can be whitelisted on the Store settings, and it can even integrate into the store, that'd be almost better.
Push notifications and home-screen icons are strictly opt-in. If you don't want them, don't opt, simple as. I use webapps for several things because I can much better protect myself from tracking and data-harvesting with a well-configured browser than I can using a native app.
As I said, desktop Safari allows websites to prompt me for push notifications.
I can't stand it: that a web site has the ability to display a modal prompt sheet that I have to cancel.
I can't stand it: that a web site has the ability to display a modal prompt sheet that I have to cancel.
There's a preference to disable this, though. Don't get me wrong - it's awful and I hate it. But I'm sure there are valid use-cases for people who use e.g. webmail.
This isn't new. Desktop browsers have been showing modal prompts via the javascript `prompt()` method for quite some time.
> This isn't new.
Just because it is old doesn't make it a good user experience.
Just because it is old doesn't make it a good user experience.
It's not coincidental that the ability to do so has been actively limited by so many browsers (with opt-out forever options in some cases).
It's not modal (like `alert`), it doesn't steal focus, at least not on any browser I've used.
Disable it.
It's a feature some people like and use. I like getting notifications from some services I use without needing to keep a browser window open on that page to get notified. And I like not having to download and install yet another flipping app to get that feature.
It's a feature some people like and use. I like getting notifications from some services I use without needing to keep a browser window open on that page to get notified. And I like not having to download and install yet another flipping app to get that feature.
I cant imagine a service that you frequent enough to want push notifications but not enough that you would be willing to install a native app for a smoother experience.
Installing an app is not a smoother experience. Allowing notifications is one click. Also, apps don't always have the same features as websites. You also make the assumption that services I use with browser notifications also have apps. This is not true in the slightest. And in some cases, I still prefer the website over an app.
How is it hard to imagine a service I don't frequent use but when I do, I want notifications? I use these services a few times a year at most. Why would I want to install an app if they have it?
How is it hard to imagine a service I don't frequent use but when I do, I want notifications? I use these services a few times a year at most. Why would I want to install an app if they have it?
One where the developer does not have enough resources to develop for and support multiple platforms?
Right, but the parent's argument is that web notifications are a way to avoid installing a native app.
My argument is not limited to some thin line you define. Please don't speak for me or put words in my mouth that are not true.
You get it.
> I cant imagine a service that you frequent enough to want push notifications but not enough that you would be willing to install a native app for a smoother experience.
Um. Email?
Um. Email?
The answer is, you don't want those things. 95% of web applications shouldn't use push notifications, add to home screen dialogs or app loading screens. They're annoying.
Now imagine a world where PWA is substantially implemented across all major browsers. Given this scenario, let's pretend Mark Zuckerberg invented Facebook in that environment. There's the case for PWA - some apps are more engaging (for better or worse) with push notifications, home screen access, offline functionality, and optimistic UI updates.
Do I care if my favorite blogs have push notifications? No. Do I care if my favorite social networks and messaging apps have push notifications? Yes.
Now imagine a world where PWA is substantially implemented across all major browsers. Given this scenario, let's pretend Mark Zuckerberg invented Facebook in that environment. There's the case for PWA - some apps are more engaging (for better or worse) with push notifications, home screen access, offline functionality, and optimistic UI updates.
Do I care if my favorite blogs have push notifications? No. Do I care if my favorite social networks and messaging apps have push notifications? Yes.
"The web" is a broad concept, but we should break it down to two distinct things: websites and web apps.
You don't need all these extra features for a website. However, they are useful and needed for many web apps. Just because websites sometimes abuse these features doesn't make them bad.
You don't need all these extra features for a website. However, they are useful and needed for many web apps. Just because websites sometimes abuse these features doesn't make them bad.
I think this is such an important distinction that we should build it into web standards.
A site should label itself as either a "plain site" or a "web app". "Sites" may only use a limited subset and amount of javascript (perhaps none?!). Browsers, search engines, and plugins can treat plain sites and web apps differently.
A site should label itself as either a "plain site" or a "web app". "Sites" may only use a limited subset and amount of javascript (perhaps none?!). Browsers, search engines, and plugins can treat plain sites and web apps differently.
>A site should label itself as either "just a site" or a "web app". "Sites" may only use a limited subset and amount of javascript (perhaps none?!). Browsers, search engines, and plugins can treat sites and web apps differently.
I too dislike the fact that web developers have the freedom to make design decisions with which I disagree.
I too dislike the fact that web developers have the freedom to make design decisions with which I disagree.
If the goal is to let developers make more design decisions, shouldn't we give websites root access to the machine by default?
any site with a login is probably already self-identifying to some degree.
I don't care much for notifications either. Offline support is pretty great though. Even when online, page load speed tends to be faster.
I was wondering what prevents someone from sending an initial app UI?
As a developer, I would love push notifications in safari. The only alternative is a native app, which is much more work.
As a user, I think crappy or unethical web developers would ruin it for everybody. At least with native apps, there's a somewhat consistent way for me to manage notifications (and I have 95% of them turned off).
So why don't you support the OP then? If Apple got behind PWA development you would see a similar menu for websites.
whats the issue if you're granting permission for them though? just say no if it's from Buzzfeed, yes if it's from my XYZ service - that's all it takes. And - I would expect notification management would need to be similarly accessible.
Notifications are tough to do as is - and a core user need. You and I might turn them off, but many people rely on them heavily. If I have responsive web app with notifications - that's the dream for me. because I don't want to have to build a native app JUST for that. Nor, should many others need to.
Notifications are tough to do as is - and a core user need. You and I might turn them off, but many people rely on them heavily. If I have responsive web app with notifications - that's the dream for me. because I don't want to have to build a native app JUST for that. Nor, should many others need to.
I may be wrong about this, but it seems like waking up a web app periodically to check for notifications would use a lot more power (and maybe data) than it does for a native app. Web apps in general are going to be less efficient, aren't they?
So a web app is easier for you, but aren't you really just transferring the cost to your users in the form of battery and data consumption?
So a web app is easier for you, but aren't you really just transferring the cost to your users in the form of battery and data consumption?
Well, I wouldn't go so far as to say a lot more power - and apple could potentially integrate it with their existing push service.
Would it be, in a way, pushing costs onto users? potentially. But, it's a matter of shipping something that works at the loss of some battery and data usage (minimal) or spending 6 months to a year learning and developing a native app which is more efficient for end users. But both approaches are subject to market validation - one lets you reach validation quickly, the other requires quite a detour.
So, I'd rather not throw away all that time. If I can get notifications that work, even if only checked every 10 minutes vs. instant, I would be happy. Then, if there is market fit and proper demand, I can likely afford the time/money to build out a native experience.
Would it be, in a way, pushing costs onto users? potentially. But, it's a matter of shipping something that works at the loss of some battery and data usage (minimal) or spending 6 months to a year learning and developing a native app which is more efficient for end users. But both approaches are subject to market validation - one lets you reach validation quickly, the other requires quite a detour.
So, I'd rather not throw away all that time. If I can get notifications that work, even if only checked every 10 minutes vs. instant, I would be happy. Then, if there is market fit and proper demand, I can likely afford the time/money to build out a native experience.
All browsers still suck at basic functionality.
Here's a quick short list of things that developers still have to write because the current implementations are broken, buggy, inconsistent or absent:
- Date pickers.
- Image upload [1].
- Autocomplete and datalist.
- Range pickers.
- Upload time remaining without javascript.
- Number min/max/step, use up/down keys to increment/decrement.
- Form elements that are unable be styled by CSS.
- Color picker (arguably not as important as the others, and some OS color pickers suck anyway).
[1] Basic things like resize image on the browser prior to uploading. Size, aspect ratio, crop could be hinted by the html or chosen by the user. Server check is still needed, but upload size and times would be reduced drastically.
Shouldn't those be more important?
Here's a quick short list of things that developers still have to write because the current implementations are broken, buggy, inconsistent or absent:
- Date pickers.
- Image upload [1].
- Autocomplete and datalist.
- Range pickers.
- Upload time remaining without javascript.
- Number min/max/step, use up/down keys to increment/decrement.
- Form elements that are unable be styled by CSS.
- Color picker (arguably not as important as the others, and some OS color pickers suck anyway).
[1] Basic things like resize image on the browser prior to uploading. Size, aspect ratio, crop could be hinted by the html or chosen by the user. Server check is still needed, but upload size and times would be reduced drastically.
Shouldn't those be more important?
Nope, they are not more important because you can easily fix those by installing an appropriate javascript library. We are talking here about functionality that a developer can't possibly fix if it's broken.
My theory is that the next big "thing" with web browsers will be to integrate a widget kit that simplifies these sorts of things. Like a stripped down version of Qt. I've made this comment before, and someone said Java Swing, and, yeah, but I still think there's an opportunity here.
Sounds to me like a suitable use case for WebComponents.
Actually www could benefit a lot from - touch versions of basic input elements - like on/off switches , ranges, color pickers, datetime pickers etc.
Original www is very successful at mouse-based UX, but horrible at touch based.
Actually browsers could agree on a dozen touch based standard input elements and we don't need 80% this JS framework cruft.
Original www is very successful at mouse-based UX, but horrible at touch based.
Actually browsers could agree on a dozen touch based standard input elements and we don't need 80% this JS framework cruft.
In an ideal world I think browsers would have removed most non-click-related JS events (including timers) and AJAX calls, but provided way better native form elements. Also kept improving frames rather than letting them stagnate and die. The web'd be far better if they'd gone that direction rather than the full (terrible) app delivery platform.
You can add the impossibility to customize the scrollbar...
Maybe I'm just an old fogey but I don't like Progress Web Apps. I think this whole movement of trying to make web apps more native-like is wrong headed and stems only from developers who have only ever written web apps wanting to write native apps but not wanting to learn how to do it properly.
As a user I don't want to have web apps giving me notifications or having loading screens. I have always liked that the web was tightly sandboxed and limited in what it can do. The nature of the web; where when I follow a link I'm basically installing your application -- sight unseen -- means that what your app can do needs to be tightly controlled and limited.
As a developer, if I want to make a native app for any platform, I'll write a native app. If you don't want to learn Objective-C or Swift, that's fine. There's plenty of ways to write Native applications iOS using cross platform languages like C++.
Frankly, those languages are easier to write testable, dependable code in than JavaScript anyway.
As a user I don't want to have web apps giving me notifications or having loading screens. I have always liked that the web was tightly sandboxed and limited in what it can do. The nature of the web; where when I follow a link I'm basically installing your application -- sight unseen -- means that what your app can do needs to be tightly controlled and limited.
As a developer, if I want to make a native app for any platform, I'll write a native app. If you don't want to learn Objective-C or Swift, that's fine. There's plenty of ways to write Native applications iOS using cross platform languages like C++.
Frankly, those languages are easier to write testable, dependable code in than JavaScript anyway.
PWAs and any of those Javascript-powered "apps" are shit. I am glad Apple is against them. Even the best JS apps with perfect UX (those are rare, but they exist) still feel relatively slow compared to a native counterpart.
I don't want to pay with UX if some "developers" can't be bothered to learn new languages and insist on doing JS everywhere.
I don't want to pay with UX if some "developers" can't be bothered to learn new languages and insist on doing JS everywhere.
"all sorts of great features that you’d normally associate with native apps, like push notifications, offline support, and app loading screens — but on the web! Awesome."
I didn't know app loading screens were "a great feature".
Anyway I really don't see the point of PWAs or much future for them anyway. Even if Apple started supporting these with Safari, the web apps still could not interact with different hardware components/sensors, iOS SDK's etc.
React Native already brought a platform which allows making apps with native components and good performance with JS + decent access to hardware and iOS and still it's barely used outside of hobby projects.
I'm sorry, but native apps aren't going anywhere.
I didn't know app loading screens were "a great feature".
Anyway I really don't see the point of PWAs or much future for them anyway. Even if Apple started supporting these with Safari, the web apps still could not interact with different hardware components/sensors, iOS SDK's etc.
React Native already brought a platform which allows making apps with native components and good performance with JS + decent access to hardware and iOS and still it's barely used outside of hobby projects.
I'm sorry, but native apps aren't going anywhere.
https://facebook.github.io/react-native/showcase.html
It's used in a lot more than just hobby projects.
It's used in a lot more than just hobby projects.
> "I didn't know app loading screens were "a great feature".
Loading screens are obviously a good thing when lots of assets need to be loaded for a game. The presentation can inform the user where things are at in the process of fetching those items. Flash could do it quite well.
Isn't that obvious though? A loading screen is informative and functional.
Loading screens are obviously a good thing when lots of assets need to be loaded for a game. The presentation can inform the user where things are at in the process of fetching those items. Flash could do it quite well.
Isn't that obvious though? A loading screen is informative and functional.
the web apps still could not interact with different hardware components/sensors
Why not? WebUSB already shows otherwise.
Why not? WebUSB already shows otherwise.
Web Bluetooth too.
As an iOS user, one thing I surely don't want are more web apps. The web is for content (including APIs Robbe used by native apps) not for apps, if on desktop or mobile. Here's why:
- lower performance. It can't be as fast as native as long as there's still the browser underneath - non-native experience. I use iOS because I like it better than android. I like the UI and UX, how it looks and feels. I don't want an web app, with an UI feeling different, looking different and behaving different. - multi-platform. All platforms will never have the same capabilities and features. You will always have to use the least common denominator or hack your things around.
Apple provides ObjC and Swift, the latter being a terrific way to develop apps, in my humble opinion a far better language and environment than JS (or JS). Just use it, your users will thank you.
- lower performance. It can't be as fast as native as long as there's still the browser underneath - non-native experience. I use iOS because I like it better than android. I like the UI and UX, how it looks and feels. I don't want an web app, with an UI feeling different, looking different and behaving different. - multi-platform. All platforms will never have the same capabilities and features. You will always have to use the least common denominator or hack your things around.
Apple provides ObjC and Swift, the latter being a terrific way to develop apps, in my humble opinion a far better language and environment than JS (or JS). Just use it, your users will thank you.
> It can't be as fast as native as long as there's still the browser underneath - non-native experience.
This is going to radically change with Webassembly, stay tuned.
This is going to radically change with Webassembly, stay tuned.
I'll just recycle a comment from a few days ago, it's (un)surprisingly fitting:
"You know the rule, Apple ALWAYS gets a pass. No matter what they do, no matter how bad they treat their customers, no matter how awful their "upgrades" are, no matter how non-configurable and locked-in their products get over time, no matter the lack of innovation for the past 5 years, they always get a pass. Deal with it, that Jobs residue works its magic for a loooooong time."
"You know the rule, Apple ALWAYS gets a pass. No matter what they do, no matter how bad they treat their customers, no matter how awful their "upgrades" are, no matter how non-configurable and locked-in their products get over time, no matter the lack of innovation for the past 5 years, they always get a pass. Deal with it, that Jobs residue works its magic for a loooooong time."
That's not because of Jobs. It's because Apple customers are most of the people that will accept that kind of behavior.
Keeping that attitude means that Apple can not grow¹, but not that it will shrink.
1 - All the times they acquired a lot of market share, they weren't doing that.
Keeping that attitude means that Apple can not grow¹, but not that it will shrink.
1 - All the times they acquired a lot of market share, they weren't doing that.
This is a frustrating article - the issue really is that Safari doesn't support Service Workers and Web App Manifests, which are the canonical way of making PWAs.
Safari should support Service Workers[1], because they allow you to safely intercept and modify navigation and resource requests, and cache resources in a very granular fashion, securely and on a different thread to your app JS. This is great for performance and offline/spotty reception.
The Web App Manifest[2] is the file that allows developers to "appify" the site, by prompting the user to add to their home screen (only once they hit a certain usage rate), show a splash screen etc. But that's a nice to have compared to Service Workers.
[1]: https://developer.mozilla.org/en/docs/Web/API/Service_Worker...
[2]: https://developer.mozilla.org/en-US/docs/Web/Manifest
Safari should support Service Workers[1], because they allow you to safely intercept and modify navigation and resource requests, and cache resources in a very granular fashion, securely and on a different thread to your app JS. This is great for performance and offline/spotty reception.
The Web App Manifest[2] is the file that allows developers to "appify" the site, by prompting the user to add to their home screen (only once they hit a certain usage rate), show a splash screen etc. But that's a nice to have compared to Service Workers.
[1]: https://developer.mozilla.org/en/docs/Web/API/Service_Worker...
[2]: https://developer.mozilla.org/en-US/docs/Web/Manifest
What. Having a really hard time following what is exactly preventing the author from doing any of these:
> Create an app loading screen > Use push notifications > Add offline support > Create an initial app UI to load instantly > Prompt installation to the home screen through browser-guided dialog
All of these things are possible in Safari, no? It just doesn't support ServiceWorkers?
Aside: as a web security guy I think serviceworkers are a tragedy. Any crappy site you accidentally visit and immediately hit the back button on gets 10 minutes of freebie time to execute Javascript, roam your local network, exploit "slow" browser vulns, eat your bandwidth, etc. Gone are the days when the only things running Javascript are your open tabs.
> Create an app loading screen > Use push notifications > Add offline support > Create an initial app UI to load instantly > Prompt installation to the home screen through browser-guided dialog
All of these things are possible in Safari, no? It just doesn't support ServiceWorkers?
Aside: as a web security guy I think serviceworkers are a tragedy. Any crappy site you accidentally visit and immediately hit the back button on gets 10 minutes of freebie time to execute Javascript, roam your local network, exploit "slow" browser vulns, eat your bandwidth, etc. Gone are the days when the only things running Javascript are your open tabs.
OP builds part of this argument based on "Apple isn't responsive to my complaints about web apps."
Apple isn't responsive to complaints in general. Are they less responsive to web app complaints than other complaints? Otherwise, the argument holds no water.
Apple isn't responsive to complaints in general. Are they less responsive to web app complaints than other complaints? Otherwise, the argument holds no water.
Apple's actually very responsive to end user complaints. Not so much to developer complaints.
As much as this annoys me (developer for iOS) I do believe it leads to a better platform.
As much as this annoys me (developer for iOS) I do believe it leads to a better platform.
I can see why apple is hesitant to do this. But there is definitely a middle ground.
Require the same developer registration process as they currently do for iOS apps. Then require some apple provided javascript to provide access to these needed functions. App review as before.
At that point they can do interesting things: charge per 1000 installs, enforce the use of apple pay. They can operate a business model that is slightly different, but the same at its core - tax developers for access to their user base/platform.
Require the same developer registration process as they currently do for iOS apps. Then require some apple provided javascript to provide access to these needed functions. App review as before.
At that point they can do interesting things: charge per 1000 installs, enforce the use of apple pay. They can operate a business model that is slightly different, but the same at its core - tax developers for access to their user base/platform.
I don't think Apple's customers are clamoring for Progressive Web App support as much as they are wanting other features.
The average customer (of which Apple has millions worldwide) wants a device that solves some basic desires like taking pictures, making phone calls, texting, email, etc.
I don't see how this feature serves enough of those customers for Apple to care more about it than something that will sell computers (in some form or another).
The average customer (of which Apple has millions worldwide) wants a device that solves some basic desires like taking pictures, making phone calls, texting, email, etc.
I don't see how this feature serves enough of those customers for Apple to care more about it than something that will sell computers (in some form or another).
When I think "progressive web…" I think of progressive enhancement. https://en.wikipedia.org/wiki/Progressive_enhancement i.e. make regular non-JavaScript websites as a foundation and add JavaScript just to enhance that.
I suppose this is a compatible idea, but the PWA idea is based on everything going in the wrong direction generally. PWA aims to make everything "app" like even when it's not warranted. The vast majority of apps and PWAs don't need to exist at all. People don't need all this JavaScript interactive excess.
What I like about PWAs: a move away from everyone downloading ridiculous numbers of apps for each website. What I don't like about PWAs: turning websites into apps when not needed.
I suppose this is a compatible idea, but the PWA idea is based on everything going in the wrong direction generally. PWA aims to make everything "app" like even when it's not warranted. The vast majority of apps and PWAs don't need to exist at all. People don't need all this JavaScript interactive excess.
What I like about PWAs: a move away from everyone downloading ridiculous numbers of apps for each website. What I don't like about PWAs: turning websites into apps when not needed.
As much as I want PWA to rule, web apps still give a noticeable lousy experience than native especially social apps with large feeds (Facebook, Twitter). After so many decades chasing the native experience, it appears HTML/CSS/DOM needs to be revamped/replaced in order for some hope. Maybe a brand new UX library build on top of web assembly? A cross-platform user interface library on top of Unity/Unreal Engine? Why must web apps rely on browser in order to run? If there is a UX component to docker/container, does it provide similar security mechanism as a browser? Maybe this world is not meant to have only one language/UX library/delivery mechanism for apps.
Since the article did not go into details, and many of the points seem nonsensical, can someone elaborate?
Why can I not "Create an app loading screen" without service workers? Why can I not "Create an initial app UI to load instantly"? Seems these are trivially possible with regular Javascript, but maybe I'm misunderstanding?
Similarly, "Use push notifications", "Add offline support" and "Prompt installation to the home screen" do not sound like APIs that are dependent on service workers, but I guess they are? (or the article makes no sense)
(By the way, the 300ms tap delay that he gripes about can be hacked away, see fastclick.js)
Why can I not "Create an app loading screen" without service workers? Why can I not "Create an initial app UI to load instantly"? Seems these are trivially possible with regular Javascript, but maybe I'm misunderstanding?
Similarly, "Use push notifications", "Add offline support" and "Prompt installation to the home screen" do not sound like APIs that are dependent on service workers, but I guess they are? (or the article makes no sense)
(By the way, the 300ms tap delay that he gripes about can be hacked away, see fastclick.js)
I'm aware of fastclick.js, and I've been using it. I was just excited to remove an extra dependency when they removed the delay from mobile Safari. Checked it into git, deployed...then realized it was still there in fullscreen mode. My point is that they develop stuff for mobile Safari, but then leave fullscreen mode in the dust.
> Why can I not "Create an app loading screen" without service workers? Why can I not "Create an initial app UI to load instantly"? Seems these are trivially possible with regular Javascript, but maybe I'm misunderstanding?
If you're waiting on async requests than everything is fine without Service Workers, but if you're performing computation then the whole UI will be blocked.
If you're waiting on async requests than everything is fine without Service Workers, but if you're performing computation then the whole UI will be blocked.
Offline support and push notifications require service workers (or some other API that doesn't exist yet[1])
And for prompting installation, I think the author wants it to appear native.
(Apple does have their own notification API but it requires an account).
And for prompting installation, I think the author wants it to appear native.
(Apple does have their own notification API but it requires an account).
Telling your users how to add your app to the home screen should not be a thing. It makes your product look unprofessional. Prompting a user who has used the web app a bunch of times should be a thing on iOS like it is on Android.
> Apple thinks you should learn a completely different and more complex programming language (Objective-C/Swift) and maintain a completely separate code base for iOS. This effectively hurts small dev shops, stifles innovation, makes startups much more difficult to get going.
ObjC/Swift may be somewhat more complex than Javascript (or whatever) as programming languages, but one thing I like about iOS development right now is the relatively stable and well-integrated toolset.
I love web development. It's how I got started in all of this. But. The web development world is (in my eyes) currently an over-complex mess of standards and practices and tools coming from twenty different directions and sometimes changing radically from one year to the next. And I have complained before about the fact that Javascript is the primary language for using all of these. (I know, you use XXXScript which transpiles into Javascript. But that kind of adds evidence to my point, no?)
Anyway, this is not a central point to the article linked, but just something that caught my eye.
ObjC/Swift may be somewhat more complex than Javascript (or whatever) as programming languages, but one thing I like about iOS development right now is the relatively stable and well-integrated toolset.
I love web development. It's how I got started in all of this. But. The web development world is (in my eyes) currently an over-complex mess of standards and practices and tools coming from twenty different directions and sometimes changing radically from one year to the next. And I have complained before about the fact that Javascript is the primary language for using all of these. (I know, you use XXXScript which transpiles into Javascript. But that kind of adds evidence to my point, no?)
Anyway, this is not a central point to the article linked, but just something that caught my eye.
>Is this just capitalism? Looking out for their own well being? No. Apple is filthy, filthy rich.
Naive much? People and corporations don't tend to stop collecting wealth - that is, after all, how they became so filthy, filthy rich in the first place.
Naive much? People and corporations don't tend to stop collecting wealth - that is, after all, how they became so filthy, filthy rich in the first place.
I am starting to get a vibe that there is a new breed of programmers who think that knowing just one language is good enough and learning anything else is "stifling innovation".
I don't even want to start on "PWAs work more seamlessly than native". I just cannot take person making such claims seriously.
I don't even want to start on "PWAs work more seamlessly than native". I just cannot take person making such claims seriously.
This kind of scares me to. The vibe that I have is that (web)developers want to make JS into a silver bullet to solve every problem (backend nodeJS, apps react native cordova etc). But I also wonder why they don't want to learn a new language. Some languages really make you look at a problem from a different perspective and to be honest also work better then JS.
The vibe you have is wrong.
It's not about learning a new language. Most web developers are comfortable in many languages. Plase stop attacking a straw-man. Not many web developers say stuff like "omg these new things are web scale" or "oh javascript is everything I need, I hate everything else". Yeah the author didn't want to learn a new language. Which is not an insane decision at the very beginning of a project.
The biggest deal, though, is code reuse. If I'm not given enough budget, I'm not developing a native app for your precious walled-garden, sorry. I can also rightfully complain that what you have is a walled-garden, and also that the owner of the garden inhibiting a cross-platform alternative.
This has nothing to do with ignorance. Give me a cross-platform API, I'm happy.
At the end, as long as there is docs & support, most really don't care if it's Haskell or PHP.
It's not about learning a new language. Most web developers are comfortable in many languages. Plase stop attacking a straw-man. Not many web developers say stuff like "omg these new things are web scale" or "oh javascript is everything I need, I hate everything else". Yeah the author didn't want to learn a new language. Which is not an insane decision at the very beginning of a project.
The biggest deal, though, is code reuse. If I'm not given enough budget, I'm not developing a native app for your precious walled-garden, sorry. I can also rightfully complain that what you have is a walled-garden, and also that the owner of the garden inhibiting a cross-platform alternative.
This has nothing to do with ignorance. Give me a cross-platform API, I'm happy.
At the end, as long as there is docs & support, most really don't care if it's Haskell or PHP.
But can you reuse UX? UX on Android and iOS are completely different, which implies different UI, which in the end of the day implies different codebase. I do believe that it's possible to implement an app indistinguishable from native with any technology given enough time to implement all UX guidelines (voiceover support, animation dynamics like scroll list velocity constants, disability stuff, etc) but than we spend too much effort reinventing Cocoa Touch, so ROI of this endeavor is highly speculative. I hope in the future iOS and Android will be closer UX wise, which should simplify code reuse and make everyone happy.
Well the UI can be changed per platform, and as I said, it's a matter of budget. I implemented a solution like that with xamarin but it's not like web. It's way more complicated and the real problem is many things are not supported and so on... React Native? No desktop support. Qt? Oh no, it doesn't feel native... Give me a break! I'm really sick of everyone being a perfectionist and making no compromises. There are too many users, too many platforms and not many developers (at least, quality ones). Facebook can maintain 100 platforms, that doesn't solve my problem of having something "usable" (not perfect) on X platforms.
- Yeah we don't support offline mode on iOS, sorry.
- How much would it cost to implement that?
- Hmm, a rewrite plus more devices to test and licenses and... hmm. Just 50K for a start.
- What, are you kidding? I just want to enter this order when offline?!
- Yeah we don't support offline mode on iOS, sorry.
- How much would it cost to implement that?
- Hmm, a rewrite plus more devices to test and licenses and... hmm. Just 50K for a start.
- What, are you kidding? I just want to enter this order when offline?!
No single top 100 app (except those made by Google or Apple) uses the default system UI components. Google does not follow its own UX guidelines.
Everybody by now knows what a hamburger button, tabs, and toggle switches do.
Everybody by now knows what a hamburger button, tabs, and toggle switches do.
> Most web developers are comfortable in many languages.
"Walled-garden" has long ago became thought-stopping cliche. But if it is walled garden, then I am thankful that Apple does not allow to litter it with some JS scraps. All this cross-platform talk is just being cheap, being lazy or both. It save money, but it produces the lowest common denominator UX wise. And I would not be surprised that maintaining cross-platform monstrosity eats away any cost-savings pretty quickly.
You know that the need for citation goes both ways and anecdotal evidence isn't a real reference, right? Web developers know at least JS, HTML & CSS. Too many know Ruby, Python and/or PHP. Significant amount of them know C#/Java/Go or something similar. Then there is Typescript, all those compile-to-js languages and so on. I've never ever seen a web developer who could only program in JS. That would be very ridiculous. I personally can't count how many languages I worked and had to work with. My list includes ColdFusion. I'm very comfortable with at least 5 languages and 6 platforms.
> I am thankful that Apple does not allow to litter it with some JS scraps.
Oh, so much for being objective. References and all.
> All this cross-platform talk is just being cheap, being lazy or both.
Are you even serious? You really blame engineers/developers coming up with trade-offs for being cheap and/or lazy?
> And I would not be surprised that maintaining cross-platform monstrosity eats away any cost-savings pretty quickly.
No it doesn't. I'm a developer since much more than 10 years. I guess that's enough of a reference :)
> I am thankful that Apple does not allow to litter it with some JS scraps.
Oh, so much for being objective. References and all.
> All this cross-platform talk is just being cheap, being lazy or both.
Are you even serious? You really blame engineers/developers coming up with trade-offs for being cheap and/or lazy?
> And I would not be surprised that maintaining cross-platform monstrosity eats away any cost-savings pretty quickly.
No it doesn't. I'm a developer since much more than 10 years. I guess that's enough of a reference :)
I'd also add SQL to your language list, and often SASS, gulp/grunt configuration, JSON, ASP.NET, and so on.
And come on, JS is a C-style language. If you know one you know them all.
It's also not a difficult jump to OOP languages; especially now that Java 8 supported lambdas and C# supports async/await. It's hard to learn concepts, not syntax.
And come on, JS is a C-style language. If you know one you know them all.
It's also not a difficult jump to OOP languages; especially now that Java 8 supported lambdas and C# supports async/await. It's hard to learn concepts, not syntax.
Don't you agree, though, thinking that web developers don't write iOS apps because they don't want to learn Swift, is a bit ridiculous at this point? Yet another language isn't even significant for a typical web developer. For me, tooling (XCode) took more time to learn than being able to write acceptable Swift...
Yes, I agree. I was agreeing with you before as well. Setting up a Mac, learning a new IDE, and getting your tooling/builds set up is a far bigger pain point than actually learning the new language.
At least that's the case if it's logically similar. C, Java, JS, etc are mostly transferable. I might not say the same about something like Haskell.
At least that's the case if it's logically similar. C, Java, JS, etc are mostly transferable. I might not say the same about something like Haskell.
If that's the case, then we shouldn't hear any complaining about having to learn Java, ObjC or Swift.
I understand code reuse can be a hassle, but not as big as some make it out to be. One way to reduce a bunch of work is to make use of swagger for your API. Which enables you to generate a client for your languages of choice.
There's more than a whiff of that in the article, for sure. Author at one point is put off Native by having to learn a "more complicated" language, i.e. Swift. It's hard to defend the assertion that Swift is more complicated than JS.
Full disclaimer, Swift is my favourite language by a long shot and I'd love to use it everywhere, but it really is very complicated in some places.
Consider, for example, the interaction between generics in structs and classes, and protocols with associated types, and why you have to make stupid type-erasing wrappers like 'AnyObject' and so forth.
JS barely even has types at all, let alone generics. There's a lot less to go wrong there :-)
Consider, for example, the interaction between generics in structs and classes, and protocols with associated types, and why you have to make stupid type-erasing wrappers like 'AnyObject' and so forth.
JS barely even has types at all, let alone generics. There's a lot less to go wrong there :-)
A good point, won't argue with you. But, at the risk of moving the conversational goalposts, I was thinking about the whole developer experience as much as just the language itself. With Swift, you can live entirely within Apple's frameworks and libraries and be immensely productive. With JS you're going through an entire exercise of flavor and framework selection before you can start writing any code; and those decisions have a massive impact on your app's fundamental design. That's as much what I meant by complexity.
Same. I always think these people come from a planet where JS is the only language and SPAs are actually good and fun to use.
>I am starting to get a vibe that there is a new breed of programmers who think that knowing just one language is good enough
+1
We're going to end up at an "Idiocracy" of programming.
+1
We're going to end up at an "Idiocracy" of programming.
> From now on, I won’t be building any more native apps. All my apps going forward will be progressive web apps.
To be sure, the guy who wrote that has never built a native app and knows nothing of native development. That is not actually a story of a native developer being converted by PWAs.
To be sure, the guy who wrote that has never built a native app and knows nothing of native development. That is not actually a story of a native developer being converted by PWAs.
Fundamentally, it's Apple's refusal to allow real 3rd party browsers that is the problem.
Actually, 3rd party browsers are now allowed on the App Store, with a few restrictions. Previous, section 3.3.2 of the developer agreement prevented the downloading and running of any code, except for JavaScript running inside iOS's JavaScriptCore. But the June 5th agreement allows any language and interpreter.
There are two limitations. The system makes it impossible to run unsigned code, so JIT compilation is out. Also, an app can't establish its own app store, so Google would have to get special permission for the Chrome Web Store.
I'm talking about section 2.5.6, which still states "Apps that browse the web must use the appropriate WebKit framework and WebKit Javascript."
That's in the App Store Review Guidelines, not the Apple Developer Program License Agreement. But that is a good point.
However, Opera Mini has a “Mini mode”, where the parsing and JavaScript execution is done on Opera's server, which then compresses the data and sends it to the phone for display. In this mode, it does not use the WebKit framework. Opera Mini has been on the App Store since 2010.
https://techcrunch.com/2010/04/12/surprise-surprise-opera-mi...
I wonder if section 2.5.6 applies to apps that display web pages as one function among many, and not to web browsers. Maybe Apple figures that if the user hits a “Web Page” button in some app, they expect it to work just like Safari, but if they download Chrome, Firefox, or Opera Mini, they actually want the web browser to be different from Safari. But I haven't researched this yet.
However, Opera Mini has a “Mini mode”, where the parsing and JavaScript execution is done on Opera's server, which then compresses the data and sends it to the phone for display. In this mode, it does not use the WebKit framework. Opera Mini has been on the App Store since 2010.
https://techcrunch.com/2010/04/12/surprise-surprise-opera-mi...
I wonder if section 2.5.6 applies to apps that display web pages as one function among many, and not to web browsers. Maybe Apple figures that if the user hits a “Web Page” button in some app, they expect it to work just like Safari, but if they download Chrome, Firefox, or Opera Mini, they actually want the web browser to be different from Safari. But I haven't researched this yet.
This is definitely true. But in addition to this, it is insane that it appears that none of the big browsers has begun implementing encrypted storage via touch and so forth.
One of the main arguments i see in my organisation to create apps for our ventures is the fact that it will enable touch login. I recon it should be rather simple to duplicate / wrap the localStorage API to do this?
One of the main arguments i see in my organisation to create apps for our ventures is the fact that it will enable touch login. I recon it should be rather simple to duplicate / wrap the localStorage API to do this?
A lot of people here seem to be advocating the superior experience that native apps provide, but forgetting how saturated the app market is and what a poor job Apple does to help its users discover new apps.
Further, the majority of US smartphone users download zero apps in a typical month. What's the point of making a "superior" app, if no one is ever going to see it? https://qz.com/253618/most-smartphone-users-download-zero-ap...
From a user perspective, I care less about whether the app is a PWA or native, and more about the "goal" I'm trying to achieve. If my goal is to find a new house, a PWA allows me to instantly see results (without first having to download an app), then use native-like features such as being notified when new properties are available. I can use these features after I visit a given website and am prompted to save the app to my homescreen.
Compare this to the random native apps that people accumulate on their phone until it slows down so much that they have to perform an "app purge".
Further, the majority of US smartphone users download zero apps in a typical month. What's the point of making a "superior" app, if no one is ever going to see it? https://qz.com/253618/most-smartphone-users-download-zero-ap...
From a user perspective, I care less about whether the app is a PWA or native, and more about the "goal" I'm trying to achieve. If my goal is to find a new house, a PWA allows me to instantly see results (without first having to download an app), then use native-like features such as being notified when new properties are available. I can use these features after I visit a given website and am prompted to save the app to my homescreen.
Compare this to the random native apps that people accumulate on their phone until it slows down so much that they have to perform an "app purge".
Your phone slows down with too many apps installed? Maybe it's time to think about your phones OS..
(I have several hundred apps installed on my 3 year old phone, actually use most of them if only occasionally and it's still as fast as on day one, and still gets every OS update on day one. Guess what phone it is..)
The web app market is even more saturated than any app store, and people do purge their bookmarks as well.
Wow, I read a lot of hate for PWAs, I had no idea. I use them and enjoy a lot of them (mobile.twitter.com). It really depends on the app, some benefit from being PWA others would need to be native. But the idea that we shouldn't add a feature that Chrome and other browsers have just because you personally don't like push notifications, seems silly.
Apple doesn't want web applications to somehow replace apps in the app store. They make way too much money from their app store. Some of these key features like push notifications are the only reason to even make a native app, for some types of apps.
Well, I would argue the web is a detriment to the web. Apple will never prioritise dev experience to the... detriment of user experience, no matter how many devs tears are shed. The author is arguing for better web developer experience, from what I read.
So the author of this post is saying a developer with 9 years experience needs 6 months to learn ReactNative?
That doesn't sound encouraging...
That doesn't sound encouraging...
TIL
> The apps implementing the standard are called progressive web applications, not to be confused with confusingly similar terms like progressive enhancement or responsive apps.
Front-end moves at the speed of light, I reckon it's hard to come up with original names...
My brain already has to remember thousands of software library names and techniques and argument orders, etc. Not making your label meld into people's brains by being similar to other software names in the SAME niche is a good place to start though.
> The apps implementing the standard are called progressive web applications, not to be confused with confusingly similar terms like progressive enhancement or responsive apps.
Front-end moves at the speed of light, I reckon it's hard to come up with original names...
My brain already has to remember thousands of software library names and techniques and argument orders, etc. Not making your label meld into people's brains by being similar to other software names in the SAME niche is a good place to start though.
I'm not naive and understand the sentiment that part of Apple's motivation behind not supporting these API's on mobile Safari is to protect its App Store ecosystem.
BUT I also believe that Apple cares deeply about quality and its MAIN reason to refuse support is to protect the quality of user experiences on its iOS platform and steer developers to use its native API's which produce vastly superior apps.
It would take Apple years of wasted effort to guarantee similar experiences in the browser.
BUT I also believe that Apple cares deeply about quality and its MAIN reason to refuse support is to protect the quality of user experiences on its iOS platform and steer developers to use its native API's which produce vastly superior apps.
It would take Apple years of wasted effort to guarantee similar experiences in the browser.
"Apple's refusal to support my chosen development platform means that Apple is holding back the entire web" ...really?
This is not the point I'm trying to make. Startups don't 'choose' the web. They choose whatever exists to make cross-platform apps, because having to develop and maintain 3 separate code bases is not feasible for most bootstrapped startups.
If I just picked iOS and told every one of my app's users that they have to use it, it would be pretty difficult for me to succeed.
Its not that I don't want to learn another language. Its that the time it takes me to maintain 3 separate codebases takes away from my ability to iterate on product features and build stuff that will actually help the people using the app, and ultimately make my company successful.
If I just picked iOS and told every one of my app's users that they have to use it, it would be pretty difficult for me to succeed.
Its not that I don't want to learn another language. Its that the time it takes me to maintain 3 separate codebases takes away from my ability to iterate on product features and build stuff that will actually help the people using the app, and ultimately make my company successful.
PWA are still inferior to real native apps. The FT's webclip "app" is ass compared to the NYT's nice, native one.
Why do I need to download 15mb js file for your fancy "offline" web app? Even native apps usually smaller.
Frankly, it seems like PWA is a solution for web developers looking to deploy LCD, "unnative" apps more widely, more easily.
That's fine for them, but ultimately, I think we've got far too many apps with crappy UIs.
So what's the the real value to the platform and the people who use it for another source of them?
That's fine for them, but ultimately, I think we've got far too many apps with crappy UIs.
So what's the the real value to the platform and the people who use it for another source of them?
how good are these PWA ? are there any apps that are already out there on Android ? I'm curious to see how well it perform compared to a native iOS app.
Twitter Lite is probably the quintessential PWA, it is very well executed. Here is a YouTube video of the creation of it from React Europe https://m.youtube.com/watch?v=cc3rdiXl5eY
Officially Apple's reasoning for barring Flash was that web should be pushed forward. Now, almost 8 years later when web is "almost there" - its still hindering real web-app experiences in the iOS browser. Its pretty clear what this was always about.
-- (Please lets not do the fanboy "Flash is garbage" here - even if you do feel that it was heating up your CPU with ads - it would have taken a lot less than 8 years to fix that then to reinvent everything and find out that money still makes the world go round.) --
-- (Please lets not do the fanboy "Flash is garbage" here - even if you do feel that it was heating up your CPU with ads - it would have taken a lot less than 8 years to fix that then to reinvent everything and find out that money still makes the world go round.) --
Adobe and Android had every financial incentive to make Flash work well on a phone, and failed.
To say that Flash on mobile was great but Apple killed it anyway, gives Apple way too much credit. Flash on mobile killed itself.
To say that Flash on mobile was great but Apple killed it anyway, gives Apple way too much credit. Flash on mobile killed itself.
And there we go again. Where/when did I ever say that Flash on mobile was great?
Just discussing monopolies and drawing parallels.
To be fair Adobe was always pushing Flash as a cross-platform, cross-browser system - mobile browsers kind of changed the game and required a different approach since they were so tightly coupled to the OS and controlled by its vendor (BTW there was also a time where Microsoft was accused of monopoly for bundling its browser with the OS - doesn't seem to apply to iOS though).
If it was supposed work cross-platform on 2 mobile platforms - and one platform says no, well then 1 platform is not cross-platform any more is it? Adobe then gave up and stopped developing it - but yeah, Apple effectively did kill it. Especially since it was still a very early try. I mean up until 1-2 years ago even normal css/webanimation was laggy on mobile browsers.
Just discussing monopolies and drawing parallels.
To be fair Adobe was always pushing Flash as a cross-platform, cross-browser system - mobile browsers kind of changed the game and required a different approach since they were so tightly coupled to the OS and controlled by its vendor (BTW there was also a time where Microsoft was accused of monopoly for bundling its browser with the OS - doesn't seem to apply to iOS though).
If it was supposed work cross-platform on 2 mobile platforms - and one platform says no, well then 1 platform is not cross-platform any more is it? Adobe then gave up and stopped developing it - but yeah, Apple effectively did kill it. Especially since it was still a very early try. I mean up until 1-2 years ago even normal css/webanimation was laggy on mobile browsers.
> even if you do feel that it was heating up your CPU with ads - it would have taken a lot less than 8 years to fix that
They had more than 8 years to fix it on the desktop and didn't. They had more than 8 years to make the Mac version perform at rough parity with the Windows version and didn't.
Either way... "it's fine, we'll make it work well within a decade" is NOT a good message to your users.
They had more than 8 years to fix it on the desktop and didn't. They had more than 8 years to make the Mac version perform at rough parity with the Windows version and didn't.
Either way... "it's fine, we'll make it work well within a decade" is NOT a good message to your users.
Again - not really trying to discuss Flash, was just drawing parallels.
Even though my Mac never had significant problems with Flash. I mean - fix what? I don't have Flash installed any more but my fans still spin-up with multiple tabs and overactive pages trying to open a bunch of animated or video tabs.
Even though my Mac never had significant problems with Flash. I mean - fix what? I don't have Flash installed any more but my fans still spin-up with multiple tabs and overactive pages trying to open a bunch of animated or video tabs.
Kind of a different use case, but I work on a web-based IRC client (self-hosted IRC cloud) and if Apple support service workers we could have improved offline support, push notifications (for mentions, disconnects, etc), on-device caching of embeds (links and images are embedded in-line), an improved loading screen, and more.
Author here. Pretty overwhelmed and astonished with all this. Can't wait to read through all these comments!
Apple just need to mess things up for everyone. They wouldn't be Apple otherwise.
Can someone explain the difference between progressive web apps and webRTC? Are they related, or completely separate technologies? I just heard about them around the same time, and it seems like they have some things in common.
PWA's use Web Technologies to build Apps. Remember jQuery Mobile? It's more like that than React Native or Xamarin.
WebRTC is an API/Protocol that enables Real Time Communication between browsers.
WebRTC is an API/Protocol that enables Real Time Communication between browsers.
Thanks, I got thrown off when I seen PWA talking about service workers, it sounded simlar to the data channels talked about in WebRTC. I haven't had a chance to dip in to either yet.
I'm pretty late to this party, so it probably has already been asked but what specific things need to be supported by mobile Safari to run a PWA?
My reading of the thread, as well as watching the general discussion of PWAs over the last 6 months, is not "what does Safari need to support", but really are PWAs the right answer?
If the comments were limited to "Safari needs X and Y", and there was no discussion about the an inherent need for PWAs it would be a pretty short thread.
Safari's support for PWA features is a proxy referendum of PWAs themselves.[1]
[1] And Google's desire to not being dis-intermediated as an arbiter of access to information/functionality via web properties.
If the comments were limited to "Safari needs X and Y", and there was no discussion about the an inherent need for PWAs it would be a pretty short thread.
Safari's support for PWA features is a proxy referendum of PWAs themselves.[1]
[1] And Google's desire to not being dis-intermediated as an arbiter of access to information/functionality via web properties.
I hope this never happens. I despise Javascript.
Apple will do anything to keep control over iOS apps. Web won't allow them to get their 30% margin, so they will do anything to force developers stay in AppStore.
Google thinking webpages can be as good as native applications is a detriment to the UX.
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.