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