Heck, you don't even have to use their phone app, you can install a SIP client. It's perfectly possible to use Android as it exists in AOSP without Google stuff at all. Some 3rd party apps may want to use things like Google Maps embedded, but there are projects that replace those and an Xposed module to fake the signatures to match. The Google-less Android system is really a decent experience if you're willing to put the work in to it.

This is the fundamental difference in philosophies behind Android and iOS.

Apple likes to build their software (most of the time) like Python - its an opinionated platform that strives to make that best decisions for users. They've determined there's very little user benefit from having multiple push notification services, and they don't want to give users a way to shoot themselves in the foot by enabling such a setting that would impact battery life like that.

Many of Apple's decisions can be viewed through that lense.

I'd argue it's a platform that strives to make best decisions for Apple, and that's not the same thing as being opinionated.

Yes, there's an argument that there is very little user benefit from having multiple push notification services. But there's no inherent benefit to having Apple's service be the one-and-only service ever allowed to be used -- that's not an opinion, that's vendor lock-in.

There's an argument that there is benefit in not having multiple different web browsers on a user's phone. But there's no benefit to having Apple's webkit be the one-and-only web browser ever allowed on the phone -- that's not opinion, that's vendor lock-in.

There's nothing inherently wrong with a product holding strong opinions. But vendor lock-in is not the same thing as an opinion -- there is a clear difference between an opinionated product, and a monopolized one - https://en.wikipedia.org/wiki/United_States_v._Microsoft_Cor....

Let's suppose Apple were to open up their APIs to allow other services to send push notifications to their devices. Since they are no longer the intermediary they've given up control on how often a developer's servers are sending notifications via the third party, they've lost a control on throttling how often notifications are sent to devices. What happens if the push service or the developer's backend is compromised (or misconfigured) and attempts to send hundreds of push notifications per second to thousands of phones? Features could be added to the OS to help mitigate this but the phone must still service the incoming traffic. Strictly speaking, this isn't Apple's fault but this won't be a sufficient answer for their customers.

Which isn't even considering that they need to figure out a secure mechanism for allowing third parties to uniquely identify iPhones.

> There's an argument that there is benefit in not having multiple different web browsers on a user's phone. But there's no benefit to having Apple's webkit be the one-and-only web browser ever allowed on the phone -- that's not opinion, that's vendor lock-in.

What happens if Mozilla, Google, etc. release a new browser engine for iOS with all the latest whizz-bang HTML features but at the cost of doubling power consumption? Apple support needs to deal with the customers who suddenly see their battery life plummet when switching to a new browser. 99 customers out of 100 will blame Apple for this. What if a vulnerability allowing RCE is discovered in the JIT code included in the third party browser? Apple has lost control of the patching cycle and their only recourse would be to remotely remove the browsers from their customers' phones if the vendor does not update the app in an acceptable timeframe.

I feel like a lot of Apple's decisions around the iOS ecosystem can be explained by looking at the problems they had with customers running Adobe Flash on the Mac.

What if I use an email app or notes app or other app that consumes twice the power of Apple's inbuilt app?

I don't see what's special about a web browser. It's just another app.

Well, I'm the user and I've determined that I'd rather not send private data through their servers, that I'd rather be able to do things like run a proper IMAP, XMPP, SSH or SIP client on my device without disconnections, etc. Those seem like pretty major use cases to me, ones which Apple shouldn't be making decisions for the user about.

If I ran an Apple device I couldn't use SIP and I'd be required to pay 4x as much for a phone plan rather than using a cheap data-only tablet plan for example. That seems prohibitive to say the least...

This is of course ignoring that the user doesn't get much of a say in what push notification delivery mechanism is used - that's up to the developer.

But, to be honest, if you don't trust Apple to handle your push notifications then I doubt you would trust them to do much else, and you should choose another platform.

Most of the time my concern isn't with apps that have a dedicated service backing them, but with apps which don't. I don't want Apple notifying me when something changes on my SSH session because I sent my SSH credentials to some 3rd party server that notified Apple to notify me.

I trust absolutely no one to handle those credentials properly, I need my device to do it. And I need it to do it by interacting directly with the server.

Android solution: You own the server. Your server pushes directly to you.

iOS solution: No ability to maintain SSH connections, instead you need to get a 3rd party app to open an SSH connection for you and send you a push notification via an Apple service when a change occurs.

See the problem? Trusting Apple alone isn't an option - Apple doesn't offer a service to send you a push notification for your SSH session. You need to involve a 3rd party.

iOS solution: everything goes through Apple, I generally trust them and know that they try to look out for me.

Android solution: every app goes through someone else's server, every app needs individual vetting because I have no idea what they're doing or how hard they're trying with their privacy. Where is the trying at all. That's the way you see it, how about the way I see it?

iOS solution: everything goes through Apple, I generally trust them and know that they try to look out for me.

Android solution: every app goes through someone else's server, every app needs individual vetting because I have no idea what they're doing or how hard they're trying with their privacy. Or if they're trying at all.

I like the iOS solution. You have it framed for my developer point of you, and I can understand that. But from your point of you, your solution has a lot of potential issues around privacy alone.

   iOS solution: everything goes through Apple,

   I generally trust them...

   and know that they try to look out for me.

Apple looks out for their bottom line. If your interest happens to cross that path, bummer.

Don't just assume a commercial interest 'looks out for you' because they don't. If your needs, or at least your perceived needs (due to effective marketing) fit with a company's strategy you might get the idea that said company does it all for you and your fellow users. This does not imply any causality, the company just does what it thinks is best for its bottom line. As long as a company serves the needs of its users they are in a position to do well. Vendor lock-in serves companies in that they have more freedom to choose their own path without bothering all that much about whether that path coincides with their users' needs as those users face a steep cost if they choose to change vendor. As long as the company keeps the extra costs - in money, limited features or usability - lower than what it would cost a user to switch vendor they stand to gain from this strategy.

