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."
Now normal service can resume, and the anyone-but-Apple brigade can froth gently at the mouth while insisting their rants are somehow not the mirror image of the "fanbois" they detest so much.
Simon.
Physicists get Hadrons!
...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
IANAL, so, someone please tell me-- Don't you have to have at least a majority in the product to have an anti-trust law suit win against you?!
The only claim I see the Feds have for antitrust is for Apple "tying" disparate products, hardware and apps, similar to the issue in U.S. v. Microsoft (o.s. and browser). However, given Apple has only about 25% of the market share in the smart phone arena, I do not see the basis for the Feds action. The development platform only lock for Apple products strikes me as failing to meet the antitrust standard.
Apple has it. They have a legal monopoly on the market of mobile apps.
At this point the not quite stiff but still present competition from other OSes like Android will probably prevent any real inquiry from going forward.
Far more concerning is this push by Apple, quickly being followed by MS, to deny user-replaceable local storage and locally-loaded software. I'd hate to see the whole industry go that way.
I am not at all fond of Apple's "use only our tools" stance, however I'm wondering exactly how they define anti-trust in this case? I understand that Apple is dictating devs to use their toolset, but how does this kill competitoin? Apple doesn't say you can ONLY develop for iPhone, they simply say to use X-Code for iPhone dev. Is it because Apple has a "monopoly" on their own products? Does the DoJ like Flash? Seriously, I can get that people are pissed off at Apple, but if you don't want to play, don't. Apple does not have a monopoly on touch screen phones, or tablet like devices, not by a long shot, and I fail to see how Apple telling it's developers that they need to use Apple tools as an anti-trust issue. Next we're going to hear from the DoJ that Apple is being investigated because OS X is only licensed for Macs? Maybe they will force Microsoft to develop Office for Linux, because I like Office and dammit I should be able to run Office on my Ubuntu machine. MS is forcing me to buy Windows or a Mac to run Office and that is anti-competitive behavior. Maybe the FTC and the DoJ should focus a little more on why we had to bail out the banks and Wall street and on how the behavior on their part hasn't changed very much. Or maybe Steve Jobs should buddy up with those guys and pay them a little more?
I still cannot find the droids I am looking for...
I don't think the problem is "supporting all languages", the Objective-C / C++ / Javascript IMHO isn't action worthy.
The problem is that the code must ORIGINALLY be written in those languages, no tool generating the code allowed.
I hope they roast Apple's fruity little ass with the biggest legal flamethrower they have stuck aside.
No, you don't. Consequences for them could also mean consequences for the product you like.
Maybe something will come of this, maybe it won't, but here's to hoping.
The 'good' you want to happen could mean Android has less of an edge to compete with them. Apple's "walled garden" is an opportunity for something more open to sneak in.
There are lines that you cannot legally cross, and Apple very well may have done so.
Only if you dislike Apple. Take that away and then obvious questions come up like "Is Nintendo next?"
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Which phone brand specifically disallows them? I'm sure if you came up with an emulator of sorts Google wouldn't give two shits if you put it on the Android app store.
It's not a matter of "supporting" something. It's a matter of them ACTIVELY PREVENTING it.
Even though in example it IS required to accommodate them, you can kind of relate it to a store either a) failing to install handicapped ramps, compared to b) clubing any handicapped person that tried to enter and throwing them back down the steps.
Which is worse? An active prevention is worlds away from passively not supporting something.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
Your choice:
Apple's Brave New World where proprietary is done right and trains run on time vs. everyone else's scattered proprietary banana republics where trains barely run at all and each has a different gauge of track.
I'll take walled garden built in Cupertino that keeps out the chaotic evildoers from Taiwan.
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?
thegodmovie.com - watch it
Apple has it. They have a legal monopoly on the market of mobile apps.
They do? When did the Android Market close down?
Track your TV Shows with your iPhone - FREE
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
Imagine only executables signed by MS's toolchain were executable on Win 8.
Or only binaries signed with Linus's or RMS's private key on 2.6.33 :)
thegodmovie.com - watch it
Link.
i.e., Not coming from just the New York Post.
Discussion System prefs link: http://slashdot.org/users.pl?op=editcomm
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.
Those Monopolistic Bastards!
I demand my Microsoft iPhone...
Look at the mac os x hardware lock in as well!
also the ATT I-phone lock in as well.
I think apple should at least make it free to put free apps in the app store with no $99 /year fee.
Also the apple app store censorship needs to go away as well.
"It will focus on whether the policy, which took effect last month, kills competition." Huh? Everything about the iProducts kills compeition. For Apple, killing competition (along with good ads) is pretty much their core competenacy. I'm not sure whether this is really something that the FTC should be investigating, but if they are going to do so, they need to widen the net and look at all the unprecedent ways that Apple uses its lock-down of the iProducts to block competition. Why limit it to just this latest trick? Again, I'm not certain that they should be doing this, but it sure would be nice if they could force Apple to stop using their control of the AppStore against their own users. We could have Google Voice, Mozilla Firefox, Ogg codecs, cheaper music, books, and videos, and even some competitors to Playboy if they want to keep Playboy around.
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...
I still cannot find the droids I am looking for...
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 ||
but in reality is *is* the case. They developed it, they can market/sell it as they see fit. The fact that people are throwing around the word "antitrust' or "monopoly" is rather ridiculous. There is still plenty of choice. Just because someone chooses to buy into the Apple brand doesn't mean they have to stay in it. Hell, it's not even difficult to leave if you want something different - on any of their platforms, be it computer or phone.
Everything they produce has something comparable (or better, in some cases) in the market. And before you go saying the iPad is unique in the market it's not. There are already options out there.
My understanding is that Apple is taking steps to disallow apps that would otherwise run just fine. For all the polish of the iPhone, it is simply a microprocessor and a screen. If a developer wants to write a program that the Apple processor can handle, why is Apple going to tell the developer that they aren't allowed to do so?
I would hope that Apple has the legal ground to deny apps. If people aren't happy with the Apple experience then they can go find another one. I just hope that those people who decide to choose Apple over other products won't bitch and whine other vendors don't support Apple's program. For example, I work in IT. In the last couple years it has gotten easier to get OSX to talk to non-Apple servers, but for the last two decades, putting an Apple workstation on a network required a whole separate set of network protocols, printing protocols, file sharing protocols and the like. The Apple folks wanted to do things the Apple way, but they also expected to be treated equally.
Steve Jobs seems to have some mental issues. As soon as his products start to lose their exclusive status and get to the point where interoperability is happening, he steps in and issues decrees and establishes mandates that go against wide spread acceptance.
I hope they roast Apple's fruity little ass with the biggest legal flamethrower they have stuck aside.
Why?
fanbois
Ah: Haters gonna hate.
You can't take the sky from me...
Probably not. It's the "Department of Justice and Federal Trade Commission", not the EU.
Not that anyone will read this before posting, but
Inquiry != prosecution.
Not that you read the summary before posting...
An inquiry doesn't necessarily mean action will be taken against Apple
Troll? Really? Whose feelings did I hurt?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
So if Apple gets the screws put to them, should Nintendo be next? Their system is even more closed than Apple's. How about Sony, with the PS3? Or Microsoft, with the Xbox?
Apple is the new Microsoft, after all.
False. And I wish people would stop stealing my meme. Adobe is now and will always be the new Microsoft, while Google is the old Apple, and Apple is the Tyrell Corporation. Think about it.
The Admin and the Engineer
Couldn't someone come out with a tool which would convert an iPhone app to an Android app? There isn't much reason why that wouldn't be allowed.
What boggles the mind is that the topic is about a monopoly on Apple's own products. Why not sue Toyota because they've got a monopoly on Camry parts while we're at it?
I'm replying to a troll here but anyway, no they don't have such a monopoly, there are plenty of major players selling/"renting" music online (I'm not sure of the actual percentages though) and the iPod/iPhone doesn't even have 50% of the market for potable media players.
Greylisting is to SMTP as NAT is to IPv4
We'll soon be able to order iNexus-6 female companions?
Unfortunately for Apple, Android's marketplace hardly sell any Apps. (It seems from all the arguments made here anyway).
yeah but.... Blackberry has the largest market share of all (40+ %), only supports a Java SDK, and doesn't run Flash either. No-one gives a damn about that, but when Apple does the same with their product, everyone's suddenly kicking and screaming.
I doubt there's any anti-trust case to answer, they're not even the majority, and Google is doing better than them in growth.
I suppose Apple's problem was allowing a non C-family SDK in the first place and allowing any code to run at all. Silly Apple, should have locked it down to a special API right from the start and prevented all this hullabaloo.
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...
So what happens if Adobe CS5 which can take a flash app and emit objective-C for it meets those performance and stability guidelines?
The primary reason Apple has this rule is to prevent flash apps from being so easily ported to its platform.
Other places sell music online, in either MP3 or AAC format.
All decent portable media players can play MP3 and AAC files.
Where's the de-facto monopoly here? Music files aren't DRM'ed anymore.
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.
Example no. 1: "I'm a user, I want to see that website... oh wait, but that's in Flash, I can't see it on my iPhone, because uncle Steve said no." Example no. 2: "I run a website, I'd like to make it compatible with smartphones... but wait, it doesn't work on iPhones: that's a pity, I'm loosing a lot of users... damn it's got a lot of Flash in it, I should rewrite it entirely." All this with the iPhone version of Flash that is ready, but uncle Steve said "no". Does it smell of unfair business practice? Yes, it does.
1. They look into it, but decide not to pursue legal action against Apple. I'd say there's a moderately good chance that they decide it's not worth bringing suit against Apple. Good for Apple, questionable for users, bad for third party developers. Nothing really changes.
2. They look into it, bring legal action against Apple and Apple is forced to change their policy. Bad for Apple, questionable for users, good for third party developers.
3. They look into it, threaten suit against Apple, and Apple meets them halfway by allowing third party apps to be installed outside of the App Store, possibly by downloading them to your computer and syncing them from there. Probably the solution where everyone is at least somewhat satisfied. Apple keeps control of their store, third party developers still have a way to get their software on the phone, and users can install anything they want without requiring Apple's permission.
I say questionable in cases 1 and 2 because it may reduce the overall quality of software on the App Store resulting in more choices for users and a larger selection of apps, but the possibility of getting craptacular cross-platform apps the run into the lowest common denominator issue Steve mentioned in his post. It really depends on your overall philosophy.
Comment removed based on user account deletion
>Apple's policy does not (as TFA claims) require the developer to use only Apple's programming tools. It just requires the developer to use C, ObjC, or C++. There's no requirement that those tools originate from Apple. Can you author an iPhone app using a Windows PC? Is there a PC software program that will allow me to write an app in Objective C?
but you can only install os x on mac hardware
So, when does the Sony PS3 inquiry start? Right after Adobe complains?
Re:May I be the first to say (Score:-1, Redundant)
by Anonymous Coward writes: on Mon May 03, '10 04:42 PM (#32077724)
Mod self redundant. NOW!
FTFY.
God invented whiskey so the Irish would not rule the world.
While they are at it, I hope that they define new rules for general purpose computers to be programmable without restrictions. This would be much better for the market (think of unification of standards; also look at how much open-source has benefited us all). Further, it would also be environmentally beneficial, since we wouldn't be forced into buying several (artificially restricted) devices where one would suffice.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
You can kiss stability and reliability good bye.
Besides, its their device, don't like it develop for another phone. No one is *forcing* you to support apple.. Once they are the ONLY game in town, we can have this discussion again.
---- Booth was a patriot ----
They should also look into why Apple refuses to allow people to isntall OSX on their "non Apple PCs"
Same damn hardware but you cant run OSX unless you buy your PC hardware from Apple.
Microsoft on the other hand, sells an OS that runs on the very same PC hardware that makes up the MAC.... except they dont restrict its usage to only "Microsoft sold PCs"
I dont know how Apple got away with that for years.
Also add:
iTunes, Ipods and Iphones that dont support open formats.
Where's the non-Nintendo-approved dev kit for the Wii and Nintendo DSi? The non-Sony-approved dev kit for the PS3 and PSP? We're not talking about tinkering in your shop here, we're talking about commercial software publishing.
Go and make one if you have a need for it, Sony and Nintendo will not stop you like Apple will.
No third party APIs are allowed. I.e. the terms and conditions are against distribution of wrappers for scripting languages like Ruby or Python. At this point Adobe is probably the last big company still willing to accept the risks associated with contributing to Apple software.
I don't think the problem is "supporting all languages", the Objective-C / C++ / Javascript IMHO isn't action worthy.
The problem is that the code must ORIGINALLY be written in those languages, no tool generating the code allowed.
So why should it be action-worthy that they do not allow generated code?
A debate on the technical merits of that restriction seems reasonable to me, because there are a couple of strong pros and cons. I do not see at all why is this should be a legal matter.
People on slashdot tend to forget that we're talking about mobile platforms here, including mobile phones. That means that the battery usage must be restricted, applications should not be allowed unrestricted access to communication functions, in particular phone functions, and there are also important user-interface problems that must be solved. Some restrictions on the software that can run on these things are therefore eminently reasonable. Thus, if Apple considers it wise to disallow generated code as part of these restrictions, I would be very surprised if a judge would object to that. Why would s/he be in a position to second-guess Apple in this?
Aren't they also pretty restrictive too? Or do they just get a free pass around here?
---- Booth was a patriot ----
(Incidentally, it's also exactly what Microsoft forces you to do if you want to submit an app to the XBox 360 "indie games market". You have to use XNA, period, no exceptions, it's not even open for negotiation.)
That's totally different because firstly XNA is not a language and secondly the indie game marketplace is not the only way to legitimately get your game out on the console. You can use any language you want to develop for the xbox and use any additional libraries, tools, interpreters, etc... which makes cross-platform development easy, just look at all the cross-platform engines and games. On the iphone you cannot do this, the only way to legitimately get apps onto the iphone is through that app store and in using that you may not use any other language, interpreters, intermediate layers, etc...
I might be ignorant, but it seems to me there is a big difference between only supporting a particular environment and writing it into your terms of use that only a particular environment can be used.
I'm quite ok if my dishwasher says I should only use a certain brand of dishwashing detergent. However having them come and turn it off or sue me if I put in another brand is a whole step worse.
> 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.
Research a bit further than your own hopes and beliefs. Apple is a lot more open to small developers than Sony or Nintendo are.
How so?
Any of these technical requirements would reject apps written under other frameworks without saying "must be written in C / C++ or Objective C".
Even if Adobe wasn't giving up on the flash to iDevice, consider how far behind they will fall when firmware 4.0 is released. How long would it take Adobe to release an update that handles background services, voip and other new features?
This really is the crux of Apple's restriction. If Adobe (or any other iDevice packager other than Xcode) became the dominant platform, it would be up to that company to add in new features that the previous firmware released. Apple has been burned by Adobe before and doesn't want to be beholden to anyone to have support for their firmware now. This is also likely why HP bought Palm - so that HP wouldn't have to wait for Microsoft or Google to do something new and game changing.
Don't Microsoft, Sony and Nintendo do the same things on their game platforms?
They have even tighter control over their platforms, don't they?
The iPhone OS is pretty new so it's hard to know what will be found, if investigated. But if based on recent legal precedents, change won't come from US legal action.
At the end of 2008, Apple's Macintosh "walled garden" practices were brought before Judge William Alsup in the Apple vs Psystar case. Psystar filed counterclaims insisting that Apple's EULA was invalid because it was "tying" Mac OS X to Apple hardware. They were basically laughed out of court.
You can read Groklaw's analysis of that ruling, but my armchair lawyering just can't see too much difference between the OS X "walled garden" and the iPhone OS "walled garden" legally.
There are lines that you cannot legally cross, and Apple very well may have done so.
They do it indiscriminately; who cares? They even have their own iPolice to raid into blogger's homes.
Now awaiting for the john gruber wannabe acolyte zombies (see above) to mod me
Did you really just say "stability guidelines that can only be met by.. C++ code"
????
Please leave the programming talk to programmers.
"His name was James Damore."
that's why people are comparing Apple's current CEO with Howard Hughes.
It's more like Bob diddled a kid, and the case is weak, but MGBMorden hopes that Bob will be found guilty and not get off because of mental handicap.
Put identity in the browser.
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."
All of that sounds to me like "Internet Explorer is built too deeply into the operating system to be removed. It cannot be replaced because too many critical systems services rely on it."
They don't want anybody developing applications without them being under their thumb.
You've got it exactly backwards. They don't want to be under anyone else's thumb. For example, Adobe's. If Apple allows Flash tools to compile apps for the iPhone, then all future iPhone updates will have to take into account Adobe's Flash tools.
Yes, they can use that control to give a good user experience (see all the quality iPhone fart software, or all that other great stuff), but they want it for purely financial reasons.
Apple doesn't make any significant money from the sales of apps. They make their money from the sales of hardware. So, once again, you have it completely backwards. They want the provide the best user experience, because that means more hardware sales. Apps are a feature of the iPhone, not the other way around where the iPhone is merely a vehicle to sell apps.
I don't think Nintendo puts clauses in their contracts that try and prevent cross-platform development.
That might very well be possible. A bonus is that the Android Market wouldn't disallow such apps.
Put identity in the browser.
Your second point stands. But your first does not -- XNA isn't the equivalent of Objective-C, it's the equivalent of Xcode. I have never heard of anyone succeeding in using any language with XNA other than C#. As far as I'm aware, every single "indie game" (they used to be called "community games") is written in C#.
http://en.wikipedia.org/wiki/Microsoft_XNA
But yeah. There are other mechanisms for getting stuff on to the XBox. All of them are considerably more expensive than $99 a year (which is what XNA creator's club membership costs), but they do indeed give you considerably more freedom with regard to the technologies you use.
I would like to see Apple do the same thing, where the "baseline" dev kit works the way today's does, and there's something else available to people with Very Deep Pockets who absolutely insist on more freedom. On top of that, I'd like them to add another tier at the hobbyist end of development, with something along the lines of HyperCard, that would be seen as unsuitable for "mass market" applications, but would meet the needs of the folks who just wanted to tinker with the device for their own use.
if they make the same prohibitions about *how* you should code, then yes
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.)
Agreed. If Apple qualifies for antitrust investigations, so do lots of other companies.
Surprisingly, I'm not too concerned about the anti-trust outcome in this case. Whatever happens, Apple will still make great products and it won't affect me as an end user.
I'm a web developer and I'm really interested in making iPhone/iPad apps using Appcelerator Titanium. If it could be guaranteed that Titanium apps won't be rejected (on the basis of being a 3rd party dev tool), that sure would be nice.
When Apple writes an Android app to host iPhone apps on Android phones, and somehow the manufacturers prevent it, bring your fanboi ass back in here. Otherwise, go away.
If you develop for xbox, you must use the Microsoft tool chain; if you develop for the playstation 3, you must use the Sony tool chain.
There's nothing new here, save a bit of Apple-hater rambling, and government cluelessness.
It's Linux, damnit! Pay no attention to renaming attempts by self-aggrandizing blowhards.
Really? Odd thing to do with less than a majority share of said market.
cat
Oh fuck that, I want my Stallman-inscribed GNU/iPhone, the version with emacs as the home screen.
cat
Are you going to argue that a fool can speak without removing all doubt?
cat
They came second, so they should be required to support the tools of those that came first. Because the bottom line is, some notable exceptions aside, all carriers and phones prior to the iPhone had some kind of similar restriction for developers, like forcing you to use the Java interpreter present in the phone.
cat
The only legitimate way to get the the SDK for a Nintendo console is to get it straight from Nintendo - requiring you to have a lot of money and preferably a signed contract with a large game publisher. This is the case with all of the major game consoles, with the possible exception of the Xbox 360 and the XNA framework. Tell me how that isn't tighter control.
Controlling the SDK that way ensures that the hardware manufacturers will get their cut of the profits for any game that's released for their console. Meanwhile, you want to whine that Apple is restricting their toolchain while they're giving the SDK away FOR FREE, to private citizens, with only a couple hundred bucks and an "approval process" between them and millions of customers? I find your lack of perspective disturbing.
Your second point stands. But your first does not -- XNA isn't the equivalent of Objective-C, it's the equivalent of Xcode. I have never heard of anyone succeeding in using any language with XNA other than C#.
I didn't say or imply that XNA was the equivalent of Obj-C. XNA is an application framework (read your own link), it is NOT the equivalent of XCode, you are probably thinking of XNA Game Studio (the plugin for VS), which is not the same thing.
I have never heard of anyone succeeding in using any language with XNA other than C#. As far as I'm aware, every single "indie game" (they used to be called "community games") is written in C#.
I don't know specifically which games are written in other languages but microsoft themselves are certainly supporting other languages. There is absolutely no reason, technical or otherwise, that you can't use any .Net language to write games using XNA, hell you can even use F#, Don Syme (of Microsoft Research) wrote a whole tutorial on using F# to develop games for the XBox360 in GSE, im sure you'll find it if you google it. What makes you so convinced that every single indie games is developed in C#? Is there any evidence to back that?
Yes, the righteous paranoia is getting thick. Otoh, I am impressed that posters are attacking Apple rather than the typical ad hominem against Steve Jobs (as though he were the only employee), a la The Register, etc.
I don't know about Sony, but with the Xbox developer program you can use whatever you want.
my understanding is that apple gets 30% of all sales, and dont even have to give that back when refunds are given (for whatever reason). This all for some piddly amount of bandwidth for the store and some clowns clicking 'approve' or 'deny' on new submissions
the app store might not be apple's mainstay, but it is essentially free money, why would they not defend that? (and keep in mind that with the ipad they added one more 'free money' generating device to the line-up, with generally higher app prices)
People, what a bunch of bastards
Their systems are far more exclusive than Apple.
You must use their dev tools, and hardware to develop games.
And not just anyone is allowed to develop for them.
Until you can square that, I don't think
Apple is doing anything extraordinary with the iProducts...
tl;dr
If I were King of the World, I would ban the practice of any retail pricing ending in '.99'. Round up, you mothers, or up against the wall.
First, full disclosure. I've paid my dues to get an iPhone OS developer license, and I'm actively writing and releasing apps for these devices.
However, I don't think the focus should be on the fact that Apple says you have to write your code in a specific language. The focus should be on the mechanism by which they can enforce that; their monopolistic App Store. The fact that the only way to get applications onto the device is to pay Apple's fee seems highly suspect to me. I understand the desire to keep a level of quality control on the code that's executing on these machines, and in principle I applaud it. The way they've gone about it is horrible, though.
People have had years now to recognize that the hardware and underlying OS are sound. I think it's time to just open the flood gates, and let developers release whatever code they want. Customers will quickly learn which companies produce good software that doesn't destabilize or crash their device, and which companies write nothing but garbage that causes their shiny little slab of magic to become a shiny little slab of useless components.
You've got it exactly backwards. They don't want to be under anyone else's thumb. For example, Adobe's. If Apple allows Flash tools to compile apps for the iPhone, then all future iPhone updates will have to take into account Adobe's Flash tools.
Why not? I mean, saying "OK, Adobe has a flash application, it is like any other application, accessing the API, if the API changes, Adobe changes their app. Or they can compile it without needing the API, then, when hardware changes, Adobe must make the modifications. Where's the problem?
And if apps were a feature to sell more hardware, why not allowing third party? And market it as a feature? It would sell even more hardware!
If I'm wrong, please correct me ; learning is better than being right.
The argument is on THAT level. Don't like it, buy another brand of car...
Apple wins, DOJ looks dumb.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
On reflection, you're right, I was being sloppy and imprecise with a point that was tangential to the main topic I was discussing. My apologies.
(But I will point out, you are wrong to accuse me of being "so convinced" that every single indie game is developed in C# -- I explicitly wrote "as far as I'm aware", because I was perfectly aware that my information could have been incomplete. Thank you for the very specific pointer for the IronPython example. I have been keeping an eye on XNA for a few years now, contemplating whether or not to "dive in", and that's the first reference I've seen to anything other than C#.)
So, here's the situation as I now understand it, with more precision:
If you just say "XNA", you're being imprecise. There are XNA frameworks. There are asset management tools. There's "XNA Game Studio". There is (was?) "XNA Creator's Club".
It's built on the .Net CLR. That is, at its core there's a VM, similar to the JVM, the "common language runtime" one that .Net uses. The frameworks are available via CLR -- if you want to use them, you need a language that "participates" in the CLR fully, seeing the objects and methods that are available in it.
The frameworks are analogous to the iPhone OS frameworks (Cocoa Touch, Core Foundation, Core Data, et cetera). The "Game Studio" is analogous to Xcode.
Here's the thing that's important to get: the "niche" occupied by the CLR in XNA is occupied by the Objective-C runtime in the iPhone OS. If you use most languages other than Objective-C, you're doing the equivalent of using a language that can't participate fully in the CLR, that can't see objects in it, that can't directly invoke methods on the frameworks exposed through it.
I had thought that C# was the only language in actual real-world use by XNA hobbyists. I will say it's certainly the one I see being discussed the most, documented the most -- heck, the "getting started" instructions I've seen all discuss using "Visual C# 2008 Express". In all the discussions about XNA I've seen or participated in, C# was assumed. But other languages aren't explicitly forbidden, and apparently they do get some use.
That is in fact the situation I'd like to see with Apple, if you're careful to keep the analogy intact. You can use any .Net-ish CLR-ish language with XNA. You should be able to use any non-interpreted language that uses the Objective-C runtime as its runtime for iPhone development.
Now, this isn't in fact a large set of languages right now. The reason C gets included is because Objective-C is pretty much a superset of C. The reason C++ gets included is simply because how trivial it is to link between C and C++. I do not recommend doing much iPhone development in C++ -- the OO systems are not compatible. This is not a way to avoid Objective-C. You end up using both, in order to get any work done, and the objects that the frameworks see and interface with are going to be the Objective-C ones. But you can use C++ for your "model" objects if you're careful, and this is actually valuable because of C++-based computational libraries/frameworks that exist out there.
(This is why things that map between a language's objects and C++ objects would not be sufficient. You're not getting the required Objective-C-like behaviors that way. You don't even get them in C++ itself, and Apple has been mixing C++ and Objective-C for many years now!)
Beyond those, MacRuby is the most obvious one. It actually compiles Ruby, and uses the Objective-C runtime and garbage collector to get its job done. It's also by Apple. There's no reason it shouldn't be supported... except that it's only up to version 0.6 right now.
http://www.macruby.org/
The limited information I have regarding MonoTouch leads me to believe something similar i
Just to follow up: I know some people are baffled that when I discuss competition in the upcoming touchscreen/tablet space, I do mention WP7 in the same breath as iPhone and Android. That's because if Microsoft is smart, they actually have a chance with WP7. This could be their "3.11 for Workgroups" in the handheld/tablet space.
I am sold on the notion that for devices like these targeted at "regular people", you can't just let anyone load any old code on them. You've got to keep apps from interfering with each other, you've got to keep apps sufficiently stable, you've got to keep apps sufficiently well-behaved, and you've got to make sure the user interaction models aren't too surprising (ie. they follow platform UI guidelines). I really to buy that that's necessary for these devices.
And I might be wrong, and I recognize that, and that's why I pay so much attention to Android. Some Android devices are wide open, and others aren't. It'll be interesting to watch.
The iPhone OS is about as locked up as you can get, and it's working.
WP7... WP7 uses XNA (or Silverlight) for app development. Programming on this sort of device has a huge amount in common with programming for a gaming console. And Microsoft's OS for this sort of device uses the same dev environment as the "indie games" marketplace for the XB360.
Now, I have not heard anyone state that they'll be using the same peer-review process for WP7 apps that they use for XNA "indie games". But it's certainly a way to get a lot of the benefits of a closed review process while avoiding some of the most egregious problems, isn't it? Microsoft is already very well positioned to do that if they want to. And if they do it, they could hit the "sweet spot" for openness, with just enough restriction to make the platform really work for end-users coupled with just enough openness to truly unshackle developers. It could be quite exciting to watch.
(Of course, the thing that splashes cold water on my face in all of this is, watching the demos of the WP7 user interface makes my skin crawl. Can't stand it. But I'm willing to allow for the possibility that that's just because I'm not used to it yet, and I'm willing -- in fact eager -- to give it a chance to "wow" me. I very much look forward to 3-way competition between Android, iPhone, and WP7 in the marketplace. Exciting times should be coming up within the next 18 months I hope to have at least one device in each ecosystem and one app available for each within that time frame, so I can really watch.)
The only problem is that there likely would have to be some tweaking done to make sure that the app complies with Android HIG, that it performs well on Android, and basically that it behaves like a good Android citizen. Of course, a bunch developers would probably just convert, make sure it runs once, and then upload, meaning we get a bunch of half assed ports on Android now.
Why should Apple second guess the user? If someone wants to install a battery hogging app, let them.
And good generated code can still beat a lot of human written code, so that's not a good argument.
Why should Apple second guess the user? If someone wants to install a battery hogging app, let them.
Apple has decided not to allow that, mainly to avoid degrading the user experience of the entire phone/ipad/ipod. You may disagree with that trade-off, but it is certainly a rational design decision.
And good generated code can still beat a lot of human written code, so that's not a good argument.
I think you're being very optimistic here. Perhaps in some limited circumstances it is easy to generate readable code, but automatically translating one high-level programming language to another one is hard, and generating readable code in the process is even harder.
In any case, my argument stands: Apple's restrictions are rational on technical grounds. Therefore I would be very surprised if a judge would want to second-guess Apple in this.
Time machine showing the world how one makes backups user friendly was definitely good. I'd say the old PC Apple is lawful neutral while the new iPhone Apple is clearly lawful evil.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
"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.
Why would typing 'make' enable an application to multitask?
It is clear to me that you have NO FUCKING IDEA what you are talking about.
Being able to switch from Arm to x86 or any other CPU architecture by doing little more than typing "make is also important.
umm, and a Flash to C compiler wouldn't allow switching between an x86 and ARM compiler? Really?
It is clear to me that you have NO FUCKING IDEA what you are talking about.
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.)
It is clear to me that you have NO FUCKING IDEA what you are talking about.
You made the whole thing up, based entirely on complete and thorough stupidity.
IF YOU DONT KNOW WHAT YOU ARE TALKING ABOUT, DONT ACT LIKE YOU KNOW.
I can translate your entire post here: "I am completely wrong about all these things, hell I don't even know what half these words really mean, but they justify the argument that Apple has technical reasons"
"His name was James Damore."
Sony, Nintendo, and Microsoft consoles...
Develop much for them? Didn't think so.
Please recall the old saw, "Nothing crashes like a Macintosh!"
No one (except Apple) bitched about the crappy developers that undermined MacOS APIs by calling behind them. Everyone bitched about the computer crashing. It didn't hurt software sales.... it hurt Apple's sales.
Mr. Jobs tried it your way the first time. He is clearly not going to play THAT game again.
On reflection, you're right, I was being sloppy and imprecise with a point that was tangential to the main topic I was discussing. My apologies.
(But I will point out, you are wrong to accuse me of being "so convinced" that every single indie game is developed in C# -- I explicitly wrote "as far as I'm aware", because I was perfectly aware that my information could have been incomplete. Thank you for the very specific pointer for the IronPython example. I have been keeping an eye on XNA for a few years now, contemplating whether or not to "dive in", and that's the first reference I've seen to anything other than C#.)
Fair enough ;) And yes I think you make a lot of valid points there. In all the comparison of the iphone platform to the xbox platform does indeed equate to an 'it's complicated'. The ability to connect to any web service makes more sense on the iphone than on the xbox (though of course some things would be nice there as well) which i guess is why there isn't so much of a furor over that as there is with the iphone's new section 3.3.1. In both cases they are very profitable and popular platforms that wouldn't lose any significant ground by being a little more open and accessible for developers to really make the most of them.
I had thought that C# was the only language in actual real-world use by XNA hobbyists. I will say it's certainly the one I see being discussed the most, documented the most -- heck, the "getting started" instructions I've seen all discuss using "Visual C# 2008 Express". In all the discussions about XNA I've seen or participated in, C# was assumed. But other languages aren't explicitly forbidden, and apparently they do get some use.
I guess it's easier to teach and support one language explicitly (obviously the most popular supported one) when you are writing the sorts of tutorials that they are - real beginner ones - and let the more experienced developers branch out to other languages on their own.
What does readable have to do with it? Executes efficiently is what you want.
And what's interesting with this restriction is that this is how gcc, the native toolchain Apple uses works. It compiles to an intermediate language before it gets converted to assembly.
Well. You're not very imaginitive, are you?
If you want one example in which doing the equivalent of typing "make" would allow your app to multitask, just go back to MacOS around the time of classic MacOS 6 or so. The multitasking was cooperative, and needed to be supported by each application in order to work properly. If you recompiled your program, the libraries and linkage and such could have the hooks all inserted automatically, enabling much better multitasking support without the programmer changing a single line of code, simply by recompiling and re-linking the application.
Any time you have a multitasking system that's not just a simplistic pure preemptive one, you can improve multitasking by using APIs and system calls that cooperate with the multitasking implementation (even if it's not "cooperative" mulltitasking). A bunch can be accomplished by changing the implementation of a system call. More can be accomplished by changing the code in a shared library. (But a lot of iPhone apps use static linking for a lot of stuff, instead of dynamic linking, as a way to keep apps in their sandboxes.) And even more can be done if the frameworks in use are very standard and are used in standard ways, so calls to new code can be transparently added without changing a line of source code. Exactly as was done when multitasking was added to classic MacOS, and the cooperating functions were inserted into the standard event-handling loop.
You know, the same sort of thing does occur under Unix. Think about I/O libraries. If you're waiting on input from a device (like a serial port), you can poll the thing in a tight loop, you can poll the thing with a "sleep" inside the loop, and you can use a system call that blocks on device I/O. I've seen all three used under Unix, especially back in the 1980s. And sometimes the behavior was chosen within a framework (or "library"), instead of the author's source code. And in those cases, you could get a program that multitasked much more efficiently by simply re-linking to a new version of the library (which could require recompiling, even if you didn't statically link, depending on what changed in the associated header files).
Do you remember those days? Remember writing Unix code that talked with serial ports (terminal software, fax software) that had to run under Ultrix, SunOS, AOS, BSD, and SysV, and using compatibility libraries to make it work? Remember how early versions of the compiled programs could eat astronomical amounts of CPU? Remember how updating the compatibility libraries and typing "make" could cause resource consumption to drop through the floor? Do you remember? Because I do, as my startup company was based around doing pseudo-realtime programming of Unix serial ports.
So. This is all speaking in general terms about how "typing make" actually could enable multitasking in an app without changing a single line of its source code. I can't speak in iPhone-specific terms in this forum for a few months yet -- nobody can (legally).
If you want one example in which doing the equivalent of typing "make" would allow your app to multitask, just go back to MacOS around the time of classic MacOS 6 or so. The multitasking was cooperative, and needed to be supported by each application in order to work properly. If you recompiled your program, the libraries and linkage and such could have the hooks all inserted automatically, enabling much better multitasking support without the programmer changing a single line of code, simply by recompiling and re-linking the application.
Ahem, not too bright, are ya? In coorperative multitasking, yielding only within library calls isnt good enough and will almost certainly create an unresponsive craptastic sytemm. Yielding is done specifically during long processing, not within UI calls and the like.
You have just described why Apple should NOT be doing what its doing, that in fact "just rebuilding" should be disallowed.
Any time you have a multitasking system that's not just a simplistic pure preemptive one, you can improve multitasking by using APIs and system calls that cooperate with the multitasking implementation (even if it's not "cooperative" mulltitasking).
Modifications to API and system calls do not require a recompile unless the interface to them changes, and if the interface to them changes, you can't simply recompile.
It is clear to me that you have no fucking idea what you are talking about.
"His name was James Damore."
Modifications to API and system calls do not require a recompile unless the interface to them changes, and if the interface to them changes, you can't simply recompile.
Never used a library that changed the linked interfaces without requiring a change to the source code, by the mechanism of macros in the header files, have you?
Also, did you realize that to relink to a static library, you have to do "the equivalent of typing make" even if none of your code recompiles?
You're the one who has no fucking idea what you're talking about. Thank you for proving it to everyone who's been following along! Bored now.
The iPhone API's arent static linked. Thats not how these devices are designed. Otherwise a firmware update would break every single application the user has.
Didn't fucking know that? did ya, moron?
That can't change the interfaces.. you fucking idiot.
"His name was James Damore."
Wow, son, it sure is your week to make aggressive assertions that are so incomplete as to become inaccurate, isn't it?
Tell you what. You seem to be going on and on about what I do or don't know about iPhone programming. This isn't the place to continue that discussion. There's another place we could continue this, where I'd have the freedom to discuss the exact behaviors of the exact APIs that deal with multitasking. So how about you join me over there, and we can pick this back up? Here's the URL:
https://devforums.apple.com/community/iphone
Here is how to find me over there:
https://devforums.apple.com/people/dfjdejulio
If you want a starting point for that discussion, here's the source code that I've been sharing with other registered iPhone developers in order to probe the capabilities of various devices running various operating systems. Go into the "Sources" folder and grab the "Runner" application:
http://public.me.com/dd26
And here's the thread in which the discussion of that source code (and its output) has been occurring:
https://devforums.apple.com/message/198165
I don't expect you'll follow me over there. I expect you'll instead stick to your usual pattern of ignoring 90% of what I wrote, latching on to some concept that doesn't match what's in your head, stamping your feet, getting red in the face, and yelling something incomplete and barely-coherent. In which case this is the last you'll hear from me. But, feel free to prove me wrong!
And do try to calm down a bit, for your own good. Your anger and misplaced contempt really do make you come across as even more stupid than your inaccurate assertions would on their own, and they paint you into a corner that makes it difficult for you to admit the cases in which even you have been able to figure out that you're wrong (which is, I suppose, why you just let those particular subjects drop). If you don't believe that, go try and find a neutral third party and ask them to read this whole back-and-forth, and see what they think.
Hah not if you actually plan on signing your code and you know... publishing it.
Ogre Wedding Planners llc.
Not quite... but an immersive technology can trick your mind into an experience that is, from the users' perspectives, sensually impossible to differentiate from the real thing. We call it virtual reality now, but that term will eventually only be used to describe the attempts near the turn of the millennium to create an immersive visual/audio experience. It's missing a subtle but essential quality that is apparent because VR users never lose themselves in the experience the way, say, a subject looses themselves in a sensory deprivation chamber. The closest thing I can compare it to is a STNG -style holodeck... except that it's the size of a funky pair of glasses. There will be many Matricies... but no Zion.
The Admin and the Engineer