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.
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.
>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 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.
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.
> 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.
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:
...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.
> 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.
> 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).
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.”
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.
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.
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.
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.
> 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.
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.
> 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.
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.
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.
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.
> 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.
"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.
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.
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.
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.
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 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.
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...
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.
>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...
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.
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.
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?
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).
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.
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.
When it comes to Electron apps I think any failing to provider a top notch user experience is on the developer and not on the technology. Visual Studio Code is based on Electron and it is hands down the best text editor/IDE-lite out there because the team behind it put the time in to make seem like the type of app you would get out established UI frameworks within the target environment.
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.
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.
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.
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)
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).
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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
"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 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.
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.
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."
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.
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.
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.
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.
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).
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.
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)
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.
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.
>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.
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.
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.
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.
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 :-)
> 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.
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.
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?
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.
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..)
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.
> 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.
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.
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.) --
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
>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.
22 replies →
>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.
9 replies →
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.
3 replies →
> 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.
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.
2 replies →
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.
4 replies →
> 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).
1 reply →
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.”
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.
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.
1 reply →
GMail was (and maybe keeps being) a much better user experience than native email clients for desktop PCs.
16 replies →
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.
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.
2 replies →
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.
2 replies →
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.
7 replies →
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?
7 replies →
> 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.
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.
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.
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.
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.
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.
> This is unnecessary duplication of work that could've been spent writing new features
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.
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.
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.
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.
6 replies →
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....
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.
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.
9 replies →
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.
6 replies →
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...
2 replies →
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.
7 replies →
>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...
10 replies →
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.
>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?
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.
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.
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?
I'm also sick and tired of bloated apps with loading screens
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).
9 replies →
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.
13 replies →
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.
4 replies →
When it comes to Electron apps I think any failing to provider a top notch user experience is on the developer and not on the technology. Visual Studio Code is based on Electron and it is hands down the best text editor/IDE-lite out there because the team behind it put the time in to make seem like the type of app you would get out established UI frameworks within the target environment.
2 replies →
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.
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.
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.
4 replies →
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)
3 replies →
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.
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.
Not even remotely close.
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).
3 replies →
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-...
2 replies →
> 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.
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.
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.
2 replies →
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.
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.
Yes but supporting the feature encourages developers to make web apps. Why would you want to encourage that?
17 replies →
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.
1 reply →
> 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.
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.
1 reply →
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?
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.
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.
[1]: http://engineering.flipboard.com/2015/02/mobile-web
Literally all businesses are run on top of Excel, which, if you like, is sort of a generic app development environment.
1 reply →
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...
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.
13 replies →
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.
6 replies →
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.
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?
> ...
6 replies →
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.
1 reply →
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.
2 replies →
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.
3 replies →
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.
1 reply →
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'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.
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.
3 replies →
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.
1 reply →
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.
13 replies →
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.
3 replies →
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).
4 replies →
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?
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.
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.
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.
"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.
https://facebook.github.io/react-native/showcase.html
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.
the web apps still could not interact with different hardware components/sensors
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.
> 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.
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."
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.
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
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.
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'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.
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.
Don't give them these scary ideas! Browser tax to access websites. Net neutrality at browser level.
so you say we give apple, a way to get 30% cut from every transaction done on a website on ios safari and web will leap forward?
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).
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.
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)
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.
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).
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.
>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.
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.
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.
10 replies →
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 :-)
3 replies →
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.
> 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.
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."
1 reply →
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?
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".
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...
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.
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.
"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.
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?
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.) --
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.
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.
> 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.
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.
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.
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.
I hope this never happens. I despise Javascript.
Please.... anything but Active Desktop again
12-year-old me loved Active Desktop, so many gifs.
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.