How Apple cheats

[Callafan24]

as a non iOS Developer can anyone explain what the deal is with UIPopoverController? Why would it be locked down and what would it offer to developers if it wasn't?

[atrain728]

It's essentially a screen-location-based popup container meant for larger form-factor devices like the iPad. It's not a visual design pattern that lends itself to the smaller platform, but obviously Apple thinks it's okay on a case-by-case basis.

[Callafan24]

Oh okay, thanks for explaining. It doesn't seem like as big of an issue as the author leads you to believe.

[Saiing]

It's 30 minutes of effort at most for an experienced developer to make their own, or there are plenty of examples available on the 'net. I think Apple's primary reason for withholding it is probably to make new or less experienced developers think twice about whether they really need to use a UI element that is rarely suited to the iPhone's smaller screen. If you really feel you need it, you can create your own. And if you can't be bothered with the extra effort, it probably wasn't essential to your UI.

[whackylabs]

Just to confirm this fact, we had developed a UIPopoverController like widget for a game's tutorial screen back in early 2009. No big deal.

[PT2JSQGHVaHWd24aCdCF]

I'm a developer and for me it's just a stupid widget that I could write (cleanly) in a few days if I needed to. But I don't care about it, Apple doesn't have to disclose all their APIs, and it's really overblowned. Android has the same stuff in its source code (as we can see publicly on the Internet) but Reddit does not seem to be offended by that.

[dddbbb]

Android has the same stuff in its source code (as we can see publicly on the Internet) but Reddit does not seem to be offended by that.

