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.
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 this example. UIPopoverController is a relatively boring UI element which it's not too complex to implement by hand, and there are a bunch of open replacements. It was also only relatively recently (Lion?) introduced into MacOS. If they are trying to find a competitive advantage here, they're not doing a good job of it…
> 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.
What I find confusing is why the API would be acceptable on an iPad and not on an iPhone. It seems unlikely that Apple would be willing to devote the resources to testing the element on one and not the other, or that the software behind the two implementations is different enough that testing would not carry between the two. And, if that were the case, surely it would have been easier to just not release the API at all?
Rather, it sounds like someone at Apple decided that popover widgets provide a poor user experience in small form factors unless they are carefully designed, so they disabled the API on the iPhone to discourage careless use. Obviously, the same restriction would not apply to Apple... which is unfair but understandable, given that "We know design better than you" is basically Apple's value proposition.
"More to the point, there's nothing to be gained from this example. UIPopoverController is a relatively boring UI element which it's not too complex to implement by hand, and there are a bunch of open replacements."
I was with you until here. I'd much rather just use the same 1st party component on a universal app, rather than a 2nd or 3rd party approximation.
So Windows 3.x on Intel 80386s was the first version that could run multiple DOS programs respectably. (Technically, Windows 386 could too, but 80386s were rare and expensive until about the time that Windows 3.0 came out.) Windows 3.0 was the first version that could actually do a reasonable job running all your old software.
Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here's the amazing part: On beta versions of Windows 95, SimCity wasn't working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn't free memory right away. That's the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95.
Amazingly, this sort of use-after-free causes compatibility problems for allocator writers even today. Imagine if you change the implementation of malloc() such that smaller allocations get their own mmap() region rather than being stuffed in with other allocations. Now any use-after-free bugs to allocations affected by the change will segfault instead of reading garbage, since the allocator would munmap the region upon free().
That's why programs like valgrind are great, they check all your memory allocations, and ensure these kinds of bugs don't occur (though it can only test codepaths that run, and has an overhead for all the checks).
This is also why I'm so excited about Rust. Suddenly your compiler and language definition ensure these kinds of bugs can't occur.
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 just by running shell commands like find and grep over the source tree.
> [...]
> Back to Content Providers. For example, there’s one inside the built-in Messaging (A.K.A. texting or SMS) app that it uses to display and search your history. Just because it’s there doesn’t mean you should use it. The Android team isn’t promising that it’ll be the same in the next release or even that it’ll be there in the next release.
> So, go ahead and look at the undocumented Content Providers; the code is full of good ideas to learn from. But don’t use them. And if you do, when bad things happen you’re pretty well on your own.
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.
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.
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.
Neither is good nor bad except one is supposedly singling out Apple to make it look bad? Besides, I was talking about holding ALL involved to the absolute standard, compared to a purely relative comparison.
Companies don't operate inside a vacuum. They are part of an ecosystem that they share with their competitors. If a competitor does X, the company in question must respond with Y. It's just how things work.
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
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.
However they acted differently for the wakelock api. In Android, there is a private api that allowed access to a list of wakelocks, which was used by many apps to provide the user with more information about what is keeping the system awake. However, their was a security implication (this was a real concern), so 4.4 made the api both private and inaccessible. (Private apis by default you can't use, but you can get around it by getting a reference using language-features). Unlike the sms situation though, they didn't provide a replacement api without the security issue. So now you need to root the phone in order to access the list of wakelocks.
While this may not affect most of the users of these apps, this is quite unfortunate, because these applications were especially handy on non-stock phones, which usually aren't easily rootable.
> 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.
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.
> What if the code was just in an unreleased static lib that was linked to each app.
Then it would be fair game. Your argument ignores an important difference: app-space code - which every developer can do; and OS code exposed as private API - which only Apple can do.
We agree that Apple can write and distribute code for its own apps, and share between them. What does it matter what the technical details are? Doing it the way that they do uses less memory -- that's better for users.
It's not feasible to extend the capability of creating and deploying OS frameworks to 3rd party developers.
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 before UIPopoverController.
Isn't the argument that Apple makes use of private APIs as a beta test? That is, Apple will first introduce these private API restrictions, build apps around them and release the API as public once they are confident on its reliability. My understanding this is the approach with XPC and TouchID.
Maybe Apple aren't confident with UIPopovers on iPhone and are awaiting its maturity until they let it loose. I highly doubt holding back a popover would be malice on Apple's part.
EDIT: Imagine if Apple released APIs as soon as they used them, we'd see more blog posts complaining about the reliability of an API they were promised.
Exactly. I rather suspect that there are some parts of UIPopoverController that have problems with the different screen sizes on say an iPhone 4S and an iPhone 5S. Apple trust themselves not to call the parts that don't work, but have not yet ironed out all of the bugs for third-party use.
Unless I've missed something about UIPopoverController, it's implemented using public APIs, so I'm curious as to what the author thinks Apple's motivation is for holding back this API - it's not like you can't create the same functionality yourself using existing APIs, it's just a bit more work. My guess would be that maybe they don't want to see people using popover controllers all over the place on the phone, so they made the bar higher for implementing such functionality.
The Apple apps that use these private APIs are publicly available. They're not beta versions. If the APIs are unstable then why are Apple releasing apps that use them?
With first-party apps being under Apple's control, it's possible to test them extensively, or make sure that they only use a working subset of the API, etc.
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 monopolies - it only ever makes sense to have one of each. The fact that it's not possible to implement a third-party Settings app isn't a problem because nobody should ever need to do this. This is arguable, but it's an easily defensible position for Apple and most iOS users would be happy with this (and those who aren't can jailbreak).
Having private APIs that are available to apps like iBooks, when competitors to iBooks exist, seems a bit shadier and much closer to the example of Microsoft Office using hidden/unpublished Windows APIs in the 90s. iBooks isn't some essential system service, and should be replaceable by a third-party app according to user preference. If Apple are making it even slightly more difficult for a third-party app to replace iBooks then this would appear to be anti-competitive.
IANAL, but I doubt that there is a legal case to answer. However, there does seem to be a moral case to answer. Sure, it's Apple's product and they can do what they like, but we have seen what happens when essential software vendors do what they like, and it's generally not pretty.
There would be a moral case to answer if this class exposed OS functionality that is otherwise unavailable. This is a convenience class that could easily have been copy-pasted between apps. I don't think that there is a moral case to answer.
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
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?
But it does require the user to be vigilant and not give every app all permissions (i.e. the root access aptitude et. co require). Do you really think that is reasonable to expect from every mobile phone user?
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.
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 apps on an iPhone they all start getting really slow. So iOS apps already do need to be updated.
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.
>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?).
Private API is not the same as API permissions. If there is a private API, it means only "selected" can give best experience to the users. IMHO It's not fair and work against Apple in long term.
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]
Too many people here are way too furious at anything apple/closed source to discuss anything.
1) you still own your phone. Don't be silly. Jailbreak and builds apps to your hearts content. Vendors can choose who and what they allow in their store. Physical or otherwise.
2) apple makes virtually all the profits on consumer hardware, but has Tiny market share. Really. It's no an abuse of a monopoly if 20 percent of people can't use a private API on their telephone.
3)equating access to private APIs in a private store with morality is a truly warped view of the world and a disservice to actual issues with morality society faces.
> you still own your phone. Don't be silly. Jailbreak and builds apps to your hearts content.
In the U.S., only as long as the Librarian of Congress keeps granting temporary exemptions to the DMCA, that otherwise probably makes jailbreaking your phone illegal. (And they have not exempted jailbreaking on tablets).
>equating access to private APIs in a private store with morality
Well, I think there is a lot more to it than this. I think people are just using this as one example. Personally I don't think it's a very good example, but you won't see a thread on HN about Apple purposely breaking X so Y is more difficult (for example the android imessage fiasco), or the fact that many 'innovations' by Apple, like thunderbolt or retina, are really just 'one-upping' the competition and attempting to lock the consumer in to something that's no more than a gimmick.
Sure thunderbolt is fast, but it's not something that any tech company couldn't design, it's just something to break compatibility between systems. Microsoft and many other tech companies are guilty of the same thing. Maybe google could make lighteningBolt on their chromebooks that goes just a little faster then thunderbolt, and then MS can make FTLBOLT on the surface that goes just a little faster than lighteningBolt, and then we can have no universal standards.
Next every company can come up with their own formats for their devices to make cross-compatibility impossible!
Like I said, Apple isn't the only company that's guilty of this, but they certainly seem to be the worst offender, especially when it comes to the consumer. If you're an investor it's great though, because they do everything they can to hook the consumer and make sure they can't go back.
Personally I'm not a fan of the Apple ecosystem. I had a lot of issues with sound going in and out on my MBP and bad multi-monitor support and I kind of felt mislead my the Apple community because I foolishly believed that OS X would have no issues out of the box.
I think the fanbase needs to be more open and accepting to criticism of the brand, because acting like Apple is some kind of flawless tech company does more harm than good.
> many 'innovations' by Apple, like thunderbolt or retina, are really just 'one-upping' the competition and attempting to lock the consumer in to something that's no more than a gimmick. Sure thunderbolt is fast, but it's not something that any tech company couldn't design
Definitely. For example, Thunderbolt was designed by Intel. Apple had an exclusive license for a while, but it's available on Windows laptops[1] now, albeit sometimes with their own proprietary connector[2].
I think it's a little silly to make a vast conspiracy about this.
When you put yourself in the shoes of the people on the product teams building the apps and maintaining the APIs, it's easy to see this for what it's much more likely to be: a hack that was implemented so that someone could leave the office at a reasonable hour.
Those of us old enough to remember the early days of the Macintosh know that this is nothing new. Apple programs used undocumented calls to QuickDraw and did all kinds of yucky stuff with the upper 8 bits of the address (in the early days, the Mac processor used 24-bit addresses but the registers were 32-bit), which lead to the "32-bit clean" problems that plagued the first Macs to use 32-bit addressing.
Apple also did this in the Apple II days, calling undocumented ROM monitor routines from their own programs and operating systems. In fact, several companies made a list of those entry points and considered them "semi-official", the reasoning being that Apple wouldn't change entry points used by their own programs.
I would not consider the default applications on the iphone "apps" even. They are written by Apple to provide a certain functionality and that is what they do. They can use any API they need. Why should they not use private API? I would not consider iBooks to be somehow different from say the phone or system preferences "app". They are there because they are provided by the system.
Bundling IE was never the problem. Using private APIs to give IE a noticeable advantage over other, more popular browsers in an effort to gain marketshare for IE was the problem. Having a monopoly isn't illegal, and is part of capitalism. Using a monopoly in one market (say, operating systems) gain share in another (like, browsers) is.
To me the issue with IE and Windows was that MS went from a position where IE basically didn't exist (but other browsers did and worked fine on it's OS) to "it couldn't possibly not be tightly integrated into Windows" in no time at all.
Funny how Microsoft owned 90%+ of installs globally. Just because everyone copies apple doesn't mean everyone uses apple and needs to bend to their will. It's the opposite actually.
That should only go as far as the app store and the settings app. The rest of the applications on the system have no reason to be special for they don't need special system administration tasks to function.
Android even functions where nothing is a 'special' app. (Although no phone is actually released that way, but it can be achieved with custom ROMs).
This won't pass Apple's automatic check for private API, but you could do some clever swizzle. IMO it's ok to use this in production (if you can get pass the app review), Apple is using them in their app anyway.
>> "This won't pass Apple's automatic check for private API, but you could do some clever swizzle. IMO it's ok to use this in production (if you can get pass the app review), Apple is using them in their app anyway"
Private API's shouldn't be used in production. When Apple changes them they can update their apps to support the changes. They won't document these changes, you won't know about them, and your app is now broken for your users. You have to work out how to fix it, then submit it for review, and if they catch your private API use this time around you've screwed your users.
Of course Apple 'cheats' with regard to its own closed product, it's hardly surprising. Interesting to read about the exact mechanisms by which they do, but I'm always reminded of Jeff Atwood's article 'Serving at the pleasure of the king'[0]. It's Apple's party and they can define the rules however they like. Enough people seem to be okay with this that it's a viable method of doing business, even if it isn't desirable.
Might be time for the Apple PR machine to crank up some more stories about developers making millions writing apps. As every casino in Vegas knows, watching some guy hit it big is a great way to take your mind off how many resources you're losing.
I wonder, though, if there's going to be an end-game to this walled-garden nonsense. On one hand, people (tech-minded people) seem to be slowly getting it.
On the other hand, industry has somehow set up this insane legal system where the product you buy? You don't actually own it. So I go to the store and buy an iPhone. I give them money and I leave. This process is the same as if I bought a regular, land-line phone. Only with the iPhone, I don't own the box, the software, the O/S, or control what the phone does. Carrier wants me to have new software? It pushes it out and I have it. Apple wants to get rid of a favorite app I use? Poof, it's gone. They seem to be doing this without any major push-back from the user community.
I am prone to think both the "educated tech user" community and the "Joe Sixpack" community are going to meet up at some point, but I'm not sure. Maybe the strategy with this and all the other dystopian bullshit we're seeing is to try to run out the clock; keep things the way they are long enough so that the argument can then be made "but it was always like this!"
It's weird. I keep reading these articles about how various services suck, but it only seems like tech people know/care about it. That can't go on. Something's gotta give somewhere.
The fact that Apple, with a half-dozen products, is holding some 50% of the smartphone market against thousands of spec-equal competing products from hundreds of manufacturers shows there is something important lacking in your argument.
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.
Apps are Turing-complete, right? In theory, that means it's possible to make an arbitarily complex and obfuscated route to a private API, making it impossible to detect via simple static analysis.
It is strange that Apple allows this API on iPad but not iPhone. What if you want to write an iPad/iPhone universal app? Although there are many 3rd party replacement, I prefer a native API anyway.
As for this popover API, I don't think it's a trick of anti-competive, It matters not so much. But there are no official explanation at all, the same as many other questions about Apple. It will be better if Apple becomes more open-----not nessesary open source, but be open to these questions to avoid guesses.
I'm not trying to suggest any kind of equivalency here, but what's the difference between hidden api functionality for Apple and Microsoft's undocumented function calls?
Microsoft's undocumented function calls gave a massive increase in performance, making competing applications in multiple domains essentially uncompetitive on the platform.
Apple is hiding a minor piece of functionality that can be implemented in another way and, indeed, has.
I find many of Apple's iOS business practices abhorrent, but trying to even suggest they are in the same league as 80's and 90's MS is an insult to all the companies MS destroyed in those decades.
The practical difference is that if you write an application which gets wide scale adoption which uses Microsoft's undocumented APIs, then Microsoft might choose to support those as-is in future versions of the OS, whereas with Apple you'll just not be able to release your application.
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.
That's a pretty boring way of preventing someone from using the API. You could easily swizzle the _popoversDisabled method and get away with it.
I remember trying to use a private API on Mac OS X and having my app receive a SIGKILL prompty after calling the function. It took me a while to find the fix: my app had to be signed. Mind you, it could be codesigned by a self-signed certificate and the system would be fine with it... these were fun times :)
The way the check is implemented looks bad, but this doesn't tell us anything we didn't already know.
If you're surprised that Apple can use non-public APIs in its apps, you'll be shocked to learn that Apple actually controls the whole ecosystem and can block apps that compete with its own apps regardless of what APIs they use.
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.
It perfectly makes sense for me for this API. It is an element which could result in bad user experience if used on the small phone screen. So their choice was: "We either a, restrict it for iPad only or b, rejects apps using it badly on the ground of bad user experience"
I don't think this is something new, actually there are plenty of places in UIKit code checking for bundle identifier prefix for "com.apple". Also it may be possible for them to plan this APIs public but not yet matured enough/finished to release.
It's understandable that Apple locks down private API's, however given that developed these often they move from the private state (beta testing for their own apps?) to public and available for developers to develop against once they are happy with them.
Are these Dev Apple new comers? Apple has a history of dogfooding its own API internally until it think it is good enough before releasing it to the public.
One of the things why Firefox OS looks appealing to me: Mozilla is being so open about every part of its architecture that situation such as this one is hard to imagine.
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.
How that "use at your own risk" is working out for Android is one notable reason why iOS is successful: everyone isn't fine with it - customers don't like getting the fallout of risks developers choose to make with APIs the OS provider won't stand behind. The walled garden approach succeeds for a reason.
This seems to be the same anti-competitive behavior that Microsoft was often found guilty of and chastised for. Come on Apple, please don't become an Evil Empire.
I am surprised that this is so shocking to the author. Stuff like this is expected and only logical, as wrong as it may be. Apple has been desperately trying to tie people into their eco-system and every move the company makes is a step in that direction whether it may be immediately obvious to other people or not. Also I should mention that I believe Apple is probably not the only company that promotes the use of its own apps on its own platforms. Regardless, it is nice to see some concrete indicators like this article to actually show how that is being done.
>> Stuff like this is expected and only logical, as wrong as it may be
Maybe it's just me, but I really don't see what's "wrong" about Apple using private API's and workarounds that are not available to 3-rd party apps. I also don't see how this is different from about every other piece of commercial software in existence, the Windows API is well known to be full of undocumented API's that are only used by Microsoft, for example.
The only way I could interpret a commercial vendor using private API's unvailable to third party applications as 'wrong' is if they secretly use them to gain a competitive advantage over third-party vendors of competing applications. This is clearly not the case on iOS, because the whole system is already locked down, and publishing applications directly competing with Apple stock apps is explicitly disallowed in the submission guidelines. Whether you agree about that is a different thing, but there's nothing secret about it.
As far as I can tell, there also is no pattern whatsoever of Apple applications somehow using magic killer unicorn features that are unvailable to third-party apps. Did anyone ever get the impression that third-party apps on iOS are second rate compared to stock apps? I surely haven't, I'd even go as far as saying it's the opposite. Also the list of app bundle exceptions that can use UIPopoverController is so small, I expect there's a much simpler explanation here. Most likely UIPopoverController does not work reliably on iOS, except in some restricted use cases, and Apple chose to disable it for third-party apps to prevent applications with broken user interfaces or having to support UIPopOverController use cases they didn't intend to be used on smalls screens.
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.
UIPopoverController is a trivial UI element which allows an app to display a kind of tooltip-style contextual view above the app. It would be hard to argue that the exclusion of this API would constitute "crippling" anything, given the number of alternatives which are available.
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 operating systems?
- Should there be an open standard so people can build compatible iPhone clones?
No. iPhone is Apple's product, and they decide how far they will go in opening up their platform.
Third party developers are not fully trusted to do the right thing, and as you can see with Android's malware situation, it's a good thing Apple is not letting random developers do whatever they want.
Since Apple is held responsible by both developers and users to have a reliable product, when they decide to make an API public this is a huge commitment.
Apple has to guarantee said API will be supported in a reasonable way in future OS releases, it has to guarantee to users that calling said API won't result in poor UX or security vulnerabilities.
The situation is much different for Apple's own apps, as Apple can then make the personal guarantee it won't be abusing its own APIs to create poor UX and implement malware.
I like how your rant about "trying to tie people into their ecosystem" has absolutely nothing with the situation here, which is the fact Apple's apps use some harmless private APIs before they finalize them to a degree to make them public.
Tell me, what other "expected and only logical" things did you encounter while reading the article? I'm sure there's an alien invasion conspiracy theory in there somewhere.
Bleh. Come on, this is just apologist. So much spin here about how "it might not be production ready, so of course they're just 'testing' it internally before making it widely available".
Except...
As noted elsewhere, "it's a trivial component, almost akin to a tooltip".
And iBooks, one of the apps, was introduced in January 2010, and requires iOS 4.3 or later.
People who, with a straight face, claim that Apple has needed nearly four-and-a-half years (more, really, since there was pre-release testing), and since iOS 4.3 to make sure a "trivial component" was ready for the public are really grasping at straws.
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.
I know how you feel. It just goes to show you that the masses think a like. :). Here is a +1 for you buddy, for what its worth, I thought the link was good.
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.)