
Apple’s refusal to support Progressive Web Apps is a detriment to the web - jaffathecake
https://medium.com/philly-dev-shop/apples-refusal-to-support-progressive-web-apps-is-a-serious-detriment-to-future-of-the-web-e81b2be29676
======
christiangenco
I think a lot of commenters here are missing the point and getting distracted
by push notifications (who wants a website spamming them with notifications?)
and loading screens (hardly a feature).

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

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

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

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

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

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

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

~~~
interpol_p
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.

~~~
emsy
>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.

~~~
interpol_p
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.

~~~
emsy
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.

~~~
briandear
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.

~~~
emsy
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.

~~~
fredsir
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.

~~~
Sacho
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.

~~~
fredsir
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.

~~~
emsy
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.

------
jaffathecake
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...](https://lists.webkit.org/pipermail/webkit-
dev/2017-July/029285.html).

~~~
jondubois
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.

~~~
overcast
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.

~~~
hungerstrike
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.

~~~
koffiezet
> 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.

------
pluma
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.

~~~
IBM
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.

~~~
andreashansen
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.

~~~
maxsilver
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](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.

~~~
euyyn
In theory you could make a web app look like a native iOS app too, yet in
practice developers don't either.

~~~
s73ver
In practice, they tend to make it look like iOS, but then they ship the same
thing for Android, meaning the Android app looks like an iOS app.

------
rsynnott
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.

~~~
SquareWheel
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.

~~~
interpol_p
Yes but supporting the feature encourages developers to make web apps. Why
would you want to encourage that?

~~~
SquareWheel
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.

~~~
yellowapple
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.

~~~
TeMPOraL
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.

~~~
euyyn
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.

~~~
TeMPOraL
> _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.

------
nothis
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.

~~~
egeozcan
> 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?

------
interpol_p
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.

~~~
criley2
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.

~~~
matthewmacleod
_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.

~~~
Ajedi32
> 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.

~~~
ino
> 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.

~~~
ChristianBundy
> 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...

~~~
interpol_p
> 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.)

------
ino
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?

~~~
TheRealDunkirk
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.

~~~
SquareWheel
Sounds to me like a suitable use case for WebComponents.

------
ebbv
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.

------
Rjevski
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.

------
illuminati1911
"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.

~~~
icebraining
_the web apps still could not interact with different hardware components
/sensors_

Why not? WebUSB already shows otherwise.

~~~
euyyn
Web Bluetooth too.

------
linopolus
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.

~~~
flavio81
> 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.

------
VeejayRampay
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."

~~~
marcosdumay
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.

------
cjCamel
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...](https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API)

[2]: [https://developer.mozilla.org/en-
US/docs/Web/Manifest](https://developer.mozilla.org/en-US/docs/Web/Manifest)

------
waitwutt
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.

------
jpttsn
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.

~~~
FussyZeus
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.

------
josefwasinski
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.

~~~
iamgopal
Don't give them these scary ideas! Browser tax to access websites. Net
neutrality at browser level.

------
programminggeek
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).

------
quadrangle
When I think "progressive web…" I think of progressive enhancement.
[https://en.wikipedia.org/wiki/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.

------
jaxondu
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.

------
aedron
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)

~~~
MaxLeiter
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).

~~~
gregblass
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.

------
chasing
> 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.

------
ivanbakel
>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.

------
rimliu
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.

~~~
Sjenk
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.

~~~
egeozcan
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.

~~~
dmytroi
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.

~~~
egeozcan
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?!

------
millstone
> 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.

------
Jyaif
Fundamentally, it's Apple's refusal to allow real 3rd party browsers that is
the problem.

~~~
DerekL
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.

~~~
Jyaif
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."

~~~
DerekL
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...](https://techcrunch.com/2010/04/12/surprise-surprise-opera-mini-iphone-
app-gets-apples-stamp-of-approval/)

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.

------
Ninn
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?

------
archie_peach
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...](https://qz.com/253618/most-smartphone-users-download-zero-apps-per-
month/)

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".

~~~
linopolus
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..)

------
anderber
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.

------
spo81rty
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.

------
frusciante19
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.

------
pavlakoos
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...

------
dmix
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.

------
martijn_himself
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.

------
summadat
"Apple's refusal to support my chosen development platform means that Apple is
holding back the entire web" ...really?

~~~
gregblass
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.

------
nimish
PWA are still inferior to real native apps. The FT's webclip "app" is ass
compared to the NYT's nice, native one.

------
ex3ndr
Why do I need to download 15mb js file for your fancy "offline" web app? Even
native apps usually smaller.

------
jmull
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?

------
perfectstorm
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.

~~~
lpa22
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](https://m.youtube.com/watch?v=cc3rdiXl5eY)

------
velcro
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.) --

~~~
snowwrestler
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.

~~~
velcro
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.

------
MaxLeiter
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.

------
gregblass
Author here. Pretty overwhelmed and astonished with all this. Can't wait to
read through all these comments!

------
shmerl
Apple just need to mess things up for everyone. They wouldn't be Apple
otherwise.

------
Pigo
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.

~~~
antoniuschan99
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.

~~~
Pigo
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.

------
wuliwong
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?

~~~
jbigelow76
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.

------
rezashirazian
I hope this never happens. I despise Javascript.

------
lurcio
Please.... anything but Active Desktop again

~~~
fenwick67
12-year-old me loved Active Desktop, so many gifs.

------
vbezhenar
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.

------
mrkrabo
Google thinking webpages can be as good as native applications is a detriment
to the UX.

