Comment by pluma
9 years ago
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).
All of these things are already available in native apps. Putting aside all the business reasons for why Apple wouldn't want to do this, why should Apple spend any time to enable this for web apps? You say the choice is between a web app and no app, and I'm sure on the margin this impacts companies that can't afford to create a native app, but why should Apple cater to the lowest common denominator? Steve Jobs' post on Flash addresses this specifically [1]:
>Sixth, the most important reason.
Besides the fact that Flash is closed and proprietary, has major technical drawbacks, and doesn’t support touch based devices, there is an even more important reason we do not allow Flash on iPhones, iPods and iPads. We have discussed the downsides of using Flash to play video and interactive content from websites, but Adobe also wants developers to adopt Flash to create apps that run on our mobile devices.
We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.
This becomes even worse if the third party is supplying a cross platform development tool. The third party may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. Again, we cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Flash is a cross platform development tool. It is not Adobe’s goal to help developers write the best iPhone, iPod and iPad apps. It is their goal to help developers write cross platform apps. And Adobe has been painfully slow to adopt enhancements to Apple’s platforms. For example, although Mac OS X has been shipping for almost 10 years now, Adobe just adopted it fully (Cocoa) two weeks ago when they shipped CS5. Adobe was the last major third party developer to fully adopt Mac OS X.
Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
[1] https://www.apple.com/hotnews/thoughts-on-flash/
7 replies →
The choice is between a web app or no app.
why do you assume that's a worse alternative?
Watch the State of the Web talk from Google IO 2017. Certain native apps (Twitter, OLA) are 70-100MB in size when downloaded from the app stores. Their progressive web app version are 0.2-0.6MB. Extremely important in countries with very limited and/or expensive mobile data.
That doesn't have anything to do with native vs web though.
Twitter's native app is heavier than their web app because Twitter has historically filled the native app with junk (like a fullscreen video just for the login screen, "moments", "highlights", hijacking browser URLs, a bunch of ads and ad tracking, etc). Facebook does the same, to an almost silly degree - https://news.ycombinator.com/item?id=8162342
The Twitter client could easily be ~3MB on Android, for instance, if they just stripped the garbage out. And similarly, if you take a web app, and embed all that same junk into it, it will suddenly be a heavy download too.
2 replies →
https://sensortower.com/blog/ios-app-size-growth
According to this, Facebook was 32 MBs 4 years ago. It's similar with Twitter.
It's their fault that they keep adding stuff to track you. And Facebook contains just about every library that has ever existed now.
6 replies →
I'd say that's another issue. Duplicate frameworks in Facebook.app, monolithic tracking frameworks, etc. So much useless stuff prying on the user's privacy.
I remember Twitter.app had code to get the currently installed apps, to "better target ads." It's user hostile and we are paying with the multi gigabytes of data.
1 reply →
0.6MB to launch the app, which downloads 100MB more resources as soon as it starts up.
Exactly. I don't want websites to send notifications. And I dislike websites with Offline support: I always have to refresh twice to make sure the content I'm seeing came from a fresh source and not from cache.
Why is your complaint specific to websites with offline support? I always get stale data when I open Twitter app. I have to go to the top and refresh to get new tweets (and then they serve you with even more stale tweets but that's another problem).
1 reply →
Then just deny push notifications when the website prompts for them (exactly once). And simply refresh manually to make sure the offline-available website is fresh.
It's not like you're being force-fed notifications against your will. And it's not like offline content hurts you. Any inconvenience offline support causes to you pales in comparison to how much people benefit who actually need to be able to access content on spotty connections.
1 reply →
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.
It might be faster than Atom, but it surely feels sluggish compared with other native editors on my system.
I only put up with it due to being the editor with the best support for Rust plugins.
The day I can have the same experience on Emacs for Rust, VSCode gets kicked out.
Code is not native. Where is the accessibility support? Native tabs? Performance? Look and feel? Compared to something like BBEdit, Code is a joke.
What you fail to understand is that what is good for developers is good for users. Instead of spending resources on maintaining many different code bases, developers can focus on providing a more solid set of features for one.
For instance, maybe instead of being an always online application, they can put in effort at caching for offline use instead of duplicating features across different platforms.
I did my senior project in Electron and there was no way we could have implemented as much as we did if we had to build a native solution for every platform.
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.
Can't reply to FussyZeus, but in Firefox, you can permanently disable notifications for all websites (though it is not exposed in the UI).
Go to about:config, search for dom.webnotifications.enabled, set it to false.
1 reply →
I'm comfortable with it, just wish the browsers would give me the option to just say no, forever, to all websites.
1 reply →
I've never met a single end user who wants desktop notifications for web "apps," including myself. In fact I wish I could turn it off globally and more easily.
In Firefox, just open "about:config", search for dom.webnotifications.enabled, then double-click it.
If using other browsers, don't :)
(PS: I like desktop notifications for Slack, but since I'd prefer not to use Slack in the first place, I'm not sure I count)
In chrome: settings -> advanced -> content settings
Also dom.push.enabled = false, apparently.
1 reply →
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).
I am talking about possibilities provided by iOS SDK and what is provided by web stack. It is amazing that React Native does not even have something UINavigationControll-ish. UIKit alone gives stuff which is lightyears ahead of the web. Even some more basic stuff: how easy it is to add accessibility to PWAs? Localization?
2 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-...
Well, Steve said "nobody wants video on an iPod" when it wasn't ready yet. I'm not convinced that link shows me his true emotions.
1 reply →
> 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.
They have already released Apple Pay for the Web.
1 reply →