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

101–110 of 235 posts

Re: How Apple Cheats

#101

Post by coldtea »

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.

You misunderstood how discussion works. YOU have to provide the arguments first.

Re: How Apple Cheats

#103

Post by coldtea »

cookiecaper wrote: post #46
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…

Open-source operating systems seem to have pretty secure applications without depending on secret or undocumented API calls. aptitude and pacman are just normal Linux programs. How come App Store can't be a normal OS X program?

First, this isn't about "secure". It's about an API not being ready for prime time, so only used in a controlled manner.

Second, open source projects have private APIs too. And if you use them, you risk breakage of your app, as soon as the API gets changed (which can at any time, under for a minor version update -- after all, it was meant to be private).

Also, there's another, laxer platform called Android. It has around double the market share, but (according to studies) 98% share of all mobile malware.

Re: How Apple Cheats

#104

Post by craigching »

matthewmacleod wrote: post #22

Like others, I'm fairly convinced that this is simply not enabled because Apple haven't done the necessary amount of work to ensure that the UIPopoverController on an iPhone is stable, API-compliant, and well-tested. Specific use-cases under their control can be extensively tested, and it may be the case that e.g. iBooks only uses a subset of the functionality. More to the point, there's nothing to be gained from thi…

> Apple haven't done the necessary amount of work to ensure that the UIPopoverController on an iPhone is stable, API-compliant, and well-tested.

And, to add to what you're saying, maybe this is how they're testing it, by using it in their own widely used apps.

I agree with the "nothing to see here" crowd, if I wanted the feature I'd develop it myself in this case. Doesn't seem like it would be that bad. Microsoft has always had their own controls too that they never exposed to the world leaving it up to applications developers to replicate if they wanted the functionality.

Re: How Apple Cheats

#105

Post by Geee »

username42 wrote: post #89
mantrax5 wrote: post #17

Earlier quoted context omitted.

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.

No, there is a stone in every the car but Apple hides it and you can't unhide it.

Re: How Apple Cheats

#106

Post by endersshadow »

room271 wrote: post #77
chaz72 wrote: post #39

Earlier quoted context omitted.

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.

It's not just the person you're responding to--the FTC looks only at relatively pure monopolies for anti-trust violations. There are lots of things that are legal as a player in a competitive market versus illegal as a monopoly. The US has a long history with pure monopolies, which are why the laws are the way they are.

You can argue until you're blue in the face that the FTC should look at other things, as well, but I'm not sure you'll get very far.

Re: How Apple Cheats

#107

Post by zackboe »

Google does a similar thing with Chrome and the Hangouts extension[0].

They have two APIs that are available behind a flag or in a dev branch. Panels[1], the always-on-top type windows Hangouts uses, and the notification area icon[2].

Google hardcodes Hangout's extension id in Chromium to allow it to use these features before they're available to the public.[3]

[0]https://chrome.google.com/webstore/detail/hangouts/nckgahada...

[1] http://www.chromium.org/developers/design-documents/extensio...

[2] https://code.google.com/p/chromium/issues/detail?id=142450

[3] https://code.google.com/p/chromium/codesearch#chromium/src/c...

Re: How Apple Cheats

#108

Post by craigching »

chrisdevereux wrote: post #11

This is a fairly straightforward, boring UI class which you could easily implement yourself, or use one of the many open source replacements[1]. Whatever the reasons for making this API private on the iPhone, I seriously doubt that it's because they are trying to give their own apps an unfair advantage. If that was their game here, I can think of many other parts of the iOS frameworks that would be kept private befor…

> I seriously doubt that it's because they are trying to give their own apps an unfair advantage.

Yes, that hits the nail on the head. Great point.

Re: How Apple Cheats

#109

Post by collyw »

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…

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.

Re: How Apple Cheats

#110

Post by S_A_P »

I can't really call this cheating. It maybe slightly inelegant or inconvenient but there are many reasons to keep an API private. There could be security implications, un finalized functionality. The fact is that there are probably hundreds of API calls in iOS that can be used improperly which can harm ux or security is a damn good reason to disallow them.
Post reply on HN