Why is it whenever there is a criticism of Apple, we always have to turn it into an Apple vs Windows, or Apple vs Android type competition? Just because One party is behaving like a twat, doesn't mean there is justification for the other to do the same.

I find that such relative comparison put things in perspective.

My problem with it is that it tends to put things in the wrong perspective. Should we judge things by comparing them to other crappy products, or by a reasonable expectation of what things should be like independent of that? If it's the latter, then what's the point of comparing it with the former? It just gives a false sense of "it's not so bad after all."

I see both approaches as merely tools to achieve what you want. I don't see any of those approaches as good or bad. If one wants to make only Apple's decision and practice look bad, then yes they could do absolute comparison. Alternatively, you could do a relative comparison to see that this is a standard practice followed by all major platforms providers, that compete with their customers.

Neither is good nor bad except one is supposedly singling out Apple to make it look bad? Besides, I was talking about holding ALL involved to the absolute standard, compared to a purely relative comparison.

Companies don't operate inside a vacuum. They are part of an ecosystem that they share with their competitors. If a competitor does X, the company in question must respond with Y. It's just how things work.

Having private APIs is now behaving like a twat? This whole issue is ridiculous, it concerns a user interface element!

Not only that I believe Google contacted most of the popular SMS devs when they made huge changes to the SMS content providers in Kit Kat (which are private). They didn't really need to but did to let them know of the changes.

Yes they did. If they deliver an OS upgrade and a bunch of apps stop working, the user will blame the OS upgrade regardless of the real reason. Raymond Chen (from MS) covered this well on his blog

http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...

This is software engineering 101, really, and the reason we have the concept of private interfaces in the first place: you bloody well expect first party developers to be able to change the private parts of the interface with abandon, knowing that third-party consumers of those interfaces will not break because of those changes.

However they acted differently for the wakelock api. In Android, there is a private api that allowed access to a list of wakelocks, which was used by many apps to provide the user with more information about what is keeping the system awake. However, their was a security implication (this was a real concern), so 4.4 made the api both private and inaccessible. (Private apis by default you can't use, but you can get around it by getting a reference using language-features). Unlike the sms situation though, they didn't provide a replacement api without the security issue. So now you need to root the phone in order to access the list of wakelocks.

While this may not affect most of the users of these apps, this is quite unfortunate, because these applications were especially handy on non-stock phones, which usually aren't easily rootable.

> The main point here is that you are on the same level of Google: if you want you can use those private APIs, but be ready to do a lot of work to keep your application working fine.

Which is swell if you're an application developer. But for the end users it means that apps may suddenly stop working if they upgrade the OS.

I've had apps stop working after upgrades on every device I have ever used.

It's important that the developer keep up with an evolving API and if they plan to use experimental features that aren't locked in yet, they should make note and be prepared for if/when it's taken out or changed.

Unfortunately, no matter what device you use, there will be developers who fail to maintain their apps.

OTOH, you get apps that can actually do things, rather than only whatever google produces.

Having an unsupported API method is one level of "cheating". Hardcoding bundle names and only allowing certain applications to call your unsupported API method takes it to a new level.

What if the code was just in an unreleased static lib that was linked to each app.

Isn't Apple allowed to make shared code for just its apps? Putting it in the supported frameworks is just an easier way to make sure that it eventually gets released for everyone -- otherwise lots of useful code might just languish inside apps and private libs.

> What if the code was just in an unreleased static lib that was linked to each app.

Then it would be fair game. Your argument ignores an important difference: app-space code - which every developer can do; and OS code exposed as private API - which only Apple can do.

We agree that Apple can write and distribute code for its own apps, and share between them. What does it matter what the technical details are? Doing it the way that they do uses less memory -- that's better for users.

It's not feasible to extend the capability of creating and deploying OS frameworks to 3rd party developers.