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 APIs, and why it's really important to prevent devs from using private APIs, check out Raymond Chen's blog.)
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.
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.
If Apple is a abusing his position as OS provider by using in their apps APIs that are not available to other app developers, I'm not sure if the right answer is "go and develop for Android instead".
What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did.
> What I think it may be different in Apple's case is that they don't usually build apps that compete with apps from other developers like Microsoft did.
They sometimes do, though, with Maps for example.
... and Maps is precisely one of the apps that use private APIs.
many people still considered windows a monopoly, when you could easily buy redhat at most local stores. MS Office file formats were also considered a monopoly by Richard Stallman, because businesses used them and it was difficult to now change (there are tons of competing formats).
the tech industry likes to change definitions to fit their viewpoints.
What people think is a monopoly and the legal definition of a monopoly is different. You have to be able to show harm to e consumer, something's hat is going to be challenging to show with a handful of hidden APIs. APIs, it should be noted, that somebody could implement themselves (at least for the sample given; whether it would be approved is, of course, questionable).
On the other hand, it could be used as evidence of part of a larger anti-trust case, but given that Android devices are cheaper, perform just as well, and have a strong ecosystem, that's going to be hard to pull off.
'Local monopoly' is meaningless. Every single business has a local monopoly on supplying services under the contracts they've made with their customers. And yes, Apple's total control of iOS is very much part of the contract when buying an iPhone.
When deciding if a monopoly exists, the relevant threshold is whether the customer had other reasonable options at the time of entering the contract, and in the smartphone world they unequivocally did have other options.
iOS users do switch to Android. You don't see it all the time because users (in the US at least) are stuck in 2 year contracts and phones are an expensive purchase. But they do.
Does Honda have a "local monopoly" on sedans because Civic drivers don't usually switch to a Kia Forte overnight?
Not quite, because "sedans" is not the relevant market. It isn't that you can't buy a Kia the next time you go to buy a car, it's that once you own a Civic you have to put Civic replacement parts on it. So then you get the relevant question, does Honda have a monopoly on any Civic replacements parts? Some parts (e.g. brake pads) may be produced by third parties in competition with Honda, so for those parts the answer is no. For other Civic parts not made by anyone else, the answer is yes.
So to get back to Apple: They don't have a monopoly on smartphones, they have a monopoly on iOS app stores.
But that would require JailBreaking and voiding the warranty. An even more interesting question would be can we install iOS on an Android device without breaking the warranty? or are we in a state where all hardware warranties are determined by the OS on it?
Well, a PopOver widget is not something that gives any unique advantage to Apple. It can be replicated in a week or so by a third party.
Now, a serious API, like say only Apple getting use of the accelerometer, that would be something. This is not the case here.
But again, expecting all APIs to be public from day one is idiotic. APIs should only be made public if they are stable and ready to be supported for the future.
It could be replicated by a third party, but thanks to Apple policy, using such a third-party component could be grounds for removal from the Apple App Store.
What Apple can do and what it should do are not necessarily the same things. While it can establish privileged APIs, it should not. While it can attempt to support outside developers as a hardware company while also competing with them as a software company, it should not.
If it is easily demonstrated for this particular API, it may be present and less obvious elsewhere, including a serious API. The only way to know for sure is to inspect the code.
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].
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.
>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.
I thought the inferred relation was clear in his original argument. If Apple makes their private API public, it is then possibly infringing. That's the difference between making an alternate implementation for a private API and something that doesn't exist; there is a higher likelihood that the private API will be made public than that an entirely new API will spring forth that covers the same area. It's already written, just not public.
Not only already written, but usable on [some] iOS devices. When developers can be affected by things that Apple might do in the future, that affects their behavior in the present.
As for myself, the terms for Apple's developer program and its App Store alone are enough for me to prefer to develop in HTML5+javascript or in Android-flavored Java over Objective C for iOS. When you have only one route between you and your money, and one person standing on it, you're going to have issues eventually.
It isn't just true for Apple. When PayPal locks your account, you don't want that to bring your business to a screaming halt, so you open up alternate payment processors, like Stripe, Google, Amazon, Rixty, etc. But unlike that competitive market, there is no alternative to Apple's App Store available to non-jailbroken devices. That is a chokepoint that gives the one holding it dangerous amounts of power over you. Any solo coder or dev shop that gets their revenue exclusively from Apple's ecosystem has a banhammer of Damocles hanging over them at all times. They can't afford to take any risks like that, so they have to dance to Apple's tune, even when there is no strict obligation to do so.
The extra revenue from Apple's customers might be worth it to them. I'd rather have more freedom of choice.
>If Apple makes their private API public, it is then possibly infringing.
No, it's not. From list views to buttons to menubars and keyboards, almost all iOS widgets (private to Apple or usually public) have alternative third party implementations. Nobody is going after them.
You are actually supposed and encouraged to create your own versions of widgets - Cocoa is especially good for that, and there are even instructions in the Apple Developer Network for how to customize views and such.
Doing their own popup widget wont get them into trouble, period.
What. No. Developing your own third-party UI components, even components that look and feel like Apple components, is not grounds for removal from the App Store.
Internet Explorer's use of DUSER.DLL is only temporary.
The final version of Internet Explorer will not use it.
-- Raymond Chen [author of "The Old New Thing"]
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.
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.
Is it possible to run Windows Phone or Android on iPhones now?
They may not have a monopoly on smartphones (they wished they did, and maybe they even think they deserve one), but that's not for lack of trying and as far as systems software on hardware supplied by Apple goes they do. You can't buy an iPhone without iOs and nobody makes an alternative.
Anti-trust law does not require a monopoly per-se, 'market power' is a well established concept and within the iPhone hardware segment Apple has 100% market power when it comes to systems software, on top of that they control (through their app store) 100% of all software that gets installed on those devices.
So if an apple supplied app out-competes a 3rd party supplied app by using api's only known to apple then that might lead to trouble. I have no illusion that that would be an extremely hard case to fight/win, especially given the fact that Apple is the largest company and has a nearly unlimited budget when it comes to hiring lawyers.
You can always define something as not a monopoly by asserting the truth that people spend their money on a variety of items so the monopolist is competing with manufacturers and purveyors of beer, diesel and kites for the sales. The existence of monopoly isn't actually the interesting test, the test is usually is there an abuse of market power to the detriment of competitors. Emphasis on "abuse"
The flip side is that you can always define any supplier as a monopoly too. Apple have a monopoly on the supply of IOS and devices running IOS. Semantic definitions of monopoly aren't terribly useful. Budweiser have a monopoly on bud light. Budweiser probably can't use their market power to make miller taste worse than it does.
I didn't much care for Microsoft's anti-competitive behavior, didn't care for the stories from the grey-beard's about IBM's before that. Maybe you've heard of standard oil. I don't care for apple's anti-competitive behavior either. Microsoft and IBM always had plenty of people who defended them too. I didn't need to give Microsoft 30% (is it?) of my sales revenue to sell software that is run by my customer on a microsoft operating system. I wonder if the general reaction would have been much different if microsoft had tried charging a significant percentage of sales revenue for all software vendors selling software that ran on windows in late 90s and early 00s
A monopoly is not always a negative, it is the behaviour of the monopolyquality determines whether it is good or bad.
I remember being taught about YKK, a monopoly producer of zips, they kept their monopoly by producing good quality cheap zips. The profit made was enough that they could stay in business but not enough that it was worth other companies expending capital to get into the market.
Monopoly is one state of the market on a spectrum in a capitalist economy, it is neither good or bad it just is.
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 substitutions.
I don't know what your comment about "anti-trust law being about more than monopolies" is supposed to mean. It says nothing, and furthermore says nothing with an authority to which you are not entitled, being not an antitrust law expert. So your unsupported and unreasonable claims should be discounted accordingly.
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.
My argument is, since you insist that I don't have any, that since Apple has total control of an ecosystem they themselves created that there might be an anti-trust issue there along the lines of Microsoft when they decided to include 'mediaplayer' with every windows install when and if an Apple app competes with a 3rd party supplied app.
Whether or not I'm a subject expert or not has no bearing on that. I suspect that the answer is 'probably not', but I have seen weirder lawsuits being won. The bar in anti-trust cases is very high but there are multiple standards of proof and multiple instances of potentially anti-competitive behaviour.
Microsoft including a media player, meant that >95% of desktop PCs had a Media Player from microsoft, thus there was no 3rd party market for Media Players. But microsoft did more than merely include a Media player with regards to IE. They embeded the media player into the operating system so you could not remove it. You had no option but to get it.
Lets say there was a device that allowed you to pay tolls from your car in bitcoin. GM including a version of that in their cars would not dominate the market. It would diminish it, but not devastate. But lets say GM sold 80% of the cars in the world. Even then, including the device wouldn't be a violation of anti-trust.
Through the early 90s, MS did this often, Media Players, Disk Compression, Defrag, the list goes on and on.
But, if GM had 95% of the car market, and included a device that only paid in fiat currency, and it was 'artificially' tied into the ignition computer, so removing it made the cars useless. Then had the device subtly interfere with any alternate device. Finally, there was evidence, (emails from CEOs, VPS) that GM did this with the sole purpose of preventing BitCoin as a currency. Then you'll understand the scope of M$'s efforts in the browser wars, and what it took to finally get them at antitrust.
You're missing the key point that Microsoft makes an OS designed to run on hardware they don't make. Apple makes the iP* hardware and the entwined OS to run on it, much like PlayStation, Xbox, etc. Apple isn't trying to elbow other people off someone else's hardware - but Microsoft did, and got slapped down for it.
Yes, somebody does "make an alternative". There are hundreds of smartphones which are, at base specs, little different from an iPhone and run a variety of viable competing operating systems.
A monopoly occurs when nobody else can compete via resources the monopoly company doesn't ever own, either because the monopoly buys out every option (usually at a loss) for the sole purpose of denying access, or by conspiring to otherwise block fair competition. MS was in violation because (to at least a significant degree) they made everyone buy Windows (or, in a somewhat misguided case, mediaplayer), even if the hardware manufacturer was deliberately not installing Windows on a machine which the customer did not want Windows on; MS was interfering in a transaction they had no right to. Apple, on the other hand, makes the hardware and OS, and has every right to not sell one without the other - and if you don't want one or the other, there are plenty of fairly competing alternatives.
> Apple makes the iP* hardware and the entwined OS to run on it, much like PlayStation, Xbox, etc.
Tying software to hardware is not some magic immunity to antitrust. If you have a monopoly on either of them then the tying itself is illegal! If Microsoft did the same thing in the 90s all it would have done for them is to have Dell and HP filing complaints with the FTC alongside Sun and Netscape.
What about first-party console games that sell better than some third-party games? Should Nintendo/Microsoft Games/Sony all be investigated for antitrust?
"Nobody makes an alternative" is demonstrably, empirically false. Android, BlackBerry, Windows, Tizen, etc.
In fact, my entire household uses Android phones, as do all my family and with the exception of three individuals (2 Apple, 1 Windows), all my friends.
Did you purposefully misunderstand that sentence or was it simply not clear? To complete the sentence in an unambiguous way 'alternative os for apple mobile hardware'.
Right, but so what? If there's alternative hardware, then there's an alternative OS; nobody is forced to use Apple mobile hardware, nobody is forced to use iOS. The fact that you can't use arbitrary operating systems on arbitrary hardware doesn't mean that Apple has a monopoly.
I begin to question whether you understand what "alternative" means in the context of the interaction between hardware and software. It's a somewhat gray area, sure, but it's not that gray. There are many, many, many different mobile devices which one can use non-Apple software and non-Apple OSes on. Real, actual, genuine alternatives to Apple mobile devices exist in literally every sense of the word "alternative". In that context, that one cannot install an alternative OS on an Apple product is irrelevant and doesn't mean, at all, by any rational measure, that therefore "alternatives don't exist." It's simply facile to suggest otherwise.
What you're failing to understand is that there is more than one market in question. Nobody is saying that Apple has a monopoly on smartphones. The issue is that Apple has a monopoly on iOS app distribution. It's a completely different market, and there is no substitute product in that market. You can't get iPhone apps from Google Play and you can't run Android apps on your iPhone.
No, the market is "consumers of mobile devices, upon which apps can be distributed or installed." What you're identifying as it's own market is actually a brand; a segment of a larger market. A market in which there is plenty of competition, I'd add.
What you're proposing could easily be said about any supply of any good or service owned by anybody or any company. If each company's product distribution constitutes a monopoly of "Product X Market", then "monopoly" has been redefined.
I'm not arguing that what Apple has done in the mobile space is good, or even ethical or appropriate. I'm simply arguing that they do not own a monopoly, in any sense of the word that is reasonable in this context.
> No, the market is "consumers of mobile devices, upon which apps can be distributed or installed."
Let me see if I can explain why that's wrong.
> What you're proposing could easily be said about any supply of any good or service owned by anybody or any company. If each company's product distribution constitutes a monopoly of "Product X Market", then "monopoly" has been redefined.
Technically a trademark is a monopoly, albeit a legally granted one. But that's not what I'm talking about.
For example, Exxon 87 unleaded gasoline is completely fungible with BP 87 unleaded gasoline. They're for all practical purposes the same product, so they're in the same market even though they're different brands. An iPhone is less fungible with, say, a Samsung phone. They're still close enough substitutes to be plausibly considered the same market (although, for example, in the Microsoft case Windows and MacOS were found not to be in the same market). But that's still not the market I'm talking about. I'm talking about distribution of apps for these devices.
Let's start with a preliminary issue. Are iPhone apps in the same market as Android apps? Can they be used as substitutes for one another? The answer is clearly no. You can't run an Android app on an iPhone. This is substantially why Windows and MacOS were found not to be in the same market, but again that's not the market I'm interested in here. The point is that iOS apps and Android apps are not substitutes. And that doesn't even necessarily separate the markets for the devices -- because even though Angry Birds for iOS is a different product sold to different customers than Angry Birds for Android, the fact that the quantity and quality of apps available for each platform is comparable means that the platforms themselves are still reasonable substitutes for one another. But you can imagine how that could change if app developers stopped developing for one platform or the other, which reinforces the point.
So back to the apps. Is there competition for the production of iOS apps? Of course there is. There are thousands of developers; that's not at issue. But distribution is different than production. General Electric is not Walmart. Is there competition for distribution? No. No one is allowed to distribute iOS apps but Apple. There are no substitutes, Apple has a distribution monopoly in that market.
That is not how most "brands" work. You don't have to buy cars through Exxon. You don't have to buy gasoline through Ford. You don't even have to buy Android apps through Google Play. Apple is doing something unusual which results in the monopoly.
While it's comforting to apply the word's meaning to all different kinds of things, the word "monopoly" is by definition tied to a size and scope of entire markets, types of goods, and services. It doesn't really apply to services within services unless those services are entire markets, and even then it's iffy at best. To say 'I have a monopoly on my toilet', while technically I control all access to it, is incorrect because the word 'monopoly' applies to all toilets in a geographic area specifically larger than my bathroom. There is some gray area in the definition. A more appropriate use of 'monopoly' is, "does Apple control software on all tablets?", no. 'Does Apple control all tablet software in the new york area?' no. 'Does Apple control all popup widgets on all Apple Tablets in the New York area?' Yes, but that is not by definition, "a monopoly".
Ask this question: Can you identify a group of customers who cannot reasonably obtain the product or service (i.e. distribution of software) from anyone other than Apple? The answer is yes. People who already own Apple iOS products. Because Apple prohibits anyone from selling to them other than through its own store and having to replace the customer's entire device to change that is not reasonable.
This is different from your toilet because other toilets are fungible with yours. You can't use an Android app store on an iPhone, they're not fungible.
This would not be the case if there were competing app stores for iOS and competing (or modifiable) operating systems for Apple hardware. That is why it hasn't been relevant in most other markets. You don't have to buy all your water from Delta after installing one of their faucets and you didn't have to buy all your music from Sony after buying a Walkman. Apple wanted to change the rules, that changes the scope of the market.
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 from switching.
A monopoly means that there's no choice for the whole product category. Back in the bad old days, if you wanted a home computer, then you were buying a Microsoft operating system whether you wanted to or not. That's what a monopoly looks like. (Yes, there were a couple of other niche players out there, like Apple. They didn't have any significant portion of the market, though. You can argue that they matter, but if so, then you're arguing that Microsoft didn't have an OS monopoly because of these competitors, which kind of reinforces my point.)
I believe the practice of requiring products to be purchased together is called "tying" and it's also problematic, but a different concept from a monopoly.
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 from companies that aren't Apple. They just have to buy an Android device first.
The problem with claiming that Android apps are competition for iOS apps is that to get competition for a $1 app you have to replace a $500 device. That isn't reasonable. It's like claiming Google Fiber is competition for Comcast because you can move to Kansas.
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.
> 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.
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.
> Why does the price of the iPhone, which you already own and which is a sunk cost, factor into it?
Exchanging $500 for an iPhone was a sunk cost. You now have an iPhone with an expected future value to you of at least $500 (or why did you pay that much for it?). Using an Android phone instead of the iPhone you already have prevents you from extracting that expected future value from the iPhone. The more you use the Android phone instead, the less value you can extract from the iPhone. It's effectively a $500 opportunity cost.
> 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 cellular service is so unimportant then why does everybody pay so much for it?
> 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.
Your efforts to reduce the switching cost are doing nothing but incurring more switching costs. A $30 Android phone is not comparable to a $500 iPhone. It will have a slower CPU, less memory, less storage, a lower resolution screen, etc. It's liable to be running an old version of Android that doesn't support newer apps, and any apps it does run will run more slowly and otherwise not work as well as they would on the newer iPhone (or newer Android device). These are all costs -- costs the market values at hundreds of dollars or the price disparity wouldn't exist. Meanwhile even $30 is a significant price to pay against a market for $1 apps.
And sharing a SIM card is an enormous pain in the ass. If you have an iPhone, other iPhones remember that and route text messages to iMessage. Your Android phone won't receive them when it has the SIM card. Any app you use on either device which is dependent on receiving events from the network won't work outside of WiFi whenever you put the SIM card in the other device, and every time you go to a new place you get to type the WiFi password twice. "Is an enormous pain in the ass" is a significant switching cost.
Which is before we even get to all the other costs of switching platforms, like trying to move your data, which is only difficult when it isn't impossible.
> who cannot reasonably obtain the product or service
But it's not reasonable. A major selling point of iOS devices is that it's a walled garden. You knew that (or had a chance to learn it) when you bought your iOS device and you had a reasonable alternative (Android) without this limitation.
You want to have your cake and eat it too. That's all well, but the fact that you can't doesn't make Apple a monopoly.
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 Apple. And by compete I mean neither Apple nor Andriod nor WindowsPhone 'owns' >90% of the mobile market.
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, because its hardware was work station hardware. Which had to compete with Silicon Graphics, IBM, Apple, Next, etc.
> 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.
The rest of the comment was also not an argument, it was just a restatement of the statement you were denying. Are you claiming that there is no circumstance in which Sun exercising control over what software could be run on the hardware of its customers could lead to an antitrust violation? That seems implausible. Once you're exercising gatekeeper control in that way, you would among other things for example have control over any downstream monopolies, such as any enterprise software vendors with a monopoly in their own market whose software ran only on Solaris/SPARC and could not easily be ported.
>Are you claiming that there is no circumstance in which Sun exercising control over what software could be run on the hardware of its customers could lead to an antitrust violation?
No, I'm claiming that under the circustances that you (or the OP) described in the previous comment it wouldn't lead to an antitrust violation.
I can't talk for "under ANY circustances".
>That seems implausible
Well, the low allows it and companies have been doing it for ages, e.g with game consoles.
> No, I'm claiming that under the circustances that you (or the OP) described in the previous comment it wouldn't lead to an antitrust violation.
The OP was claiming that the reason Sun was not prosecuted for an antitrust violation despite the lack of OS competition for SPARC hardware was that other hardware existed in competition with SPARC. But the reason there was no competing OS to run on SPARC is not the same reason that there is no competing OS to run on iPhone. In the case of SPARC the lack of OS competition was not a result of any interference on the part of Sun. When Linux was subsequently ported to SPARC they made no effort to prevent it, I imagine they probably did most of the work. In the case of iPhone the lack of OS and app store competition is directly a result of Apple thwarting it. It is extremely likely that at least one of Android/Ubuntu/FirefoxOS/etc. would be ported to iPhone hardware in the alternative, and that Amazon or others would be operating competing app stores. So the existence of hardware competition was not the only thing saving Sun from an antitrust violation -- even if they had a strong hardware monopoly their behavior wouldn't have been an abuse of it. Apple is behaving differently. Its behavior is distinguishable from that of Sun in a way that makes an antitrust violation significantly more plausible. There is a much stronger argument that Apple exerts monopoly power over the market for iOS applications than Sun ever did over the market for Solaris applications. Which part of this do you deny?
> Well, the low allows it and companies have been doing it for ages, e.g with game consoles.
I'm not sure how clear that is. Was there an antitrust case against a game console maker in which they were vindicated? Just because the government has never prosecuted anyone doesn't mean it isn't a violation. Antitrust law is about as clear as mud and they rarely prosecute anybody even in cases of much less nuanced violations.
"The issue central to the case was whether Microsoft was allowed to bundle its flagship Internet Explorer (IE) web browser software with its Microsoft Windows operating system. Bundling them together is alleged to have been responsible for Microsoft's victory in the browser wars"
Does this apply to the same extent to phones as it does to an operating system? Apple has made devices that don't even have an app store - nobody cries foul that the Nokia 1100 only runs Nokia software.
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.
You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only). Businesses universally use PowerPoint, Excel, and Word. If you work in industry or manufacturing, you may have noticed that the drivers for specialist equipment are always for Windows. "Industry Standard" software like 3ds Max only runs on Windows. Government still overwhelmingly uses Windows, which is why it's still "news" when somewhere switches to Linux (usually Berlin again). Healthcare uses Windows.
In the consumer OS space, nobody is even trying to compete with them commercially. The worst they have to worry about there is poor publicity from a lemon version of Windows, because no matter how crap it is all new computers will still ship with it.
> You cannot buy a laptop not running Windows, unless you go Apple (a very small percentage of laptops sold, and high-end only).
Or ChromeOS. Or more traditional Linux (a number of vendors sell them). Last I checked (though I haven't for a while) you could even get OS-free laptops on NewEgg.
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.
Have you not seen google maps, amazon's kindle app, the many weather and stock apps, Instagram for taking and sharing photos? I can't think of a native app that doesn't have competition.
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 the feature may cause warnings. Backwards compatibility should not be expected.
Stability: 1 - Experimental This feature was introduced recently, and may change or be removed in future versions. Please try it out and provide feedback. If it addresses a use-case that is important to you, tell the node core team.
Stability: 2 - Unstable The API is in the process of settling, but has not yet had sufficient real-world testing to be considered stable. Backwards-compatibility will be maintained if reasonable.
Stability: 3 - Stable The API has proven satisfactory, but cleanup in the underlying code may cause minor changes. Backwards-compatibility is guaranteed.
Stability: 4 - API Frozen This API has been tested extensively in production and is unlikely to ever have to change.
Stability: 5 - Locked Unless serious bugs are found, this code will not ever change. Please do not suggest changes in this area; they will be refused.
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.
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.
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.
This doesn't mean it runs fine, it means that in the particular cases that Apple uses the API for it runs fine. Apple may not have tested the API sufficiently for broader usage, or made special cases in the API to support their specific internal usage. Public usage of the API on iPhones may result in concerns about security, stability, or it may simply not behave on iPhones the way most developers would expect it to, and Apple doesn't want to create an API that will result in a lot of application bugs they can't fix themselves.
No one outside of Apple knows exactly why this API is only supported publicly on iPads and not iPhones. Concluding the reason isn't valid is premature.
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 can be run just fine on an iPhone by reversing the code.
It uses CGRects to lay itself out. This is prevalent in one of the delegate callbacks.
It uses the UIPopoverControllerDelegate in order to send the calling class callbacks relative to certain events. That is standard code on iOS both for iPads and iPhones. When creating a universal app, I have never had to change how I use delegates between the iPad and the iPhone.
This is because they both run objective C with the same SDK. When compiling the iPad version of your XCode project, you may have to change your build target, which is indicative of differences in the environment (perhaps only the CPU architecture). You do not, however, change an SDK. The classes you import are identical.
I believe Apple's reasoning is entirely valid. Popovers look terrible on small devices. That is what the Apple guidelines state. I like that they are very opinionated with their design guidelines. There are still a very many ways of doing things and staying inside those guidelines.
Edit: I believe that the presence of the UIPopoverController while building an iOS app is proof enough that the SDKs are identical.
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.
> [it's reasonable not to commit to long-term API support lightly]
Another dimension, which I think primes here, is potential for abuse: things either likely to be used for scammy features, or leading to 99% of results in very poor tastes (think of those as the descendants of the <blink> tag from the 90's). It's simpler and creates less outrage to block those APIs than to reject most of the applications misusing them.
I think that's one of the reasons why they disallowed compatibility layers: it would have encouraged poor UX as, by definition, they only offer the common denominator of all the targeted platforms (I'm not naive about other motives, but they're off-topic).
What Apple sales is great user experience. App developers are only welcome as long as they're improving that experience. They're currently useful to Apple as a whole, but they aren't Apple's customers.
And of course Apple trusts itself to respect its own sense of taste, so doesn't need any self-limitation. They're your host in their personal walled garden, they can't even imagine that you'd ask to "compete with them on equal grounds".
As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent. They're intended for serious alerts requiring immediate action from the user, and they're often used as a substitute for a usable notification UI.
> As for this specific feature, from its name I'd guess it's some form of popup? I'd tend to side with Apple then: the vast majority of popup uses are bad: ugly, extremely disruptive, inconsistent.
It would be one thing if this was just built-in apps that need special capabilities. It's reasonable for, say, Settings to use private APIs, because it's special. (I don't agree with that, and would like third-party apps to be allowed to change that stuff too, but I don't think it's an unreasonable stance.)
However, this is iBooks, which you get from the App Store just like all third-party apps. It's explicitly competing with products from third-party developers. In this area, there should be a level playing field.
When us third-party developers distribute on the App Store, we have to agree to a contract that, among other things, states that our apps will not use private APIs. Why do Apple's apps, when distributed through the App Store, not follow the same rules? Why should they get special treatment for apps that aren't built in to the OS and which are distributed using the same channels the rest of us use?
This popover example is fairly trivial, since nothing stops you from building your own version of it and shipping it in your app, but it illustrates the point. A more significant example is the screen brightness control. iBooks has a slider that you can use to adjust the brightness of the screen. This brightness adjustment uses private API, and because of that, other eBook readers cannot replicate that feature. There is no technical reason third-party apps couldn't do this (they have the same access to the device that iBooks does) but Apple doesn't allow it.
The Kindle app, for example, has a brightness slider too. Except it doesn't adjust the screen brightness. It just adjusts the gray level of the white background, while leaving the backlight at original strength. This means that you lose contrast and use more battery power, meaning that the Kindle app is inherently worse because Apple isn't playing fair.
This is less important these days, now that Control Center lets you easily access the device brightness from anywhere. It was a big hit against Kindle's usability for years, though.
If taken too far, this can lead to two-tiers of applications, which can be incredibly bad for the eco-system. On early Windows Phone 7, Nokia used an entirely different api to other apps, that gave much more freedom. So Nokia apps both allowed custom styles, and were much faster. This meant no apps on the store could really compete with the system apps. I'm unsure if this changed with Windows Phone 8, though I'm sure it would have.
There's a difference between private APIs which are convenient for Apple to use and inconvenient for Apple to let others use but developers can create alternatives without much difficulty, vs private APIs which give Apple an outright unfair advantage over others.
Are there any private APIs which really do amount to "unfair advantage for Apple"? or does the whole issue amount to sniveling about not being able to play with all their toys and having to bring your own?
> 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.
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 APIs, and why it's really important to prevent devs from using private APIs, check out Raymond Chen's blog.)