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

121–130 of 235 posts

Re: How Apple Cheats

#121

Post by GrinningFool »

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.

But from a legal perspective [IANAL, but I'm pretty confident on this one], they can engineer the system to give them an advantage as long as they don't have an monopoly. When a company is a monopoly, new rules do apply.

Re: How Apple Cheats

#122

Post by al2o3cr »

loup-vaillant wrote: post #112
dilap wrote: post #42

Earlier quoted context omitted.

Yeah, in a monopoly situation I see where you're coming from, but Apple has very healthy competition from Android. It's not currently in Apple's interest to hobble 3rd party apps; quite the opposite.

It's a local monopoly. An iOS user won't just switch to Android. Not overnight, at least.

"local monopoly": meaningless. That's like saying that Gmail has a "local monopoly" on web-based email because switching would be a hassle.

Re: How Apple Cheats

#123

Post by jasallen »

As others are pointing out, yes, it's reasonable to not publish an API that you've chosen not to invest in supporting forever.

But it still feels like this is wrong even though we know the above. The reason it feels wrong comes back, as it always does, to Apple's walled garden. If we could 'use it at our own risk' as we might with an unpublished Android API or an unpublished Windows API, everyone would be fine with it.

But when 'unpublished API' means 'if you go near it your app is dead' that is a much less reasonable thing.

Re: How Apple Cheats

#125

Post by username42 »

Geee wrote: post #105
username42 wrote: post #89

Earlier quoted context omitted.

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.

Well, I have lost 7 karma points because I agree with an article.

Re: How Apple Cheats

#126

Post by danudey »

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…

> You've got to support the API forever, and future design directions are constrained.

Actually, I think part of the reason for Apple's reluctance is that they don't do this; they'll gladly deprecate APIs and remove them in future versions, but that's about as bad because now you're breaking apps (which admittedly are unable or unwilling to update).

This is especially a problem in corporate environments with custom iPad apps; if the customer doesn't want to pay the developer to update for newer iOS versions, then they basically can't buy new devices once the API is removed, because their app won't work. This is why Microsoft keeps APIs around forever, and why businesses keep running XP until ten years has gone by and they start getting hammered with 0-days.

Re: How Apple Cheats

#127

Post by taumhn »

danford wrote: post #73
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…

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

I'm actually rather happy with the Apple philosophy of not opening APIs early and supporting them as long as possible when they've been made public, rather than having to check my app against 6 levels of API stability... thank you very much.

Re: How Apple Cheats

#128

Post by username42 »

mantrax5 wrote: post #31
probably_wrong wrote: post #8

Earlier quoted context omitted.

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

> Apple has no dominant position in smartphones

Where do you live ? Inform yourself (https://www.comscore.com/Insights/Press_Releases/2014/3/comS...). Apple has 41.6% when the second one, Samsung has 26.7%

Re: How Apple Cheats

#129

Post by vanderZwan »

abhigupta wrote: post #119
collyw wrote: post #109

Earlier quoted context omitted.

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.

I find that such relative comparison put things in perspective.

My problem with it is that it tends to put things in the wrong perspective. Should we judge things by comparing them to other crappy products, or by a reasonable expectation of what things should be like independent of that? If it's the latter, then what's the point of comparing it with the former? It just gives a false sense of "it's not so bad after all."

Re: How Apple Cheats

#130

Post by interpol_p »

I don't think it's a big deal that Apple reserves some API functionality for their own apps — you can always re-create this from scratch, after all. They just aren't ready to fully support the popover controller API on iPhone. I'd rather that Apple be committed to every public API they publish (they aren't, but anything in that direction is a good thing).

What I don't like about this is how they chose to implement the restriction. Messy, hacky and inelegant.

Post reply on HN