You honestly believe that Google don't look out for their bottom line either?

   You honestly believe that Google don't look out for their bottom line either?

But, to get back to your Google example, of course Google looks out for their bottom line. It just so happens that Google is not nearly as aggressive in herding their users into fenced corrals as Apple is. Google moves fast and often discontinues services so it is unwise to base your (company's) future on the existence of any specific Google service. Fortunately Google generally makes it easy to get data out of their services so a viable exit strategy is usually feasible. Apple is not that fast a mover which also implies they don't discontinue services at the rate at which Google does. Where Apple fails miserably is in their support for migrating data out of their services. This, again, fits the description I gave at the start of this sub-thread: Apple wants to raise the cost of leaving their services.

I'm not talking about general push notifications though, nor am I speaking as a developer. I'm speaking as a user, who also wants to connect to ssh, imap, xmpp and sip. The standard Apple/Google model is fine for most push notifications but absolutely not for things like this where a direct connection to a server is something that you as a user want.

That's the part I'm complaining about, not the general push message system, but the system of not being able to keep a persistent connection to a SIP or IMAP server without giving my credentials to a 3rd party so they can handle push and forward that off to Apple or Google.

I learned recently that this isn't just a matter about the OS vendor making decisions, but that the OS vendors negotiate with the cell providers for longer timeouts:

https://github.com/WhisperSystems/Signal-Android/issues/1000...

"The advantage GCM has is that Google has made agreements with mobile carriers not to timeout connections on those networks. Without those, websocket connection idle timeouts on mobile data connections will be unpredictable, and they tend to be more trigger happy (and also often just silently close without sending an RST)."

So, if you want to run a proper IMAP (IDLE, I assume) or XMPP or anything client, you'll need to negotiate with your cell provider for better timeouts.

Or just send TCP keepalives and accept worse battery life. I still get enough to get me through a day with my phone almost never sleeping fully due to all the shit I have connected constantly.

Also, note that that comment is completely unsourced - I'm curious if there's any evidence backing that or it's just bunk. It wouldn't surprise me, but I also don't see any references to that anywhere else. Moxie is known to hate the 3rd party app stores and stuff, so it might just be him bullshitting about a possibility.

https://developer.apple.com/reference/callkit

You can also push notifications to your device in an end-to-end encrypted manner. iOS 10 supports notification extensions so your private app extension can receive the encrypted payload, decrypt it, and then present a normal notification.

Because people could use whatever web browser they wanted and tons of people experienced 3-5 hour battery life, I imagine a lot of them would ditch iOS thinking that the iPhone was the problem.

And Apple would lose money.

There are some things Apple does that are very blatantly self-serving. I think there's are VERY reasonable explanations for this one (power usage and security being two).

Unless you want Signal, which everyone (rightly) recommends. Finally off of almost every Google service, wanna install the latest and greatest encrypted chat app... too bad. But I recently heard Signal is finally working on it (after they closed my Github Issue as wontfix/by-design a year or two ago).

That doesn’t work in Marshmallow, due to a bug, even if the user opts out, it will still disable the app during Doze.

The bug has been fixed in later versions, but you as a dev obviously can’t just leave a huge share of your users without working push notifications.

Surely another constant connection like SIP would also be terminated, no? I don't see how that would differ from another push notification system.

edit: to be clear I'm using a 3rd party SIP client (Bria), which I have indeed excepted via this method.

This was fixed at https://android-review.googlesource.com/#/c/221708/ and probably merged into many custom roms generated since. It also only occurred under fairly specific circumstances.

EDIT: Yup, https://romhut.com/versions/cm-13-0-20160508-v8-0 indicates it's been in CM for a while, which is probably why I haven't experienced it. Dianne Hackborn fixed this as far back as November 2015, it might have made it into 6.0.1 on some devices too, though I could be misreading.

This leads to the problem that you, as a dev, either have to leave a huge amount of users without working push notifications, or use GCM anyway.

Any Java library that depends on Java 7 or 8 standard libraries not available on Android, newly introduced JVM bytecodes, some of the Java 8 language features, annotation processors, ... isn't usable on Android.

Good luck getting Java 9 modules, or eventually Java 10 value types and updated generics when they become available.

https://developer.android.com/about/versions/marshmallow/and...

Edit: I'm getting down-voted, presumably because people think web apps should have different capabilities than native apps. To those responding this way: why? I can't imagine why you'd prefer the locked-down app distribution channel of the Play Store, in comparison to the open web..

I think a lot of the newer APIs being exposed to the Web via the Browser are not very well thought out and will eventually be removed because of the risks they present.

Those APIs are available to all Android apps, including other browsers. The only complaints I've heard are about Push-style APIs and power saving essentially forcing you to use Google Services.

However you can write an App that persists in the App Tray as an icon that could maintain the App's Service component. The drawback there however is the persistent notification.

Well, the actual drawback is that you end up with over a dozen such notifications, your entire UI is full with them, and there’s no way to get rid of them, even if you developed the apps yourself.

On the phone they could then look if GCM is around (and use it) or if that other notification app is around (and use it) or propose to install said app. It's negligible in terms of user confusion because people on non-GCM systems likely know what they're getting into (except for those using Amazon Fire).

I, for example, develop an app connecting to servers that the users self-host.

I can’t modify the server, nor can I easily get it to send notifications.

But I want to be able to show notifications.

Luckily I can open a port to it and wait for them.

It’s impossible to solve with GCM.

http://xmpp.org/extensions/xep-0357.html