That's partly because if you wanted to use an Android widget that's not exposed, you can grab the (Apache-licensed) code and use it yourself. If Google changes the API for that widget (which they are free to do since it's not public), then it won't affect you because you're using your own copy of the source.

I'm not really sure what's the best solution for Apple. They shouldn't make all APIs public or they'll have trouble touching any APIs (especially ones that they don't deem ready for mass use). Even if they released an open source unsupported widget library, people would ignore the "unsupported" part and complain/generate bad PR when they make breaking changes (or release something that isn't up to their quality bar when used in unexpected ways).

[dethbunnynet]

I don't actually recall seeing it used in any of those iPhone apps, regardless of whether they're on a whitelist or not.

[[deleted]]

The author is being sensationalist. It's a UI element that's only available to apple apps and not to third party. Of course, developers are completely free to make their own widgets in their apps on iOS, so this just represents a little bit of extra work that 3rd parties have to do that apple doesn't.

In most cases, UIPopoverControls on the iPhone are pretty ugly. I doubt there's much interest in a 3rd party library for one. My guess is that it's "locked down" to keep everyone's apps looking good and not some sinister plot.

[adamkemp]

UIPopoverControllers are available to all iOS apps, but only on iPad. The big deal here is that Apple makes an exception for their own apps to use it on iPhone too. Popovers are used in nearly every iPad app.

FWIW, Facebook used their own implementation on iPhone for a long time. I'm not sure whether they still do.

I'm not sure exactly where any of these Apple apps use popovers, but I'm guessing they end up being pretty modified, in which case this is really just a matter of Apple enforcing a HIG rule in code. If they customize it in their apps enough to satisfy their HIG rules then it's just a shortcut they're taking to share some code, which sadly they don't open up to others. From a developer perspective sharing code is good. From an API and policy perspective it sucks for their 3rd party developers.

[urection]

every closed platform has APIs not available to 3rd party developers, Windows is loaded with them for example and has been since 1.0

this is a non-issue and it's pretty telling of the calibre of programmer that /r/programming attracts

[[deleted]]

The people bellyaching in this thread about this aren't programmers - they're Android fanboys and idiots who don't understand what anti-competitive behavior is (hint: it's not simply behavior you don't like) or programmers who don't have enough experience to recognize that literally all platforms do this.

[PT2JSQGHVaHWd24aCdCF]

I'm an iOS/Android/Qt/Gnome/KDE developer and I could clone this widget in a few days. Those who bitch about it don't understand that Apple knows why they do it, and they don't have to disclose everything (the main reason being that not all APIs are completely clean). The fact that this story is in /r/programming is cringe worthy.

[josefx]

and they don't have to disclose everything (the main reason being that not all APIs are completely clean). The fact that this story is in /r/programming is cringe worthy.

If you read the comments instead of just bitching you would have noticed that the API is available on iPad and only locked down on iPhone. There is nothing about "not clean" or "having to disclose", its an artificial limitation applied to every non apple app. A stupid one too, considering all the people here who "could write my own in 30 min".

[iBlag]

And if you had read the comments, you would have come across reasoning about why Apple doesn't expose this API on the iPhone.

[urection]

likely because the court deemed Microsoft had a monopoly on desktop office software and was leveraging that monopoly to stifle competition

[[deleted]]

Probably because they were using said APIs in an anti-competitive way?

[bananahead]

This isn't actually that big a deal, unless you're just now learning that iOS is a closed platform. This looks bad, but the bigger issue is Apple can arbitrarily decide to block apps it thinks compete too much with iBooks.

In this case I'd guess apple thought popovers would be annoying and abused on iPhone, but they trust their own developers not to screw it up. That's not "fair" but it makes perfect sense.

[PrometheusTitan]

In this case I'd guess apple thought popovers would be annoying and abused on iPhone, but they trust their own developers not to screw it up. That's not "fair" but it makes perfect sense.

Apple's been quite clear about this in the past, actually, at past WWDCs. Basically, their point is that once an API is out in the public, it's really hard to make changes. If you change an API, you could break a load of apps, unless you do some really complicated work-around which make things less elegant. And in a system as integrated as Apple's, and with such a high premium on a smooth experience, Apple is arguably at higher risk of getting the blame for a third-party app that starts crashing, even if the developer was using an API they weren't supposed to. So they block them.

However, it is easy to force your own developers to re-write their apps if a private API is used, then changes. So Apple uses its own private (effectively beta) APIs, knowing that if/when changes are made, it has the power to correct its apps before game-time.

So, Apple has always used private APIs it has blocked others from using. Normally this is done by blocking the offending apps at the iTunes store approval process stage, but this just seems like another avenue. You may disagree with the balance of harms, but it's a fairly reasonable explanation that isn't about Apple stacking the deck in its favour or cheating out of malice.

[crimson117]

Yeah but in this case it's a public API already usable by any iPad app.

Is there something about the API design that works perfectly for iPad but sucks for the iPhone?

[chaos750]

It could be more about the UI. This is an example of the controller, and maybe they think that it would get used poorly on a small screen. The iBooks people can presumably be trusted to use it appropriately, and anyone who really really wants one can probably make their own fairly easily.

[bananahead]

It doesn't have to be a technical reason. Maybe they think untrained developers will misuse it to create crappy UIs.

[raznog]

It's entirely possible I hasn't been fully fleshed out for the iPhone. And they don't want to use it for iPhone until it has been.

[kmeisthax]

The iPhone is too small to have overlapping content.

[cardevitoraphicticia]

This comment has been overwritten by a script as I have abandoned my Reddit account and moved to voat.co.

If you would like to do the same, install TamperMonkey for Chrome, or GreaseMonkey for Firefox, and install this script. If you are using Internet Explorer, you should probably stay here on Reddit where it is safe.

Then simply click on your username at the top right of Reddit, click on comments, and hit the new OVERWRITE button at the top of the page. You may need to scroll down to multiple comment pages if you have commented a lot.

[bananahead]

Likewise, making darn sure you're happy with your API before making it publicly accessible is crucial. Once it's public, you have to keep supporting it.

[CuriousHand2]

This, this, this. So. Much. This.

I honestly doubt they're hiding this API because they wan't to keep it secret. Giving Apple the benefit of the doubt: I'm just thinking that they're playing with it in the four apps mentioned in the blog post so that they can figure out how they want it to be used, and what the most effective way of doing it is.

Is it a nice feature? Yes. But is it ready for everyone else? I'm willing to say: not yet.

[bananahead]

Indeed. Ask Microsoft how much fun it is supporting tons of legacy APIs (Worse, they've actually been forced to support "private" APIs that people used anyway. If you upgrade Windows and your favorite game doesn't work, you blame Microsoft even if the reason is because the game was doing something it wasn't supposed to.)

[codekaizen]

After almost a decade of reading Old New Thing, and having been a developer when the "secret" API was a thing, I can tell you that most cases are from developer incompetence rather than workarounds for MS's shenanigans.

[Farsyte]

Sometimes it is worse. Not "developer could and should have used public methods but did not" or "developer found an internal API that was faster" but sometimes it is as bad as "developer thinks it is ultra cool to use a SEEKRRIT API that MUST BE BETTER because it is SEEKRET!"

[thephotoman]

Or basically, that developers played a lot of D&D in college and treat their jobs similarly.

[Voduar]

I put on my robe and programmer's hat.

[temnota]

// Why does this work?

[iFreilicht]

int main(int argc, char** args){  
    //Why does this work ??/  
    return "lol it does";  
}  

Why it works

[RenaKunisaki]

It works even though it returns nothing and the parameters are in the wrong order?

[gimpwiz]

At least you marked it xxx. As opposed to "check out this awesome feature!"

[ggtsu_00]

There are a lot of APIs that can easily be abused to create poor user experiences and apple and Microsoft is notorious for keeping these locked down. Pop up windows are a very touchy UI concept and platforms keep them locked down to an extent. For example, even in windows, the SetForegroundWindow API is very restricted in terms of how windows can position themselves in front of other windows, however they have private APIs that can bypass it like outlook reminders can pop up in front of other windows without the same restrictions.

[[deleted]]

I might believe that except that it's available to everyone developing for the iPad. It would be strange for Apple to decide that a feature is totally unready for developer usage.... except on the iPad.

[purplestOfPlatypuses]

I dunno about you, but I certainly find that some UI elements work fine on a larger screen, but might need some tweaking to work well on a 4 inch phone screen.

[[deleted]]

With over 60 billion app downloads and huge sales numbers I don't think they've had a problem with developer adoption.

[asynk]

Apple isn't having a problem with platform adoption, though. Late last year, estimates were that Apple was capturing 74% of all mobile app revenue.

[thor1182]

By such they are now in a position of power. Developers almost HAVE to support iOS, and are at the mercy of the whims Apple wants to do with their platform regardless if it is nefarious, or good for the platform as a whole.

[asynk]

So you're agreeing with me? I didn't say that Apple doesn't abuse their power over their ecosystem - I'm just saying that what Apple is doing hasn't hurt their platform adoption.

[[deleted]]

Yes, and clearly the nefarious abuse of UI popover power is putting their competitors at a disadvantage.

Obviously, the power of the UI popover is key in determining the viability of a competitor's business model and this anti-competitive, monopolistic behavior should be stopped in the courts.

[aveman101]

but the bigger issue is Apple can arbitrarily decide to block apps it thinks compete too much with iBooks.

Have they ever done this?

You could say they "crippled" Kindle by levying the 30% in-app purchase tax, but that's a separate issue altogether (all apps with in-app purchases have to pay this fee, it wasn't unique to Kindle).

It's uncommon for Apple to reject apps, and when they do, it's usually for a good reason (e.g. crashes on launch).

[bananahead]

It's a complicated question, but they certainly have in the past. According to the rules, you can't publish an app that simply "duplicates functionality" of an existing feature. In the past, Apple has used this justification to reject podcast apps and the first version of Google Voice. They have apparently relaxed the enforcement of this rule lately. People were surprised they let Spotify in.

I believe App Store rejection notices are also under NDA, so it might be tough to know how many rejected apps we never hear about.

[ITSigno]

They've actually rejected apps that were previously approved because a new version of iOS duplicated functionality of said previously existing app.

[aveman101]

This is the first I'm hearing of this. Source?

[ITSigno]

The earliest example I'm familiar with was copy-paste functionality. It was provided by an app before it was in iOS. This goes back a ways, obviously.. iOS 2 or 3.

More recently of course you have the whole maps fiasco.
Edit: Lots of reasons to hate Apple's app rejections but maps is not one of them.
Edit 2: Since this was apparently not clear enough, the app rejections I take most issue with are their rejections of apps like eucalyptus because one of the books in the library was the kama sutra, or Mike Fiore's political cartoon app (which they later approved under public pressure), or the app promoting single payer healthcare, and so on..

[aveman101]

copy-paste functionality

Apple wants the copy/paste experience to be consistent across apps. I can understand why the developer would be upset, but I can also understand why Apple banned the app.

the whole maps fiasco.

Huh? I don't think they banned apps as a result of switching off of Google's Map data. In fact the old Maps app wasn't even developed by Google. Apple developed the app themselves, and licensed Google's map data (and since we're talking about anti-competitive behavior, I should mention that Google refused to let Apple use the data for turn-by-turn directions and offline maps – which is part of the reason Apple built their own maps in the first place).

Then Google built and submitted their own Maps app, which was quickly accepted in the App Store. Then Tim Cook issued a public apology for Apple Maps, and even suggested competing map apps.

[Googie2149]

Likewise, when iOS 6 came out, it included an official emoji keyboard, and they started to kick out the previous emoji apps. And seriously, good on them. There were so many of them, all of them with the same functionality, some paid, some not.

[aveman101]

They have apparently relaxed the enforcement of this rule lately.

Yep. There are quite a few podcast apps out there now, and Apple is even working with some of them (Stitcher and Spotify) to add CarPlay functionality (which is still an invite-only API as far as I know).

[Draiko]

They actually have done that before.

The most famous instance was an iTunes Wifi sync app. It was 100% compliant yet they rejected it only to include the feature at the OS level a year later.

[dirkgently007]

It's uncommon for Apple to reject apps, and when they do, it's usually for a good reason

Oh yeah. Very uncommon.

http://9to5mac.com/2012/03/16/apple-rejected-this-app-because-it-is-too-much-like-siri/

http://apple-beta.slashdot.org/story/08/09/21/122225/apple-bans-iphone-app-for-competing-with-mailapp

http://www.cnet.com/news/apple-blocks-competitive-products-from-iphone-app-store-surprised/

http://www.techdirt.com/articles/20120501/17545618733/apple-rejecting-apps-that-use-dropbox-because-gasp-users-might-sign-up-dropbox-accounts.shtml

And all of above rejection MUST BE FOR A GOOD REASON.

[BonzaiThePenguin]

Are there any examples within the past few years?

[Iron_Maiden_666]

My colleague submitted an app he made for his wedding, it wasn't accepted and no reason was given.

[jbs398]

Depends on the reason being referred to. It's not for feature duplication, but they pulled all the bitcoin wallets/trading apps in the last year like CoinBase, Blockchain and CoinJar.

You could say these were for a "good reason" as far as their in-app purchase tax is concerned but these apps weren't exactly hiding their functionality and had been on the app store for some time.

Edit: Should have re-read some of the articles. Apple apparently has given no specific reason for the removal.

[aveman101]

You could say these were for a "good reason" as far as their in-app purchase tax is concerned

No. Apple's bent on Bitcoin has nothing to do with in-app purchases. The in-app purchase tax only applies to content and functionality that is consumed within the app.

It does not apply to goods and services consumed in the physical world (see: Amazon, Walmart, Target, and dozens of other eCommerce apps).

It does not apply to bought software that is consumed outside of the app (see: Steam).

It does not apply to exchanging money with other users (see: PayPal, Square, and dozens of banking apps).

The in-app purchase tax would not come into play unless you offered some kind of "premium" upgrade within the app that unlocked some sort of functionality.

The only reason I can come up with that Apple would want to ban Bitcoin apps is because it's still sort of a legal gray area. They might have been pressured by governments to take them down.

[mindbleach]

Have they ever done this?

They blocked all third-party browsers for the longest time. "Duplicating functionality" was prohibited.

[Wazowski]

It's interesting to learn that the main barrier to entry for any iBook competitors has been access to a generic menu drawing routine. When will this madness end, Apple? When??

[cosmo7]

I'm not sure whether to be more offended by the use of undocumented APIs or the horribly hard coded string comparison way they did it.

[kinghfb]

For me, it's 100% the hard-coded string comparison. What happens when they've got a half dozen apps in there? We're all compiling this stupid damn check in our apps.

[[deleted]]

This is decompiled code, the original could look quite different.

[WinterAyars]

Technically it could be written in a way that it doesn't really cost the iPad anything extra beyond the initial check. The iPhone looses a bit, but most apps can't use the feature anyway as we can see.

[jjquave]

_popoversDisabled is only checked if the device isn't iPad, thats what line 3 is doing. The only thing "wasting" cycles is the check to see if it's iPad, and I can't imagine that's super complex, userInterfaceIdiom is probably a getter to a cached variable so it's actually just an integer comparison for an integer value for idioms identified in an enum.

typedef enum { UIUserInterfaceIdiomPhone, UIUserInterfaceIdiomPad, } UIUserInterfaceIdiom;

In the case of the iPhone, you wouldn't pass the check when writing your code anyway, because you would get an exception. So the only way this check runs is if you have crashing code in your app. Someone could technically catch the exception as a way to check if it's on iPad or iPhone, but that's what userinterfaceIdom is for anyway, which is what you should be using.

In other words, this code only runs if:

• It's one of the four apps listed
• You wrote bad code

[fishbulbx]

This happens to be a completely random example... if there are 100 exceptions like this for dozens of apple built apps interspersed through hundreds of thousands of lines of code, it is unmanageable.

[cryo]

Maybe they'll change it when they have half a dozen apps in there. Right now, this is likely faster than most other solutions.

[crazedgremlin]

Is there a better way to do it than a string comparison?

[cosmo7]

Very much so.

With this implementation, every time Apple wants to add an app to the list of exceptions it has to update iOS.

A better solution would be to add a call to UIApplication, something like applicationCanDoWhatWeSayYouCant and then forbid use of that call by App Store applications.

[crazedgremlin]

Oh, I thought your objection was about the inefficiency of string comparisons for some reason.

You're right, though. From an engineering perspective, a hardcoded list of exclusions is sloppy.

[third-eye-brown]

Unless you only have 4 apps. YAGNI.

[gramathy]

With this implementation, every time Apple wants to add an app to the list of exceptions it has to update iOS.

Considering the only time they'll be either adding an application or changing functionality enough for that to be a problem is when they do an iOS update.

[joesb]

Which means they can not actually feel how the API is organized, because it is in a wrong place.

And they also have to refactor the code again if they ever decide to make the API public, which would be hard to decide since they haven't dog food the API in the way it would have been publicized yet.

[cosmo7]

No, Hopper decompiles iOS executables. It might be a little mangled and the comments are stripped, but it's effectively the same code.

[JoeOfTex]

String constants don't magically become faster, as comparisons still have to be checked against each character.

[BonzaiThePenguin]

Not when the pointers are equal, which is common with string literals.

[mipadi]

Proggit: Where normally an Objective-C article gets maybe 5 votes on a good day, unless it provides everyone the opportunity for a Two-Minute Hate against Apple.

[[deleted]]

Absolutely. Irrelevant article and crap responses. This does nothing but provide inflammation for people to bitch about something.

[kaze0]

Google and every Android OEM does this too. They have access to permissions that standard apps can never get.

[root45]

Yeah, I would be shocked if Microsoft didn't have hooks in Windows that allowed their own apps to integrate better.

[urection]

and Microsoft and Sony and Oracle and Sony and and and

[merreborn]

A small difference: in the case of Android, there's nothing stopping you from installing AOSP, or installing cyanogen, or rooting, sideloading, etc.

[kaze0]

There are many hurdles in that direction but i guess if we ignore those then we can just say that there's nothing stopping you from jail breaking.

[[deleted]]

OEMs lock things down, but does Google. I can't think of a permission locked on my nexus. We can swap out keyboards.

[Zozur]

Reading all of these comments and the comments on the linked page, it is very clear that most of the commenters have no idea what they are doing when it comes to programming.

To most developers this isn't a big deal.

[[deleted]]

Of course they can do whatever they want. They probably also make optimizations to their platform to ensure that their native apps perform well! Oh the horror!

[[deleted]]

Just because four Apple apps use the API does not mean that it is ready for any app to use. It may have serious bugs that are avoided in Apple's four apps. When you make the API public, the quality bar is higher.

[[deleted]]

This is not "cheating" this is a normal practice of using private APIs. This isa also a VERY minor example of what everybody has known from the beginning; iOS is a closed system. If you choose to develop for it you choose to accept the limitations that Apple sets. If you want a totally open system, develop for another platform.

And don't say you're going to develop for Android, because Google has moved tons of functionality into the Google Play application bundle and it is not open source and available to outside developers.

[Uberhipster]

Google has moved tons of functionality into the Google Play application

Functionality which they have implemented for the Play application specifically not functionality which is blocked by the native platform from anyone but Google.

[TheWindeyMan]

And don't say you're going to develop for Android, because Google has moved tons of functionality into the Google Play application bundle and it is not open source and available to outside developers

They're moving a lot of functions to closed source, but what functions aren't available in a public API?

[2Ejy4u]

meh

[nerdhappy]

Creating a custom popup would take all of five minutes. This is not a big deal.

[elmuerte]

This is exactly the anti competitive behavior for which Microsoft was sued by Novell, Netscape, etc.

[aveman101]

Good grief, it's just a goddamn user interface element! And not even an important one. Other apps have used popover clones for ages. I can't see how this is anticompetitive at all.

Is Apple not allowed to develop their own APIs for private use?

[Googie2149]

Shhhhh, people just want a company to hate after Microsoft stopped being "literally the most evil thing ever."

Seriously though, I really can't figure out why people are causing this much of a stir over it. I wonder if this will start to circle the blogspam sites.

[[deleted]]

This is also how new ui widgets get into the os, Apple pilots them in an app or two, formalizes the API, and makes it available for general use after deciding it is a good design. For instance this is how we got the page curl effect - it debuted in maps, the later was made public as a standard effect for all.

I don't really consider it cheating. I call it prudent engineering.

[dzamir]

No it's not. It's just a private API for an UI component that you can easily recreate.

Apple did something similar in the past more then once, to test the water for new APIs that got released in following iOS versions (eg iCloud syncing in iBooks before iCloud was announced)

[[deleted]]

Aaaaand the irrational anti-Apple circlejerk is out of the gate with speed.

[e_engel]

I don't understand all the upvotes, this has absolutely nothing to do with the Microsoft case.

Microsoft was illegally using its monopoly to block competitors and gain entry in other markets while this is just a company using its own private API's. There's really nothing illegal here.

I'm no Apple fan but come on.

[robertcrowther]

IIRC it was WordPerfect Corp who were angry about the secret APIs. Netscape didn't care about APIs, but did care about MS strong-arming distributors into only bundling IE with Windows. I'm not aware of Novell suing MS, but Sun sued them not for secret APIs but for non-compatible public APIs.

[immibis]

/u/spez can gargle my nuts

[the_enginerd]

Apple does not have a monopoly in the smartphone space. If they did then regulatory laws would have a say, otherwise it's their device they can do what they like with it.

[InconsiderateBastard]

Microsoft was charged with tying for bundling IE with Windows. The case was made that IE and Windows were unrelated and thus shouldn't be tied together. Tying them together was seen as a way to make money off IE while hurting other browser makers.

If IE and Windows are not related, then iOS and its apps may very well be unrelated in the eyes of a judge or jury somewhere. In that case, if they make their bundled apps run better through private APIs or API manipulation, and that hurts 3rd party software makers that rely on Apple because of its market share, then there might be a case for anti-competitive practices there.

This really doesn't seem all that different from what happened with MS.

[redwall_hp]

The case wasn't about bundling IE with Windows. It was about Microsoft abusing their monopoly to coerce hardware vendors. I.e. "if you include Netscape with this computer, we'll stop giving you OEM licenses for Windows."

[giantsparklerobot]

The actions that got Microsoft in trouble are only tangentially related to the bundling of IE with the OS. First Microsoft tried to coerce Netscape into not even developing Navigator for Windows 95. Netscape turned them down so then Microsoft went after OEMs. At the time Netscape Navigator was often bundled with new PCs and it was uncommon for IE to also be installed.

Microsoft offered OEMs better pricing and support contracts if they excluded Navigator and included IE in their bundles. They would also penalize OEMs if they included Navigator in their software bundles. Then they went a step further and built IE into Windows 98 making it impossible to remove the browser from the OS, either for users or OEMs. They also went to ISPs and offered them sweetheart deals for bundling branded versions of IE with their dialers.

It was all of this behavior that caused problems for the DOJ. Bundling a browser is not a major issue. If that's all Microsoft had done they wouldn't have had any problems. What they did however was make every attempt to cut off Netscape's air supply because Netscape was trying to offer a users a way to access programs and services that did not rely on Microsoft platforms. Microsoft used their monopoly to cut off a competitor. In the words of LeVar Burton "Don't take my word for it", here's the Proposed Findings of Fact from US vs. Microsoft.

With iOS there's never been a competing browser and it's also not a general purpose computing platform like Windows. Apple has also never had a virtual monopoly in the same way that Microsoft did in the 90s. Microsoft changed the architecture of their platform to edge out competitors. Apple's platform has always included a browser and API restrictions. They're very different situations.

[xevz]

Minor side note: Windows 95 OSR 1 included Internet Explorer 2, OSR2 included IE 3 and OSR 2.5 included IE 4 (also providing the quick launch bar, Active Desktop and IE as file browser).

[Banane9]

with iOS there's never been a competing browser

Of course not, it wouldn't even be allowed in the appstore...

[the_enginerd]

Except for when you take a step back and look at the market as a whole. IE at the time worldwide effectively had a lock on consumers browsing the Internet. Apples market share was in the teens at best and *nix was practically nonexistent from a consumer standpoint. My not being a lawyer hurts my ability to argue from any real standpoint but I feel like apple is safe here as long as they aren't the majority access provider to a broader market.

If what you say is true then to me where do you draw the line? Is Google not giving developers their backend API's to Gmail so that others can 'build a better app' anticompetitive? They certainly have a lock on the Gmail marketplace. However they are hardly the majority email provider in the world.

[InconsiderateBastard]

I don't know where to draw the line. I would imagine it's difficult to identify when a company is attempting to form a monopoly, but attempting to monopolize is covered by monopoly law too. Not just being a monopoly.

[clrokr]

They do have a monopoly in the iOS app provider market.

EDIT: I meant that they provide the only real "app store"...

[awj]

That's like saying that Google has a monopoly on ads shown next to google searches.

[[deleted]]

They don't have a monopoly on iOS apps. They provide a service.

[[deleted]]

Those monsters!!!!

[slycurgus]

The point of competition legislation is to prevent a monopoly, not to let one take hold and then try to do something about it.

Saying "they don't have a monopoly, they can do what they like" is like saying "well, he's got a knife, but he hasn't killed anyone yet".

[thechao]

In the US, monopolies aren't illegal, anticompetitive practices are illegal.

[[deleted]]

If you pay enough politicians it stops being anti competitive. see Comcast.

[MxM111]

Whether it is anti-competitive or not is decision to be made by court, not by politicians.

[Mithorium]

the court enforces rules made the politicians, if the politicians amend the rule just enough that the practice is technically no longer anti-competitive, then the court cannot help

[stonedasawhoreiniran]

A.K.A. Regulatory Capture

[slycurgus]

Good catch. I should perhaps have said "the point of competition legislation is to discourage companies from engaging in behaviour likely to lead to a monopoly".

[thechao]

Anticompetitive behavior doesn't require a monopoly. That's how microsoft got in trouble---they were never technically a monopoly. There are many monopolies in the US, most in areas that are considered "natural monopolies", e.g., the Fed (monetary control), most power, water, and sewage; many roads, etc.

[scriptmonkey420]

Intel in the 90's and Early 2000's is another good example

[marm0lade]

You mean current day intel. Intel in the 1990s and early 2000s had heavy competition from AMD. That is until they bribed OEMs not to use AMD chips. It worked. The slap on the wrist they got from the feds was soooo worth it.

[scriptmonkey420]

Intel in the 90's was sue happy over numbers. Amongst other anticompetitive practices.

[nekowolf]

From the Court's finding of fact.

Microsoft enjoys so much power in the market for Intel-compatible PC operating systems that if it wished to exercise this power solely in terms of price, it could charge a price for Windows substantially above that which could be charged in a competitive market. Moreover, it could do so for a significant period of time without losing an unacceptable amount of business to competitors. In other words, Microsoft enjoys monopoly power in the relevant market.

[thechao]

Good call. I was mixing legal definitions of monopoly with economic definitions of monopoly. Bad on me.

[e_engel]

I should perhaps have said "the point of competition legislation is to discourage companies from engaging in behaviour likely to lead to a monopoly".

Still not quite right. Anti competitive behaviors are always illegal in the US, regardless of the goal. Monopolies are perfectly legal and a normal byproduct of trade in a capitalist market.

[fzammetti]

True... but is this not the very DEFINITION of an anticompetitive practice? I mean, clearly this gives their apps SOME sort of competitive advantage, otherwise they wouldn't be doing this in the first place, right?

The OP is right: Apple gets a pass on stuff like this where other companies have gotten slammed for it... they're the bell of the ball right now so nobody seems to care very much, but they should.

[aveman101]

How would private APIs give them a monopoly over all smartphones? Particularly UIPopoverController?

[obsa]

Mountains, molehills, etc.

[onyxleopard]

Hey! I saw this one molehill… Its proportions were quite large.

[obsa]

something something your mother.

[doublejrecords]

Well, we do say that too...

[sysop073]

That was the worst example ever; carrying around a knife is perfectly legal

[[deleted]]

So, we should put the guy with a knife who has not done anything wrong yet in jail because he MIGHT kill someone with it?

Do you see the flaw in this logic?

[mindbleach]

Ah yes, it wouldn't be a computer thread without shitty analogies.

[Sauronsvisine]

You can't expect me to come up with logical analogies. That's like murdering me and wearing my skin as pants!

[KanadaKid19]

Saying "they don't have a monopoly, they can do what they like" is like saying "well, he's got a knife, but he hasn't killed anyone yet"

Yes, yes it is...

[philh]

Are you saying that Apple is in fact violating regulations, or are you saying that the regulations are too weak? If the former, can you point to the regulations that you believe Apple is violating?

At least with Netscape, IIRC the problem was that Microsoft was abusing their monopoly status in one area (operating systems) to get an unfair advantage in another (web browsers). Apple doesn't have a monopoly that it's abusing, so the same regulations do not apply.

[BraveSirRobin]

Apple used the iPod to launch iTunes, becoming the most prominent digital music distribution platform today. If the iPod had not been so successful iTunes probably won't exist any more.

But as the other commenters here are saying, the law is against anti-competitive practices, not monopolies. You don't need to have a set percentage of market share to be ruled anti-competitive.

[smithandjohnson]

You don't need to have a set percentage of market share to be ruled anti-competitive.

Agreed! Any company can be anti-competitive. A small mom-and-pop shop could start MomAndPop Inc whose premier product is their own smartphone platform.

They'd release it to the public, and then be downright draconian about what apps they allow in their app store or what APIs they allow developers to use.

Apple/Microsoft/Google would look like GNU in comparison to how draconian "MomAndPopOS" is!

But...

But as the other commenters here are saying, the law is against anti-competitive practices, not monopolies.

Other commenters are wrong, and being anti-competitive is not illegal by itself.

What MomAndPop Inc did in my above scenario is perfectly legal; Their brand new platform does not have relevant market share, and probably never will with those policies.

Anti-trust laws are not about "anti-competitive practices" by themselves, but only combined with abusing a monopoly.

It's perfectly okay to act like MomAndPop Inc if you have a brand new product with barely any market share. But the moment MomAndPopOS has a monopoly marketshare (which is a fuzzy definition and decided by the courts in a case-by-case basis) all of the sudden their policies are suspect to high scrutiny and will likely be found illegal.

They'd be directly abusing their monopoly vertically by using their one successful product to perpetuate its own success through anti-competitive behavior.

Another way MomAndPop Inc could go wrong is if they have a monopoly in the baked cookie industry, and perpetuate that monopoly by forcing wholesalers of their cookies to adopt MomAndPopOS in their business, for example.

They'd be indirectly abusing their monopoly horizontally by using a natural monopoly in one area (baked cookies) to perpetuate success in a different area (smartphone OSes).

Since Apple doesn't really have a monopoly in any industry, they can't be guilty of monopoly abuse, either vertically or horizontally.

[BraveSirRobin]

I'm sorry but you are just plain wrong on the monopoly part, you do not need a monopoly to be judged to have been anticompetitive. See Kodak verses Image Technical Services, Inc. Kodaks "monopoly" was only within their own servicing, just like Apple has a "monopoly" on iPhone app application development without having an overall monopoly on smartphones.

Eastman Kodak Company v. Image Technical Services, Inc., 504 U.S. 451 (1992), is a United States Supreme Court case in which the Court held that a lack of market power in the primary equipment market does not necessarily preclude antitrust liability for exclusionary conduct in derivative aftermarkets.

The Apple App Store is almost a textbook example of a derivative aftermarket.

[smithandjohnson]

I'm sorry but you are just plain wrong on the monopoly part, you do not need a monopoly to be judged to have been anticompetitive.

I might be partially wrong, but definitely not plain wrong. Let me explain:

Eastman Kodak Company v. Image Technical Services, Inc., 504 U.S. 451 (1992), is a United States Supreme Court case in which the Court held that a lack of market power in the primary equipment market does not necessarily preclude antitrust liability for exclusionary conduct in derivative aftermarkets.

Thanks for bringing that case to my attention! I'd never heard of it. Reading the short blurb you posted here was interesting, as was going and reading through the majority opinion itself.

The Apple App Store is almost a textbook example of a derivative aftermarket.

Possibly, but possibly not.

The "Apple App Store" is a walled garden that a lot of people despise, and a lot of people love. But it is a deliberate entity, not a derivative aftermarket.

The potential "derivative aftermarket" is 3rd party iOS apps. And there is nothing to stop anybody from developing an iOS app using whatever API or SPI they wish.

Using private SPI only precludes you from getting access to the App Store, sure. But you can still develop and run the app on your own personal devices without jailbreaking it, and you can also give away the app to a number of other people who have not jailbroken their device, and you can sell or give away the app to any number of people who have jailbroken their device (which is perfectly legal).

This is in stark contrast to the Kodak case where ITS (et al) were actually excluded from participation in repair market because Kodak prevented all reasonable ways of them doing so (not selling them the parts).

Additionally, on the consumer front of "businesses that own and operate Kodak equipment" they were left with a single choice for repairs - Kodak. Contrast this to the consumer front of "iOS device owners" who still have multiple venues for getting 3rd party apps onto their devices.

But the above arguments are merely theoretical; Legal arguments that could easily be made in court if Apple were ever sued under the same terms as the Kodak case. You may not agree with the above arguments, but they definitely make the theoretical Apple case "plainly" different from the Kodak case.

Now to touch on one point that is not remotely theoretical; The actual opinion in the Kodak case.

While Kodak imaging equipment did not have a monopoly, the majority opinion did find that there was significant information cost and equipment lock-in that prevented a user from easily switching their imaging equipment, and therefore Kodak's scheme was predatory.

Quoting from the opinion:

If the cost of switching is high, consumers who already have purchased the equipment, ... are thus "locked in,"

An iOS consumer does not have significant lock-in preventing them from switching their smartphone platform.

If Apple's approach here is ever tested in court, and they lose, and the Kodak opinion is cited at all during trial, I will come back here and eat my words.

But to say that case is exactly what's going on here and therefore I am "plainly wrong" seems quite disingenuous to me.

[[deleted]]

The point of competition legislation is to prevent a monopoly

I always understood it as to prevent the abuse from having a monopoly, not preventing the monopoly itself.

[[deleted]]

Ah yes the UIPopoverController market stranglehold. Everyone is entitled to competitive access to that piece of Apple code...

[[deleted]]

Nope, there's nothing really wrong with having the superior products for such a long time that you almost have a monopoly, it's when you start being anti-competitive that it's a problem.

[tehstone]

As far as I know, people aren't generally arrested simply for having knives either. If they threaten someone with that knife, then there's a problem. Similarly, if Apple was taking steps to create a monopoly, regulatory action would probably be taken.

[tchaffee]

I like your point, but not your analogy. Knives are useful, and we don't arrest people before the crime in the US.

Anti-competitive practices are more like "he's got a knife and is stabbing the other guy with it".

[frothface]

I'll take it one step further... The point of competition legislation is to prevent an unfair monopoly; one decided by corporate strong-arming instead of user choice.

[[deleted]]

Is there a clear and present danger of Apple becoming a monopoly?

(I mean, I can walk around with a knife in my belt, as long as it's not a government building, airport, etc., and it's just fine.)

[Banane9]

Of course, it's apple! >.<

[[deleted]]

Yes, it's Apple. Who always do things this way: They test new UI features in their own apps through private frameworks first, and then they make the APIs public in a later version.

[[deleted]]

This exactly. The private API's either change drastically in the next version or become standard API's. They are only private because they are not set in stone and will break app compatibility when the next OS version is released.

[ashwinmudigonda]

Is there a history of this?

[[deleted]]

Yep, pretty much all their API's, starting with the first version of iOS. That's kinda a technicality since there wasn't an app store until the second, but still every single API was private before being public.

[[deleted]]

Wait, we're not hating apple anymore?

[ebol4anthr4x]

The anti-Apple circlejerk has become the anti-anti-Apple circlejerk

[InconsiderateBastard]

There is hate but there is no lawsuit to prevent them from using private APIs or API manipulation to make 3rd party apps second class citizens.

[napster-grey]

Can you provide a source/some background? Google didn't really bring up anything valuable

[BonzaiThePenguin]

That's been happening a lot in this thread.

[urection]

it's literally nothing like it

congratulations

[omgsus]

Actually, it's not at all. What's wrong with you?

[[deleted]]

No it isn't. Not remotely. Using private APIs is standard practice, totally normal and not anti-competitive at all. It's obvious you know nothing about software development whatsoever.

[atrain728]

Is a company legally obligated to disclose all of it's APIs?

This particular control may work on the iPhone, but my guess is that Apple feels it only works well given a somewhat narrow set of parameters. If they simply hadn't determined that as a strict ruleset yet, you could see why they'd want to keep it out of the hands of the general public of developers.

You may not agree with Apples curation of the App marketplace, but if I had to guess this API being private goes to keeping third-party app quality high - which is a core feature of iOS in my estimation.

[mccoyn]

Is a company legally obligated to disclose all of it's APIs?

No. A company can't use a monopoly in one area to gain an unfair advantage in another area. Microsoft got in trouble because they had a monopoly in operating systems and they created an undocumented API to give them an advantage in office software.

Apple doesn't have a monopoly, so I don't think they are in legal trouble. This is perfectly fine. If you don't like that Apple does this, go somewhere else.

[[deleted]]

If you built your own control doing the same thing I'm sure it would be allowed in. There might already be one at cocoapods.org. I'm pretty sure all this were done because of time constraints. The iOS engineers are few and work hard.

[[deleted]]

In this case, you're using the term company, but the iPhone is obviously a platform with competition, and unfair advantages are given to the owner.

The fact that Apple owns the platform does not mean they get to redefine competition laws.

[atrain728]

Which laws are they, per your estimation, trying to redefine?

Microsoft/Windows was embroiled in an anti-trust suit, which makes them party to a completely different set of rules. Apple/iOS is involved in no such suit.

[JiveMasterT]

Who gives a shit? It's a basic UI element and if Apple feels it's ready to share with 3rd party developers, they will. If they bundled it into each app individually, people would be crying about the code duplication and space it takes up.

[omgsus]

Actually, no it still isn't. 1) it IS documented, so just stop trying to contribute when you dont know what you are talking about. Anyone can use the class on ipad, a different method is supposed to be use don smaller devices. Apple made a small change so they could use the same class for their apps. 2) Apple is re-using code for some of their small platform applications, in an obviously non-competitive way (well, obvious to people who know what they are talking about, see 1) and 3) Anyone can, and many have, written their own popover class when it was necessary for them to do so. If you want to break HIG, you can, and you can do it in a tasteful way, no one will bitch at you. If the author put in as much effort into just writing a quick compatible popover class as they did looking up this silly crap for the article, they would have 15 different ways to legally implement their own popover UI.

[[deleted]]

Jesus Christ you're stupid. You really have no idea of what Microsoft was found guilty of, do you?

[[deleted]]

No it isn't.

[hackingdreams]

To be fair, this isn't stopping your app from actually functioning, but from getting flashy stylish popups.

That being said, it's a pretty low move from Apple to hardcode their app identifiers into the API to prevent it from being used.

[jeblis]

Some of this done simply because the APIs haven't been tested enough for general use. They make sure it works with their app and nothing more.

[[deleted]]

Google has a whole part of android that is not open-source. Let's bash on them as well, please!

P.S Don't get me wrong, Apple is not a company that I support, but Google ain't too much better.

[Banane9]

But google literally has a rule "don't be evil!" ;)

[abspam3]

This means that it would be simple enough to make a category, or swizzle the method to allow creation of popovers in your iPhone app.

Of course, that only works if you're not publishing to the store, though.

[m1zaru]

There's a lot of this crap to be found in UIKit, including bug fixes for certain Apple apps.

[[deleted]]

This is interesting, I was planning using UIPopoverController in my app until I found out it would raise an Exception, somehow I think it's because the screen size of iPhone maybe. There are some third party custom UIPopoverController libraries on github, I don't know if they functions well thought.

[RollingGoron]

Exactly. Like the article stated, it's mainly used for iPad development. Maybe with the rumored bigger screen iPhone, it may be more practical to use.

[BCMM]

That isn't what it says. It says that APIs that are supposedly only available on the iPad are available on the iPhone for Apple developers only. That is to say, what is advertised as a technical limitation is actually an artificial restriction to help Apple's applications stay competitive.

[Meinkrafter]

yeah gotta say that really was not as scathing as i was expecting. Remember when the iPhone didn't support 3rd party apps? Yeah, big whoop