How Apple Cheats
marksands.github.io
marksands.github.io
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.)
http://www.pcpro.co.uk/news/101947/microsoft-used-undocument...
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
A much narrower range of anti-competitive practices are illegal when you are not a monopoly.
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.
the tech industry likes to change definitions to fit their viewpoints.
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.
Does Honda have a "local monopoly" on sedans because Civic drivers don't usually switch to a Kia Forte overnight?
So to get back to Apple: They don't have a monopoly on smartphones, they have a monopoly on iOS app stores.
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.
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.
Seems to me Microsoft is still dominant.
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.
What more do you really need to know ? If this isn't abuse of monopoly power, then what is ?
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.
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.
[1] https://www.cocoacontrols.com/controls/wypopovercontroller
[2] https://itunes.apple.com/us/app/cookapp/id771313730?mt=8&uo=...
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.
Which is totally unrelated to the discussion about the private API, and if you can replicate a widget provided in one. Which you can.
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.
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.
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.
There is also the fact that Sun didn't prohibit other operating system or application vendors from making operating systems or applications for its hardware by locking the boot loader.
No, 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.
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.
I thought it was because it tried to use its dominance in the desktop OS market to get dominance in the we browser market. http://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp...:
"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"
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.
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.
You're the one trying to have your cake and eat it too. You want a walled garden, which is a monopoly, and then want to claim it isn't one.
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.
> 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.
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.
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.
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.
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.
It's called Windows "DirectUser" UI and it's in violation of the antitrust settlement.
sources:
* http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/52952...
* http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US...
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"]
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.
This is for a popover like this http://i.imgur.com/ItDZQRL.png
Not a popup like this (known as an alert in iOS) http://i.imgur.com/3U2Tq2e.png
Nothing here is private.
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.
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.
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.
Here is the quote, it might help:
Say what?! Did Apple seriously grant access to four of their native apps by hardcoding their bundle identifiers? Yep, they sure did².
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.
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.
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?
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.
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…
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.
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.
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.
This is from Joel Spolsky's Strategy Letter II: Chicken and Egg Problems http://www.joelonsoftware.com/articles/fog0000000054.html
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.
This is also why I'm so excited about Rust. Suddenly your compiler and language definition ensure these kinds of bugs can't occur.
> 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.
http://android-developers.blogspot.de/2010/05/be-careful-wit... http://www.tbray.org/ongoing/When/201x/2010/05/06/Private-AP...
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.
http://blogs.msdn.com/b/oldnewthing/archive/2003/12/24/45779...
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.
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.
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.
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.
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.
It's not feasible to extend the capability of creating and deploying OS frameworks to 3rd party developers.
If that was their game here, I can think of many other parts of the iOS frameworks that would be kept private before UIPopoverController.
Yes, that hits the nail on the head. Great point.
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.
If they mess up the API calls, they can sidetrack the review process and deliver a swift update.
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.
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.
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.
> 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.
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?).
As you point out, there are cases of that happening on iOS. It would be better if we were talking about those instead.
They have two APIs that are available behind a flag or in a dev branch. Panels[1], the always-on-top type windows Hangouts uses, and the notification area icon[2].
Google hardcodes Hangout's extension id in Chromium to allow it to use these features before they're available to the public.[3]
[0]https://chrome.google.com/webstore/detail/hangouts/nckgahada...
[1] http://www.chromium.org/developers/design-documents/extensio...
[2] https://code.google.com/p/chromium/issues/detail?id=142450
[3] https://code.google.com/p/chromium/codesearch#chromium/src/c...
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.
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).
http://arstechnica.com/tech-policy/2012/10/jailbreaking-now-...
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.
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].
> Personally I'm not a fan of the Apple ecosystem
It shows.
[1]http://en.wikipedia.org/wiki/List_of_Thunderbolt-compatible_...
[2]http://www.pcworld.idg.com.au/article/391755/sony_adopts_int...
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.
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.
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.
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.
[0]: http://blog.codinghorror.com/serving-at-the-pleasure-of-the-...
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.
Peter Steinberger (https://twitter.com/steipete) shipped this in his PSPDFKit, which is used for Box/Dropbox/Evernote.
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.
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.
What I don't like about this is how they chose to implement the restriction. Messy, hacky and inelegant.
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 :)
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.
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.
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.
Do you even read what you write or you just mash the keyboard and hit "reply"?
If it were so it then it wouldn't be about being shocking, expected or logical, but about being against the law.
- 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.
Where do you live ? Inform yourself (https://www.comscore.com/Insights/Press_Releases/2014/3/comS...). Apple has 41.6% when the second one, Samsung has 26.7%
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.
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.
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.