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
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.
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.
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
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.
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
> 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).