Slashdot Mirror
Apple May Face Antitrust Inquiry
suraj.sun writes with this excerpt from the NY Post:
"According to a person familiar with the matter, the Department of Justice and Federal Trade Commission are locked in negotiations over which of the watchdogs will begin an antitrust inquiry into Apple's new policy of requiring software developers who devise applications for devices such as the iPhone and iPad to use only Apple's programming tools. Regulators, this person said, are days away from making a decision about which agency will launch the inquiry. It will focus on whether the policy, which took effect last month, kills competition by forcing programmers to choose between developing apps that can run only on Apple gizmos or come up with apps that are platform-neutral, and can be used on a variety of operating systems, such as those from rivals Google, Microsoft, and Research In Motion. An inquiry doesn't necessarily mean action will be taken against Apple, which argues the rule is in place to ensure the quality of the apps it sells to customers. Typically, regulators initiate inquiries to determine whether a full-fledged investigation ought to be launched. If the inquiry escalates to an investigation, the agency handling the matter would issue Apple a subpoena seeking information about the policy."
...I can understand where Apple is coming from, as far as wanting to maintain the quality of the programs available to its users, but that is still a thinly veiled attempt at justifying keeping their devices locked down tighter than a million dollar whore.
For a company whose users have been stereotyped as hipsters, they really love to retain control over EVERYTHING they sell.
Living With a Nerd
This falls into the "not all" category though, I think, since it's an investigation of whether Apple's engaged in anticompetitive tying. The iPhone / Apple devtools tying is somewhat reminiscent of the car-makers / car-parts antitrust investigations, which happened even though no carmaker actually held a monopoly in the car market.
I think it'd be a problem for Apple if it were possible to show (e.g. by discovering an unwise internal memo) that the main purpose of the restrictions is to restrain trade, e.g. to harm the market for competitor development tools, or to make it harder to port apps to/from Android. Apple would want to be able to show that the tying was done for legitimate reasons not related to restraining trade.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I think Apple is in trouble because they decided to change their developer agreement *days* before the public unveiling of Adobe CS5. Adobe had been promoting for many months before that the new version of Flash would support export to iPhone. And Apple pulled the rug out from under them days before the release of their product. What happens if a subpoena finds an email between Apple employees suggesting the optimal time to change the licensing terms to damage Adobe (who put a lot of time and money into this feature)? IANAL
Apple does not require developers to use Apple tools, only the approved languages, which were not invented and neither are owned by Apple: Objective C, C, and C++. XCode is the IDE provided by Apple, and it uses GCC to compile the code.
You are free to use whatever you want, as long as the code is originally written in one of those languages and not ported from a different platform.
-dZ.
Carol vs. Ghost
Up until recently, there was *no* way to get compiled apps on the phone. You were stuck with web "apps". Apparently that was fine, but allowing apps and restricting the development language is not ?
A web app though is more or less platform neutral though. The entire point of this inquiry is that when you develop an app for the iPhone you have to almost completely re-write it for every other platform discouraging developers to port to other OSes.
Most (not all) antitrust legislation is aimed at preventing monopoly exploitation of alternate markets. There is little evidence that Apple has any sort of monopoly unless the category is defined so narrowly as to be useless.
The point of the investigation is to investigate if the point of Apple's restrictions is to create more or less an app store monopoly by preventing the approval of apps that would work on multiple platforms.
For example, lets say I just made the game Zombie Attack. If I made it in a platform neutral language like what Adobe has I would be able to ship the game on PC, Mac, iPhone OS, Android, BlackBerry OS, Linux, etc. with minimal changes. On the other hand, if I wrote it for the iPhone with the iPhone SDK, I would have to completely re-write the game to get it to run on any of the other platforms.
This, in essence allows Apple with a large percentage of smartphone sales to dominate the market by effectivly "blocking" their apps from appearing in competitor's stores because of the pain it takes to recode the program.
I still don't see why Apple aren't allowed to set the terms of participation in their program. If you sign up as an iphone/ipod/ipad developer, you know what you're getting into, and you know they can change their rules at any time. Don't come whining when you don't like it any more
Because their terms of participation is blocking free competition for most users who don't jailbreak.
The problem isn't that Apple can set the terms, it is that Apple is setting the terms -only- to prevent people from coding the same app and running it other places, so Apple can have the app exclusively and keeping people tied into the iPhone rather than the cheaper, diverse and more feature filled Android, BlackBerry, and other phones.
Taxation is legalized theft, no more, no less.
I hadn't thought of this, and this is exactly right. I don't even think they need to find an email: this seems (perhaps illegally) anti-competitive on its face.
if apple went ahead with that policy, and tried to practice it, Eu would eventually bitchslap them into changing it. And what Eu does is nothing like what FTC does - When microsoft tried to stall compliance with Eu's decision, Eu started fining them 500,000 Euros a day. Suddenly microsoft managed to come up with a compliance plan that was implementable in acceptable time. Now we have ballot boxes in ms oses sold in europe.
FTC would be way too soft on american corporations, due to the lobbyism plague there is in america.
apple should thank ftc.
Read radical news here
I think it really comes down to whether or not their dominance over mobile apps is sufficient to count as a monopoly - and even if it isn't currently, it could well become one with expansion into the MID market with the iPad.
Depends on the kind of antitrust suit. Certainly you can't be guilty of monopoly leveraging unless you have a monopoly, so you're right as far as that goes. =] And it's also true that that's generally the easiest kind of antitrust claim to prove (it's what Microsoft was accused of), because there's a very strong presumption that if: 1. you're a monopoly; and 2. you're leveraging it; then that's bad, regardless of what "legitimate reasons" you have for doing so. (It used to even be considered always illegal to leverage a monopoly, but recent Supreme Court decisions have chipped away at that.)
There are other kinds of anticompetitive trade practices, though, with lower threshholds. At the one end of the scale is being a monopoly, where your conduct is closely scrutinized; at the other end is being a tiny player, whose market power is so small that any claim you were engaged in anticompetitive behavior is implausible. But in between there's a whole area of restraint-of-trade and anticompetitive tying, where you can be guilty of an antitrust violation without being a monopoly, if you have sufficient market power to influence another market improperly, and you did in fact do so. For example, some car manufacturers lost antitrust cases relating to car parts, despite not having a monopoly on automobiles: courts found that e.g. Mercedes banning anyone from making Mercedes-compatible parts was anticompetitive tying between the car market and the replacement-parts market, even though Mercedes isn't a car monopoly.
Those kinds of cases often come down to what the intent of the tying was. Mercedes argued that they wanted to control the replacement-parts market not for anticompetitive reasons, but for quality-assurance reasons; the courts ended up not buying that. But often courts do buy arguments that there was a legitimate reason for tying (possibly even most of the time; non-monopoly tying prosecutions succeeding isn't that common). In Apple's case, they would presumably argue that the purpose of requiring XCode and certain languages isn't mainly to restrain trade in dev-tools markets or to make it harder to port apps, but because of reasons related to its app-review process ("it's easier to review apps if they're all in Obj-C on XCode" or something). I could see a court giving reasonable deference to that, though predictions are always dodgy. The main place I could see that failing is if there's some smoking-gun email that ends up as evidence, where a VP or someone says, "hey we should institute this new requirement because of [reasons that sound like restraint of trade]".
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Inquiry != prosecution.
The point of an inquiry is to determine whether there is a basis for an anti-trust case or not.
There isn't some pre-inquiry inquiry to decide if the company has enough market share or has behaved in ways that violate anti-trust laws, so there's no point in crying about how Apple doesn't meet the criteria for an anti-trust case.
So this is what it comes down to?
Apple : Lawful Good (self-righteous)
Google : Chaotic Good (for now)
Taiwan Mfg : Chaotic Neutral
Microsoft : Neutral Evil (of course!)
SCO : Chaotic Evil
-- Home is where you eat your heart out.
Well, there is some prior case history on this. Back in the late 90's, MS was found guilty of exploiting a monopoly with Windows with regards to Netscape and Internet Explorer. They used their market position with Windows to push IE onto Windows Users. Never mind the fact that alternative operating systems existed. Never mind the fact that people COULD install other browsers once they installed Windows. They looked at the market space that was defined by Windows programs, and looked to see if MS was abusing that space. It's not a far fetched idea to translate that to the iPhone issue. Apple is locking off their internal market space by using what is a monopolistic hold on their operating system. The difference here, is that people CANNOT install competing software from another source than Apple. So in a sense, it is a clearer case than MS lost.
And people were free to chose a different OS from Windows. Yet they still found the MS exploited a monopolistic hold on the OS to push IE. Apple clearly does have a monopolistic hold on the iPhone OS (Even stronger of one than MS did). The question is not are people free to choose another device, but are those with the device free to choose another avenue of operation (away from Apple). The average user isn't told that their phone won't run non-Apple approved apps before hand. The average user isn't told "If you don't like these policies, don't buy this phone". They are told "Check out what this phone can do!", and "Look at all these apps it can run!". Not to mention that once they buy the phone, they are locked into a multi-year contract which will cost them money to terminate. So at absolute least, if this is not an abuse of monopolistic power, it is a case of deceptive advertising. They are not presenting users with a fair and complete choice. They are showing one side of it, and then locking down the other. So yes, users are free to choose another device, but they aren't given enough information (without going out and knowing what to look for) to make that choice intelligently.
Well, it's quite simple. They are allowed to set the terms of participation. However, I don't think they should be able to change their rules at any time (And/Or enforce them retroactively). If I signed up and agreed to their terms 6 months ago, I would be abiding by their rules to develop in {insert language x here} and convert to ObjC for submission. So I spend 6 months working on my application, only to be told today when I submit that it's no good because they "changed their rules". In my mind, there are few clearer examples of abuse of market position than that. It's an arbitrary rule set out do nothing but exact control (They have reasons why they did it, presumably to stick another knife in Adobe). But it does have significant collateral damage (being the developers who now have lost time because they were following the rules a month ago). And those interests do need to be protected.
Just my $0.02...
If a man isn't willing to take some risk for his opinions, either his opinions are no good or he's no good
Let's not be too drastic with these inquiries. Apple might get mad and move all its manufacturing jobs to China or something.
Reply to That ||
It seems like you're overstating the case. As an app developer I can code something for Windows, but will have to separate the API calls if I want to easily port for KDE (for instance). Assuming I write in C/C++ I can do this, with extra effort. I could also write my app in Flash so that it is portable, but I then have to accept the limitations of Flash. In this case, for the iPhone it seems to be the same situation, with the limitations for Flash being that it does not work. So I can still develop an app that I want to market for the iPhone as well as other mobile (or even desktop) environments, and the situation is no different than it has been at any time in the world of computers. That is if I want to easily port my app to different platforms I will have to abstract the platform dependant portions so that I can re-use the rest of the code directly, and have separate bits of code for the various APIs and such. While I don't necessarily agree with Apple's iPhone policies, I don't see anything anticompetitive with regards to this particular policy (you must develop only in C, C++, or objC).
Other way around. You can't use their APIs unless you're using ObjC, C/C++.
I am not sure that is really true. Section 3.3.1, as far as I can tell, places no restrictions on supporting code (think 3rd party libraries). What you are required to do is write any code that links against Apple's provided APIs to be originally written in C, C++, or Objective-C (hereafter known as C-family languages).
What this means to you is that you can write your program in Flash, write a compiler* to convert the Flash output to code that can be executed natively**, and write an application in the C-family language of your choosing to provide a bridge between your own APIs used by the compiled flash code and Apple's frameworks.
No matter how you slice it, if you want your compiled Flash code (or any kind of platform neutral code) to run on any device you would have to provide an intermediary between the Flash API and the platform APIs. Even before the change in license, Apple's APIs required that your language be compatible with linking against C and Objective-C frameworks. Naturally, most developers will choose to implement the necessary bridge in a C-family language. As far as developers are concerned, nothing has really changed, save a few edge cases.
* Because interpreting code is forbidden
** Required step because Adobe will no longer be releasing theirs
1) Seriously? Either you're joking or you truly are a hardcore "fanboi". And even for the phones which couldn't install software, at least they were non-discriminate about it. That's sort of what this "anti-trust" stuff is all about.
3) So what? Apple have proven that they'll screw over anyone who doesn't fit in their scheme. I don't see why we should give them any benefit for "apparently talking with Unity"
4) Anti-trust, or competition law, is to prevent anti-competitive behavior. There's a myth going round here on Slashdot that companies have to be a monopoly before they have to obey the law. But that's just fantasy.
5) The same could be said for any business or government. That still doesn't make their actions right.
6) We're discussing whether Apple has acted illegally, not whether or not it fits in their EULA.
Really? Please tell me how to develop for iphone without ever buying a mac.
Can you point out where it says that? The agreement actually has a specific item in it that specifies if you use any FOSS you agree to satisfy the requirements of the particular FOSS license.
There was a time when the SDK was under NDA and so you weren't allowed to discuss it in public, but that time is past, except for the bleeding edge beta releases. There are lots of publicly viewable discussion groups, including one hosted by Apple, and many, many tutorials (that would be publishing code).
Microsoft :: Capitalism. :: Fascism. :: Communism.
Apple
Unix
-Clio
Karma: Bad (mostly from not giving a fuck)
Blog: http://clintjcl.wordpress.com
Apples only restriction on book pricing is that the price must end in 99 cents. They also have a restriction that you can not sell your book in another online store for less than you charge in Apple's store, but Amazon has the exact same restriction.
All other pricing decisions are made by PUBLISHERS. Amazon forced publishers to sell books at prices lower than they wanted to. Apple has simply said that publishers should decide their pricing.
This case has nothing to do with web standards, but beneath all your struggling you seem to have a point.
100 million iDevices to give them a certain market power and it is possible for regulators to use that as a basis for an anti-trust investigation.
I know a bunch of people are going to say I'm some kind of fanboy or something, but: there are reasons to believe this restriction is not entirely business-driven. That is, there's reason to believe there's some technical reasoning behind it.
Now, I do believe there are business reasons too. The technical reasons wouldn't be enough to forbid all environments other than Xcode+Objective C. I could see something like MonoTouch being able to meet the actual technical requirements trivially.
But do you know how MonoTouch actually works? The result would not be portable. It would be just as tied to the iPhone as an Xcode/ObjC app, it would simply be using another language.
Apps on the iPhone need a particular application architecture if they're going to perform well. This is true now, but is going to be even more true in the future, when the OS tries to do more complicated things with each app than simply "jump to it when the app starts, and shut it down completely when the app ends".
The same is true on Android by the way. If you want to use Android's frameworks, you have to access it from within their custom JVM. Yes, you can program in C, but your C can't call their frameworks. You write your C using JNI to make your C routines available to the Java code, and some minimum "stub" Java code has to glue your code to all the Android frameworks. And if you want your code to continue running in the background, you have to fork off a "Service" that is essentially the Android version of a daemon.
The same looks to be true of WP7. It looks like you code your UI up as a silverlight or XNA app, and you flow data into it via ActiveSync (I am not clear on all of the details). Each of these platforms requires a completely fundamentally different architecture to write to. You're not going to get true portability across them easily, not and get a decent experience with the app.
So anyway, on the iPhone OS, you need to have your UI broken up into a set of XIB/NIB files, and each "view" needs to have a "view controller" object -- and by "object" I mean something that the on-device Objective-C runtime sees as an Objective-C object. Has to have the semantics of an Objective-C object, and has to support the introspection methods of an Objective-C object (just as Android objects have the semantics of Java objects). If all that is in place, then the OS can (in theory) do stuff like unload UI assets and UI-related objects from the running process, and notice before they're needed (via Obj-C introspection and method interception and stuff), and load them back in before they're missed.
So if you're using MonoTouch, which is basically (from what I read) little more than a way to do Objective-C programming using C# syntax, you could be fine. Your UI assets would still be in those separate XIB/NIB files, your controller objects would be indistinguishable from "raw" Objective-C objects as far as the runtime is concerned, and so on. So stuff like that ought to be permitted. And it won't be portable.
So, Apple could say something more along the lines of: "Here are the rules. Your UI needs to be implemented as a set of XIB/NIB files in these data formats that the OS can inspect in these ways, and that the OS turns into a view hierarchy for your app upon loading. You need to specify connections between those view hierarchies and a bunch of things that behave as if they were plain Objective-C objects with regard to the following (very long) list of introspection mechanisms. References between objects in your code have to permit these sorts of relocation and this sort of serialization. And your callback methods need to behave such-and-such way, and any time we change the ABI for the closure functionality we added as an extension to the C-family languages, you must be able to conform to the possibly-extensive ABI change within less than a week of being informed of it. And and and...".
You end up with a very very long li
Everyone realizes that this announcements indicated that two government agencies are in the midst of negotiating to decide which one of them might launch an investigation.
Most of us will likely have died of old age before the investigation even starts. Why do real work when you can justify your existence by simply sitting around the office and bickering with the guys down the street.
It took 10 years to resolve the Microsoft case and their market dominance was clear and certain. 3 Years to come to agreement. Another 4 years for the DOJ to sure Microsoft for completely ignoring the agreement. Three more years to resolve the lawsuit.
Since it is unlikely these two departments will resolve their internal squabble any time soon. By the time they do one of them will be out for blood. Unfortunately there will be little to find.
If you can't use the undocumented APIs, and you can't use a wrapper around Apple's APIs, and you can't access hardware directly, you're directly tied to Apple's documented APIs, which ties the application very tightly to Apple's device.
But they're not controlling "the market"; they are only controlling their portion of the market. Their impact on "the market" as a whole, appears to have been to force competitors to make phones of comparable quality/usability; this, IMHO, is indeed the case, as there is a plethora of excellent Android (and otherwise) based products on "the market", and more coming. This antitrust stuff all seems a little bit premature, to me - Apple has by no means yet earned the right to say they "control the market".
The secret to creativity is knowing how to hide your sources. - Albert Einstein
That's a pretty paranoid reading. The agreement mentions the application and the program, but says nothing about the source code. Since you can't actually run the app unmodified on anything other than an Apple device anyway, I don't see why there's a problem. If you port it to another device it's not the same app. The intention seems to be very clearly that Apple doesn't want people trying to do an end run around the App Store, not that they're trying to prevent people from porting their iPhone apps to other platforms. If they actually sue someone for doing so then I take it back, but they haven't done that, despite there being several examples of iPhone apps being ported to Android and vice versa.
Yes, the wording is a little bit ambiguous, but it's far less so than many, many other legal agreements, including quite a few actual laws. Yes, the agreement has some parts, that Apple enforces, that aren't great. But I don't think this is one of them, at least not the way you claim.
They have over 90% of the iPhone market
I'm nearly 100% positive we have a definitive number on what percentage of that market they have, and that the number is >90%.
But wouldn't it be smart to investigate and look for signs of douchebaggery before they dominate the entire market? Just think how different the OS landscape would be if they would have looked into MSFT during the days of Win3.x instead of waiting until all possible competitors were dead or on life support.
If Jobs and Apple are really setting their terms to try to cut others out of the market now is the time to look into it, no after everything else is DOA and everyone is dependent on Apple. Hopefully we have learned from the little MSFT antitrust that if you wait too late it is kinda pointless.
ACs don't waste your time replying, your posts are never seen by me.
> All Apple needs to do to avoid this is publish performance and stability guidelines that can only be met by Objective-C or C++ code
Exactly - and it's very notable that they did not do this. They could also easily have written that all applications must support touch interfaces into their agreement. But they didn't. Because they know that in 5 minutes time Adobe would produce a version of Flash that complied with just about anything they wrote in their agreement. So they just had to out and out ban it based on "how" you made it rather than "what" you made. This is one of the telling points that gives lie to their motives.
I know a bunch of people are going to say I'm some kind of fanboy or something, but: there are reasons to believe this restriction is not entirely business-driven. That is, there's reason to believe there's some technical reasoning behind it.
If only your wall of text justified your opening statements.
There is no reason to believe that there is a technical reason behind it. Either the application works, or it doesn't. Thats supposed to be the end of the discussion on the technical aspect of this, but I'll go one further.
Apple is preventing applications written in arbitrary languages from being translated to C++. If there was merit to "technical reasoning" then surely the translated code would be acceptable to Apple, because after all, its C++ and thats acceptable. THis also is supposed to be the end of the discussion on the technical aspect of this.
No sir, you wall of text does not support your assertations. You are suggesting technical reasons, but are not describing any. Most of your wall of text is a "me too" appeal, where if Microsoft does it then its magically also OK for Apple to do it. You are wrong on several counts with that one, because A) Microsoft isnt doing it, and B) even if they were, that doesnt mean it would be OK for Apple.
"His name was James Damore."
How long would it take Adobe to release an update that handles background services, voip and other new features?
Why does it matter how long? Hell, I contend that they dont ever have release an update.
How long until the iFart App I have in the App store magically updates itself to support background services, voip, and other new features? Thats right, it wont, yet its still going to work.
You are imagining that using C++ somehow makes programs upgradable-via-magic.
"His name was James Damore."
While I don't necessarily agree with Apple's iPhone policies, I don't see anything anticompetitive with regards to this particular policy (you must develop only in C, C++, or objC).
Please have the guts to say whether you agree or disagree with their policy instead of the constant waffling and weasel words displayed by most of the Apple and Jobs fans here.
This policy disallowing cross-compilers is clearly aimed at one company - Adobe. I have been around computers for a long time and I've never seen such a ridiculous restriction - ever. It is very odd and is clearly and carefully worded in such a way to crush the Adobe Packager, but in such a way that they hope can avoid legal ramifications.
There is absolutely no technical reason for it - even to accomplish Apple's stated goals of having a consistent user experience. A cross compiler can generate native Apple code using documented API's. It still has to meet Apple's approval to get into the App Store which still allows them reject it if it didn't meet their other criteria.
It is clearly anti-competitive - whether it is illegally so would hopefully be explored in an investigation - although I'm not holding my breath.
But it is definitely wrong and I would hope even Apple and Jobs fans would have the courage to at least complain to Apple that attempting to crush their competitors will not be tolerated by their developer community (and I'm definitely not holding my breath for that).