Live data from Hacker News

How Apple Cheats

marksands.github.io

201–210 of 235 posts

Re: How Apple Cheats

#201

Earlier quoted context omitted.

Nonsense. I'm using WYPopoverController[1] in some of my apps and they're a-ok. On the component's page they even have links to apps in the App Store that use it[2]. [1] https://www.cocoacontrols.com/controls/wypopovercontroller [2] https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=...

Whether they have removed apps that use is irrelevant. That they can at any point remove them because of their policies but don't should not be lauded, it just creates an air of confusion that they can use to their benefit as they see fit.

Perhaps I was modded down to oblivion because what I said was too obvious, and therefore not adding to the discussion?

The fact remains that there are plenty of documented examples of Apple tossing apps from its App Store for reasons that amount to little more than corporate whim or gatekeeper prerogative, or for no adequately explained reasons at all.

Should Apple ever decide that its popover API is ready for prime time, it could yank all apps that do not use it and demand that the Apple popover be used instead. I seem to recall something similar happening with third-party apps that improved upon the native camera API, but my memory may be suspect.

Re: How Apple Cheats

#202

Earlier quoted context omitted.

People who already own Apple iOS products can easily obtain apps from companies that aren't Apple. They just have to buy an Android device first. And while I agree that this is a barrier, it doesn't sit right with me at all to cry "monopoly" in a situation where other companies sell products with the same capabilities (indeed, in greater number than Apple sells them) and there's nothing that inherently prevents you f…

The important thing to understand is that there is a difference between having a monopoly (which is not illegal) and abusing it (which is). That's what tying is about. If you have a monopoly, tying is an example of monopoly abuse. It's an attempt to leverage the monopoly in one market (e.g. operating systems) into a new market (e.g. web browsers). > People who already own Apple iOS products can easily obtain apps fro…

I don't see why it's unreasonable to replace a $500 device, when you already had to buy a $500 device in the first place to get access to iOS apps.

If you had to move every time you signed up for any broadband service, even the first one you ever sign up for, then that might be a comparable analogy.

Nintendo controls the availability of games for my Wii, and I'd have to spend a chunk of money to switch to another gaming platform, but that doesn't make them a monopoly either.

While I think that $500 doesn't break my point, I'd still also like to point out that it's wildly inflated. If you own an iOS device and want to run Android apps, the cost of entry is more like $30-50, even if you don't consider used hardware. Even coming the other way, prices start at $229.

Re: How Apple Cheats

#203

Earlier quoted context omitted.

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.

At the time, there was only the desktop market and no mobile to speak of. Microsoft still dominates the desktop but how that figures into a monopoly calculation, I'm not sure.

Re: How Apple Cheats

#204

Earlier quoted context omitted.

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

Even though they're called 'private' they're not really private though. So saying > open source projects have private APIs too Is misleading (and unethical). As far as APIs go, most project have a system to rate features called a stability index. Developers should take note and me aware of it. If something looks like it's going to be broken in the future, don't use it. I'd also like to add that if you don't update ap…

>Even though they're called 'private' they're not really private though. So saying "open source projects have private APIs too" Is misleading (and unethical)

I call BS. And I'm offended by the "unethical" part.

First, they are totally private. Private is a well defined term in software engineering. It's a specific designation of code as a "you should not bypass this" by the developers.

Some languages have specific keywords for this very purpose (such as, well, the keyword "private"). Others use some tricks like "_" prefix to mark functions for internal use. In any case, you are not supposed to use those and mess with it.

And while you might get away with not obeying that in an open source program (if you consider your app breaking when that API changes upstream "getting away with it"), that's not the case in close source, long term supported platforms, where you don't want to have paid users shouting at you, or having to maintain some half-written, immature version of your API just because some idiot used it before it was ready.

>As far as APIs go, most project have a system to rate features called a stability index.

Private APIs are supplementary to the "stability index" contract. It means "this is subject to change and/or this is meant for internal use only".

There's not a large project that doesn't have private APIs. Including Open Source ones, like Java or Mono or Boost, etc etc.

>I'd also like to add that if you don't update apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.

Not sure where you got that from. That doesn't even make sense, computing wise. Apps run at the same speed at all times for the same inputs. The only time you might need to update them is when the OS and underlying libraries change incombatibly. Surely not to make them "go faster".

(Whereas a programmer has made the new version faster is beside the point. He might as well made the new version slower and more bloated. The thing is, apps do not get "slower" as time goes by. Perhaps you conflate them with something like disk fragmentation?).

Re: How Apple Cheats

#205

Earlier quoted context omitted.

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."

I see both approaches as merely tools to achieve what you want. I don't see any of those approaches as good or bad. If one wants to make only Apple's decision and practice look bad, then yes they could do absolute comparison. Alternatively, you could do a relative comparison to see that this is a standard practice followed by all major platforms providers, that compete with their customers.

Re: How Apple Cheats

#206
post #170

Earlier quoted context omitted.

This class only has one function. It pops up. That's all. There is a UIView that shows content. It literally only has one job. The environment that runs the iPad and the iPhone is the same. You can run the same exact code on either device. The UI code between devices are equivalent. They have the same class hierarchies. UIPopoverViewController is an NSObject. It has one function that the writer of this article proved…

And yet, there is something Apple knows about it, which you don't, that leads Apple to prevent general use thereof. They are in a position to abruptly change how it's used in their own software, but are not in a position to make you abruptly change how you use it; not letting you use it is fair in this situation.

Since there is one init function, any changes to the SDK will cascade outwards automatically.

