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

81–90 of 235 posts

Re: How Apple Cheats

#81

Post by loumf »

300bps wrote: post #75
gioele wrote: post #63

Let'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.

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.

Re: How Apple Cheats

#82

Post by matthewmacleod »

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've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.

Re: How Apple Cheats

#83

Post by danford »

adamlett wrote: post #70
gioele wrote: post #63

Let'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.

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.

Re: How Apple Cheats

#84

Post by cynicalkane »

jacquesm wrote: post #79
cynicalkane wrote: post #72

Earlier quoted context omitted.

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.

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

Re: How Apple Cheats

#85

Post by icantthinkofone »

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…

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.

Re: How Apple Cheats

#86

Post by [deleted] »

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.

[deleted]

Re: How Apple Cheats

#87

Post by jamra »

matthewmacleod wrote: post #82
jamra wrote: post #51

Earlier quoted context omitted.

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've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.

The API is available. It compiles just fine. It just throws an exception when you try to initialize. There is no reason for this other than UI opinions. It clearly runs fine since Apple is using it. Since this is a simple control, there are no use cases that Apple is somehow snuffing through their use.

It is not difficult at all in iOS 7 to create a modal popup on an iPhone. I don't think it would be too difficult to create a UIPopoverController clone either. I'm pretty sure it's just a case of getting the sender's frame relative to its parent's view for the arrow part of it (although I agree with Apple's UI opinion here).

Circumventing the restriction has nothing to do with private APIs. Apple added a hard-coded check on the bundle identifier. That is not a private API. As a matter of fact, nothing here is private. I don't believe you can circumvent this restriction either because there is a private variable that is a part of the UIPopoverController class. Note that the private variable is not a private API.

Re: How Apple Cheats

#88

Post by testrun »

matthewmacleod wrote: post #82
jamra wrote: post #51

Earlier quoted context omitted.

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've misunderstood this. The API is not available for iPhone apps (there could be many reasons for this, such as it having known bugs or missing features.) There's a built-in check which prevents the API being used on an iPhone. Circumventing that restriction requires accessing some private APIs, which will not be permitted by Apple.

You should read the article again. The API is there, it is working, but only for four selected applications. They are all Apple applications.

Here is the quote, it might help:

Say what?! Did Apple seriously grant access to four of their native apps by hardcoding their bundle identifiers? Yep, they sure did².

Re: How Apple Cheats

#89

Post by username42 »

mantrax5 wrote: post #17
username42 wrote: post #6

Earlier quoted context omitted.

I agree that stuff like this is expected but I am still shocked. I think that this kind of revelations means you never really own the iphone you have bought. It is more like a leasing. The only way to own what you buy is to switch to open alternatives.

Oh yeah. Without UIPopoverController on iPhone, it's like you lease your phone, and at any moment Apple may pull the string to that UIPopoverController and take their phone back. Do you even read what you write or you just mash the keyboard and hit "reply"?

Please, do not joke about my english. This article is about the iphone that has features that are blocked by Apple. If you own the phone, you remove the block and use the feature. Take the example of a car where there would be a huge stone on the middle back sit. You can not use the middle back sit without removing the stone, but the seller of the car prohibits to remove the stone.

Re: How Apple Cheats

#90

Post by pdpi »

loumf wrote: post #80
mirsadm wrote: post #66

Earlier quoted context omitted.

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.
Post reply on HN