Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Apple Cheats

marksands.github.io

Post reply on HN
Print view View original

91–100 of 235 posts

Re: How Apple Cheats

#91

Post by eddieroger »

praptak wrote: post #43
yalogin wrote: post #16

I would not consider the default applications on the iphone "apps" even. They are written by Apple to provide a certain functionality and that is what they do. They can use any API they need. Why should they not use private API? I would not consider iBooks to be somehow different from say the phone or system preferences "app". They are there because they are provided by the system.

Funny how Microsoft got pitchforks & torches for using this argument for bundling IE with Windows.

Bundling IE was never the problem. Using private APIs to give IE a noticeable advantage over other, more popular browsers in an effort to gain marketshare for IE was the problem. Having a monopoly isn't illegal, and is part of capitalism. Using a monopoly in one market (say, operating systems) gain share in another (like, browsers) is.

Re: How Apple Cheats

#92

Post by eli »

jamra wrote: post #51
dilap wrote: post #27

It'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…

The situation you're describing is not the same situation as described in the article. This API is not private. It's a public API for the iPad. There is a check that detects if you are running an iPad or iPhone. If you are running an iPhone, your program will crash.... unless it is one of the internal apple apps. Nothing here is private.

I think you are just being pedantic here. It's private in the sense that it is not usable by the public on this device.

Re: How Apple Cheats

#93

Post by csixty4 »

danford wrote: post #68
poolpool wrote: post #61

Too many people here are way too furious at anything apple/closed source to discuss anything. 1) you still own your phone. Don't be silly. Jailbreak and builds apps to your hearts content. Vendors can choose who and what they allow in their store. Physical or otherwise. 2) apple makes virtually all the profits on consumer hardware, but has Tiny market share. Really. It's no an abuse of a monopoly if 20 percent of peo…

>equating access to private APIs in a private store with morality Well, I think there is a lot more to it than this. I think people are just using this as one example. Personally I don't think it's a very good example, but you won't see a thread on HN about Apple purposely breaking X so Y is more difficult (for example the android imessage fiasco), or the fact that many 'innovations' by Apple, like thunderbolt or ret…

> many 'innovations' by Apple, like thunderbolt or retina, are really just 'one-upping' the competition and attempting to lock the consumer in to something that's no more than a gimmick. Sure thunderbolt is fast, but it's not something that any tech company couldn't design

Definitely. For example, Thunderbolt was designed by Intel. Apple had an exclusive license for a while, but it's available on Windows laptops[1] now, albeit sometimes with their own proprietary connector[2].

> Personally I'm not a fan of the Apple ecosystem

It shows.

[1]http://en.wikipedia.org/wiki/List_of_Thunderbolt-compatible_...

[2]http://www.pcworld.idg.com.au/article/391755/sony_adopts_int...

Re: How Apple Cheats

#94

Post by eli »

The way the check is implemented looks bad, but this doesn't tell us anything we didn't already know.

If you're surprised that Apple can use non-public APIs in its apps, you'll be shocked to learn that Apple actually controls the whole ecosystem and can block apps that compete with its own apps regardless of what APIs they use.

Re: How Apple Cheats

#95

Post by jacquesm »

icantthinkofone wrote: post #85
jacquesm wrote: post #36

Earlier 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…

The difference may be that Microsoft used the private APIs to give itself (and select partners) advantages over competitors while being a monopoly. I don't know if Apple is using those APIs to give themselves an advantage over competitors but they certainly are not a monopoly as Microsoft is.

As microsoft was. At this point in time I don't think that anybody would be able to present an argument to the effect that Microsoft is the dominant player in consumer or business computing. The number of devices not running a Microsoft OS is significant.

Re: How Apple Cheats

#96

Post by mitosis »

Those of us old enough to remember the early days of the Macintosh know that this is nothing new. Apple programs used undocumented calls to QuickDraw and did all kinds of yucky stuff with the upper 8 bits of the address (in the early days, the Mac processor used 24-bit addresses but the registers were 32-bit), which lead to the "32-bit clean" problems that plagued the first Macs to use 32-bit addressing.

Apple also did this in the Apple II days, calling undocumented ROM monitor routines from their own programs and operating systems. In fact, several companies made a list of those entry points and considered them "semi-official", the reasoning being that Apple wouldn't change entry points used by their own programs.

Re: How Apple Cheats

#97

Post by eli »

ninininini wrote: post #71

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.

What are you implying?

Re: How Apple Cheats

#98

Post by Tyrannosaurs »

praptak wrote: post #43
yalogin wrote: post #16

I would not consider the default applications on the iphone "apps" even. They are written by Apple to provide a certain functionality and that is what they do. They can use any API they need. Why should they not use private API? I would not consider iBooks to be somehow different from say the phone or system preferences "app". They are there because they are provided by the system.

Funny how Microsoft got pitchforks & torches for using this argument for bundling IE with Windows.

To me the issue with IE and Windows was that MS went from a position where IE basically didn't exist (but other browsers did and worked fine on it's OS) to "it couldn't possibly not be tightly integrated into Windows" in no time at all.

Re: How Apple Cheats

#99

Post by coldtea »

jacquesm wrote: post #36
dilap wrote: post #27

It'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…

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…

Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party.

Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here.

But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.

Re: How Apple Cheats

#100

Post by jacquesm »

cynicalkane wrote: post #84
jacquesm wrote: post #79

Earlier quoted context omitted.

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.

No, the point is you have no argument in addition to no authority. It's normal to require one or the other.

My argument is, since you insist that I don't have any, that since Apple has total control of an ecosystem they themselves created that there might be an anti-trust issue there along the lines of Microsoft when they decided to include 'mediaplayer' with every windows install when and if an Apple app competes with a 3rd party supplied app.

Whether or not I'm a subject expert or not has no bearing on that. I suspect that the answer is 'probably not', but I have seen weirder lawsuits being won. The bar in anti-trust cases is very high but there are multiple standards of proof and multiple instances of potentially anti-competitive behaviour.

Post reply on HN