I think that you are trying to make some sort of theoretical point about theoretical issues with the SDK. Do you program on iOS devices?

There is a reason why they do not want users to use this on an iPhone. It is the same reason why they do not want users to use a numeric-only keyboard on the iPad. It is because it does not look nice. Launching a popover from the bottom half of an iPhone doesn't look quite right. That is all. There are no API problems. A popover is just a view that appears in dynamic locations on the device. When programming something like that in objective-c, you use CGRect to provide an x, y, width, and height. I don't know why people keep trying to argue these theoretical points without understanding the simplicity of the control.

Re: How Apple Cheats

#207

Earlier quoted context omitted.

The important thing to understand is that there is a difference between having a monopoly (which is not illegal) and abusing it (which is). That's what tying is about. If you have a monopoly, tying is an example of monopoly abuse. It's an attempt to leverage the monopoly in one market (e.g. operating systems) into a new market (e.g. web browsers). > People who already own Apple iOS products can easily obtain apps fro…

I don't see why it's unreasonable to replace a $500 device, when you already had to buy a $500 device in the first place to get access to iOS apps. If you had to move every time you signed up for any broadband service, even the first one you ever sign up for, then that might be a comparable analogy. Nintendo controls the availability of games for my Wii, and I'd have to spend a chunk of money to switch to another gam…

> I don't see why it's unreasonable to replace a $500 device, when you already had to buy a $500 device in the first place to get access to iOS apps.

You paid $500 for a device that can browse the internet, make phone calls from the back of a moving car, give you directions from anywhere to anywhere, record video, etc. You don't see how having to replace that entire device in order to buy a $1 app is unreasonable?

> If you had to move every time you signed up for any broadband service, even the first one you ever sign up for, then that might be a comparable analogy.

1) Where Comcast is the only provider in your area, you do. 2) In areas where Comcast has actual competitors, that would imply that Comcast is less of a monopoly than Apple. I don't think that's what you were going for.

> Nintendo controls the availability of games for my Wii, and I'd have to spend a chunk of money to switch to another gaming platform, but that doesn't make them a monopoly either.

Sure it does. It's exactly the same thing. Although Apple does have a higher barrier to switching, because cost of phone:cost of app is a much bigger ratio than cost of console:cost of game.

> While I think that $500 doesn't break my point, I'd still also like to point out that it's wildly inflated. If you own an iOS device and want to run Android apps, the cost of entry is more like $30-50, even if you don't consider used hardware. Even coming the other way, prices start at $229.

The $500 isn't the cost of the Android device, it's the cost of the iPhone you canceled the service on. Unless you want to say you're going to keep the iPhone too, in which case you're going to have to add in the recurring cost of a second cellular plan. And the market value of the huge inconvenience of having half your stuff on each of two devices.

Re: How Apple Cheats

#208

Earlier quoted context omitted.

I don't see why it's unreasonable to replace a $500 device, when you already had to buy a $500 device in the first place to get access to iOS apps. If you had to move every time you signed up for any broadband service, even the first one you ever sign up for, then that might be a comparable analogy. Nintendo controls the availability of games for my Wii, and I'd have to spend a chunk of money to switch to another gam…

> I don't see why it's unreasonable to replace a $500 device, when you already had to buy a $500 device in the first place to get access to iOS apps. You paid $500 for a device that can browse the internet, make phone calls from the back of a moving car, give you directions from anywhere to anywhere, record video, etc. You don't see how having to replace that entire device in order to buy a $1 app is unreasonable? >…

Why does the price of the iPhone, which you already own and which is a sunk cost, factor into it?

Further, why do cellular services factor into any of this? Both iOS and Android devices run apps fine without cellular service. In fact, lots of them don't even have the ability to use cellular service.

If you're insisting on only examining the scenario where you own an iPhone and a long-term cellular contract, then you can still switch to Android for $30-50 through the simple expedient of buying an unlocked Android phone, taking the SIM out of your iPhone, and placing it in the Android phone.

Re: How Apple Cheats

#209

Earlier quoted context omitted.

Whether they have removed apps that use is irrelevant. That they can at any point remove them because of their policies but don't should not be lauded, it just creates an air of confusion that they can use to their benefit as they see fit.

Perhaps I was modded down to oblivion because what I said was too obvious, and therefore not adding to the discussion? The fact remains that there are plenty of documented examples of Apple tossing apps from its App Store for reasons that amount to little more than corporate whim or gatekeeper prerogative, or for no adequately explained reasons at all. Should Apple ever decide that its popover API is ready for prime…

>The fact remains that there are plenty of documented examples of Apple tossing apps from its App Store for reasons that amount to little more than corporate whim or gatekeeper prerogative, or for no adequately explained reasons at all.

Which is totally unrelated to the discussion about the private API, and if you can replicate a widget provided in one. Which you can.

Re: How Apple Cheats

#210

Earlier quoted context omitted.

I don't think your understanding how a Monopoly applied in the situation with Microsoft. Microsoft's Anti-trust suite was because of its web browser's dominance, IE was during the anti-trust suite upwards of 95% of all browsers on the Internet, this was because of bundling and defaults. While other OS's may not execute on Apple's own hardware, other hardware exists (other smart phones) that directly compete with Appl…

> This is how Sun didn't get involved in trust litigation over the fact that Solaris was the only OS that ran on Sun SPARC hardware There is also the fact that Sun didn't prohibit other operating system or application vendors from making operating systems or applications for its hardware by locking the boot loader.

No, that didn't come into play at all. Sun could have locked it whichever way they wanted, and still they wouldn't get involved in such litigation.
Post reply on HN