How Apple Cheats • Hacker News Board

Re: How Apple Cheats

#31

Post by mantrax5 » Wed, May 28, 2014, 10:19 AM UTC

probably_wrong wrote: post #8

siphr wrote: post #4

I am surprised that this is so shocking to the author. Stuff like this is expected and only logical, as wrong as it may be. Apple has been desperately trying to tie people into their eco-system and every move the company makes is a step in that direction whether it may be immediately obvious to other people or not. Also I should mention that I believe Apple is probably not the only company that promotes the use of it…

As someone who is not an iDeveloper and has no idea what the UIPopoverController does: couldn't you make a case that Apple is deliberately crippling the competition and, therefore, make a case for abuse of a dominant position? If it were so it then it wouldn't be about being shocking, expected or logical, but about being against the law.

Apple has no dominant position in smartphones, so you may at best argue they have a dominant position specifically in their own iPhones.... But if Apple making design decisions for their iPhone product line constitutes an "abuse of dominant position" where do we draw the line exactly?

- Should Apple be forced to open all internal APIs to third party developers?

- Should Apple be offering iPhones with alternative operating systems?

- Should there be an open standard so people can build compatible iPhone clones?

No. iPhone is Apple's product, and they decide how far they will go in opening up their platform.

Third party developers are not fully trusted to do the right thing, and as you can see with Android's malware situation, it's a good thing Apple is not letting random developers do whatever they want.

Since Apple is held responsible by both developers and users to have a reliable product, when they decide to make an API public this is a huge commitment.

Apple has to guarantee said API will be supported in a reasonable way in future OS releases, it has to guarantee to users that calling said API won't result in poor UX or security vulnerabilities.

The situation is much different for Apple's own apps, as Apple can then make the personal guarantee it won't be abusing its own APIs to create poor UX and implement malware.

Re: How Apple Cheats

#32

Post by isawczuk » Wed, May 28, 2014, 10:34 AM UTC

rjknight wrote: post #28

There is definitely a need for private APIs that normal apps cannot use - they might have security implications, for instance. The App Store or Settings apps clearly need to be able to do things that other apps cannot do - for instance, any app that had the same privileges as the App Store would be able to install/uninstall other apps. Further, Apple's position is that the App Store, Settings etc. are akin to natural…

Private API is not the same as API permissions. If there is a private API, it means only "selected" can give best experience to the users. IMHO It's not fair and work against Apple in long term.

Re: How Apple Cheats

#33

Post by HannibalLecter » Wed, May 28, 2014, 10:36 AM UTC

The poor ethical state of affairs in the technology field is precisely what is slowing down humanity. Let's just run out of time and do the universe a favor, and rid it of our stupidity.

Re: How Apple Cheats

#34

Post by antimagic » Wed, May 28, 2014, 10:37 AM UTC

callumjones wrote: post #15

Isn't the argument that Apple makes use of private APIs as a beta test? That is, Apple will first introduce these private API restrictions, build apps around them and release the API as public once they are confident on its reliability. My understanding this is the approach with XPC and TouchID. Maybe Apple aren't confident with UIPopovers on iPhone and are awaiting its maturity until they let it loose. I highly doub…

Exactly. I rather suspect that there are some parts of UIPopoverController that have problems with the different screen sizes on say an iPhone 4S and an iPhone 5S. Apple trust themselves not to call the parts that don't work, but have not yet ironed out all of the bugs for third-party use.

Unless I've missed something about UIPopoverController, it's implemented using public APIs, so I'm curious as to what the author thinks Apple's motivation is for holding back this API - it's not like you can't create the same functionality yourself using existing APIs, it's just a bit more work. My guess would be that maybe they don't want to see people using popover controllers all over the place on the phone, so they made the bar higher for implementing such functionality.

Re: How Apple Cheats

#35

Post by HannibalLecter » Wed, May 28, 2014, 10:37 AM UTC

siphr wrote: post #4

I am surprised that this is so shocking to the author. Stuff like this is expected and only logical, as wrong as it may be. Apple has been desperately trying to tie people into their eco-system and every move the company makes is a step in that direction whether it may be immediately obvious to other people or not. Also I should mention that I believe Apple is probably not the only company that promotes the use of it…

By ecosystem, you mean venus flytrap?

Re: How Apple Cheats

#36

Post by jacquesm » Wed, May 28, 2014, 10:42 AM UTC

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 you having an unfair advantage.

Re: How Apple Cheats

#37

Post by ant_sz » Wed, May 28, 2014, 10:44 AM UTC

It is strange that Apple allows this API on iPad but not iPhone. What if you want to write an iPad/iPhone universal app? Although there are many 3rd party replacement, I prefer a native API anyway.

As for this popover API, I don't think it's a trick of anti-competive, It matters not so much. But there are no official explanation at all, the same as many other questions about Apple. It will be better if Apple becomes more open-----not nessesary open source, but be open to these questions to avoid guesses.

Re: How Apple Cheats

#38

Post by DanielBMarkham » Wed, May 28, 2014, 10:46 AM UTC

Might be time for the Apple PR machine to crank up some more stories about developers making millions writing apps. As every casino in Vegas knows, watching some guy hit it big is a great way to take your mind off how many resources you're losing.

I wonder, though, if there's going to be an end-game to this walled-garden nonsense. On one hand, people (tech-minded people) seem to be slowly getting it.

On the other hand, industry has somehow set up this insane legal system where the product you buy? You don't actually own it. So I go to the store and buy an iPhone. I give them money and I leave. This process is the same as if I bought a regular, land-line phone. Only with the iPhone, I don't own the box, the software, the O/S, or control what the phone does. Carrier wants me to have new software? It pushes it out and I have it. Apple wants to get rid of a favorite app I use? Poof, it's gone. They seem to be doing this without any major push-back from the user community.

I am prone to think both the "educated tech user" community and the "Joe Sixpack" community are going to meet up at some point, but I'm not sure. Maybe the strategy with this and all the other dystopian bullshit we're seeing is to try to run out the clock; keep things the way they are long enough so that the argument can then be made "but it was always like this!"

It's weird. I keep reading these articles about how various services suck, but it only seems like tech people know/care about it. That can't go on. Something's gotta give somewhere.

Re: How Apple Cheats

#39

Post by chaz72 » Wed, May 28, 2014, 10:49 AM UTC

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…

Microsoft had a monopoly position at that time, and Apple does not.

Re: How Apple Cheats

#40

Post by lepunk » Wed, May 28, 2014, 10:53 AM UTC

It perfectly makes sense for me for this API. It is an element which could result in bad user experience if used on the small phone screen. So their choice was: "We either a, restrict it for iPad only or b, rejects apps using it badly on the ground of bad user experience"