Apple May Face Antitrust Inquiry 457
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."
Re:[sigh] (Score:5, Interesting)
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
Let's not forget mind control (Score:3, Interesting)
After all, it's how the RDF makes fanbois out of everybody who comes too close to His Jobsness.
Who is going to investigate that?
Re:[sigh] (Score:5, Interesting)
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.
Re:[sigh] (Score:2, Interesting)
Users are free to choose another device if they feel that strongly about the situation. My hunch is that /. won't accurately represent the marketplace, however.
One thing people tend to forget here on the dot is that Apple doesn't sell "computers" as we define it. They sell a style or rather a UI. It's like going to Casa Bonita [westword.com]; you go there for the scenery not the food.
As much as I hate Apple, it's their right to do what they want with the device. Especially considering that you have a choice of phones to choose from. Yes, Verizon+Droid is indeed a choice. Forgetting the touch UI issues with flash, it's just too slow and Apple wants their device to be as polished and native looking as possible for the "experience".
I'll put it in Star Trek terms: If you built your house to look like the bridge of Voyager, you'd be pissed if your [insert related person here] up and installed an ugly looking "crystal" SG-Atlantis control panel.
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
Yes, absolutely. The same applies for Facebook app developers too. You're programming for a closed platform, controlled by a closed company.
If you can't handle that, develop for Android.
Re:[sigh] (Score:2, Interesting)
Honestly i think it is the "not ported" part that is going to hurt them - ported to apple from another platform or the other way - one of the line items on the dev agreement is that you aren't allowed to publish the source code to programs submitted to the app store - effectively preventing all GNU projects from making it - and preventing any type of developer community out side of apple.
Re:[sigh] (Score:2, Interesting)
This is fine. Bet the policy stands, though. (Score:4, Interesting)
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
Re:[sigh] (Score:4, Interesting)
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.
Re:[sigh] (Score:3, Interesting)
1. BlackBerry will be getting Flash in the future.
2. RIM never outlawed any third-party development tools. If Adobe made a Flash to BlackBerry compiler I doubt they would disallow it.
3. This is ludicrous because the version of Java that runs on BlackBerry, J2ME, is cross platform and has been on nearly every mobile phone since the dumbphones.
Comment removed (Score:4, Interesting)
Re:[sigh] (Score:3, Interesting)
The first thing you have to prove in a tying case is that Apple has market power.
1. Apple's market cap, today, is larger than wall-mart.
2. Interview (ex-)executives in the music industry.
Interview (ex-)executives in any media industry.
Apple is a market force and exerts monopoly power in media and app distribution.
everyone is EFFING scared of them
Re:This is fine. Bet the policy stands, though. (Score:3, Interesting)
Good heavens, why do you believe that? "It works or it doesn't" is not supposed to be the end of the discussion. Where did that idea come from? If you think that, you don't understand Apple.
"It works" is important. But having every app able to switch to full multitasking support by doing little more than typing "make" once 4.0 comes out is also important. Being able to switch from Arm to x86 or any other CPU architecture by doing little more than typing "make is also important. Running seamlessly on an iPad or "iPhone HD" is also important. Having the unused pieces of your app able to be removed from memory so that background tasks have more space to run in is also important.
Maybe those are not important to a given app developer. Maybe those are not important to a given user.. This is harsh, but none of those folks get a say. They're important enough to Apple to form the kernel of a technical basis for the restrictions. (Restrictions which I've already agreed probably go too far.)