Almost everyone on here is defending Apple. For any other company there would be crying that someone is planting these Apple supporters or its Apple's marketing department making these comments or a hundred other reasons why these supportive comments shouldn't be trusted.
How Apple Cheats
71–80 of 235 posts
Re: How Apple Cheats
#72Earlier quoted context omitted.
You are fundamentally misunderstanding a monopoly position.
And you are fundamentally misunderstanding that anti-trust law is about more than just monopolies.
Except you're not an antitrust law expert, you're a Random Guy On The Internet making up handwavey arguments that would never fly in court. Under this principle, you could say Nintendo has a monopoly on Nintendos and must therefore open secret APIs to developers, or that whatever cable box company has a monopoly on their particular brand of cable boxes, &c. Courts reject principles that lead to absurdity under simple substitutions.
I don't know what your comment about "anti-trust law being about more than monopolies" is supposed to mean. It says nothing, and furthermore says nothing with an authority to which you are not entitled, being not an antitrust law expert. So your unsupported and unreasonable claims should be discounted accordingly.
Re: How Apple Cheats
#73It's totally reasonable for Apple to use APIs internally that it's not ready to make public -- making an API public is a serious decision with lots of downsides! You've got to support the API forever, and future design directions are constrained. To expect Apple to make all code it uses internally available publicly is silly. (If you want some great examples of the extreme amount of work it can be to support legacy A…
>You've got to support the API forever
Not really. Many APIs have features that are put in and removed all the time. The key to managing this is having a good API that tags features as things like 'experimental', 'deprecated', 'locked', etc to indicate if features are permanent or could be changing.
Stability: 0 - Deprecated This feature is known to be problematic, and changes are planned. Do not rely on it. Use of the feature may cause warnings. Backwards compatibility should not be expected.
Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team.
Stability: 2 - Unstable The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable. Backwards-compatibility will be maintained if reasonable.
Stability: 3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes. Backwards-compatibility is guaranteed.
Stability: 4 - API Frozen This API has been tested extensively in production and is unlikely to ever have to change.
Stability: 5 - Locked Unless serious bugs are found, this code will not ever change. Please do not suggest changes in this area; they will be refused.
Re: How Apple Cheats
#74I'm not trying to suggest any kind of equivalency here, but what's the difference between hidden api functionality for Apple and Microsoft's undocumented function calls?
Microsoft's undocumented function calls gave a massive increase in performance, making competing applications in multiple domains essentially uncompetitive on the platform.
Apple is hiding a minor piece of functionality that can be implemented in another way and, indeed, has.
I find many of Apple's iOS business practices abhorrent, but trying to even suggest they are in the same league as 80's and 90's MS is an insult to all the companies MS destroyed in those decades.
Re: How Apple Cheats
#75Let's contrast with Android's take on a private API: private Content Providers. > The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them ju…
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.
Re: How Apple Cheats
#76Let's contrast with Android's take on a private API: private Content Providers. > The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them ju…
> 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.
OTOH, you get apps that can actually do things, rather than only whatever google produces.
Re: How Apple Cheats
#77Earlier quoted context omitted.
When Microsoft did the same thing in Windows it was grounds for anti-trust lawsuits to be brought against them: http://www.pcpro.co.uk/news/101947/microsoft-used-undocument... The idea here is that if you are supplying both the operating system and the applications that your applications should not benefit from being made by the same company as the OS, in other words, that it should be a level playing ground without…
Microsoft had a monopoly position at that time, and Apple does not.
In the vast chasm between pure monopoly (one supplier) and the perfectly competitive market (which is imaginary), is large room for firms which have competition but are still big enough to abuse their market position.
It's not useful to focus only on pure monopoly. From an economics perspective, there are plenty of other market structures which can be damaging for consumers.
Re: How Apple Cheats
#78Earlier quoted context omitted.
Apple systematically rejects apps that use private API's
Only if you let them find out ;).
Apps are Turing-complete, right? In theory, that means it's possible to make an arbitarily complex and obfuscated route to a private API, making it impossible to detect via simple static analysis.
Re: How Apple Cheats
#79Earlier quoted context omitted.
And you are fundamentally misunderstanding that anti-trust law is about more than just monopolies.
Except you're not an antitrust law expert, you're a Random Guy On The Internet making up handwavey arguments that would never fly in court. Under this principle, you could say Nintendo has a monopoly on Nintendos and must therefore open secret APIs to developers, or that whatever cable box company has a monopoly on their particular brand of cable boxes, &c. Courts reject principles that lead to absurdity under simple…
If the only people allowed to talk about anything are experts then we might as well shut down every forum on the internet including this one.
But have a read on the various pages written by experts and come up with arguments against what I said instead of just trying to attack my credibility.
Re: How Apple Cheats
#80Let's contrast with Android's take on a private API: private Content Providers. > The problem is, there are more Content Providers in the system than are documented in that package, and while you can use them, you probably shouldn’t. They’re there because some of the Google-provided apps use them internally to access their own data resources. Because Android is an open-source project, it’s easy enough to find them ju…
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...