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
I hope they roast Apple's fruity little ass with the biggest legal flamethrower they have stuck aside.
Maybe something will come of this, maybe it won't, but here's to hoping.
At least we can finally get an answer one way or another for the fanbois who keep saying "It's their platform, they can do what they want." - because in reality, that's not the case. There are lines that you cannot legally cross, and Apple very well may have done so.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
But inquire away! They've been uppity lately.
You can't take the sky from me...
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.
Which other phone brand in the market supports iphone apps? Why the fuck should apple support other platforms then? If apple is supposed to support all languages, this rule must be imposed on all manufacturers.
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.
At the heart of the matter, it's Apple saying if you want the most exposure to the largest mobile application market ($$$), then you will limit what you program with to make it more difficult (potentially lost time and money) to port the application to non Apple devices.
merger to your anti-trust INQUIRY.
Yours In Apsheronsk,
Kilgore Trout
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...
The hype surrounding all things Apple is getting to weird new heights...
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 is the new Microsoft, after all.
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
Exactly! That's what's so insidious about Apple! They are the only company that makes iPhones. If you want an iPhone, you HAVE to go to Apple! They won't let Microsoft or Google make iPhones so they hold all the cards! It's a monopoly!
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.
Are you going to argue that Apple doesn't have a de-facto monopoly in online music sales and in portable media players? Really?
"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...
Not ALL antitrust laws are anti monopoly, although the vast majority are. this is still not even an inquiry yet, and inquiries against non monopolies for anti competitive practices really aren't that uncommon.
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 ||
Apple has it. They have a legal monopoly on the market of mobile apps.
They do? When did the Android Market close down?
You don't have to have a lack of alternatives to have a monopoly market share (like fx Windows vs Linux and Mac), and Apple have something like 85-90% of the app market right now. That said, I don't agree with the antitrust involvment in any of these recent tech cases, including Windows N and IE ballot screen. They are not necessary, you can clearly see alternatives succeding (though just not complaint filer Opera in case of browsers).
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.
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
Doing a quick search I found that Apple had 25% of the smartphone market in December 2009. How can you have an antitrust investigation against a company that doesn't have anything close to a monopoly?
I'm no Apple fanboy (in fact I've never owned a single Apple product) so I'm not saying this based on some sort of bias. It just seems absurd to me.
So what differentiates this case from closed console gaming platforms (PS3, Wii, XBox 360), which also have substantial restrictions on development? I can see it now: "waaah! I can't write my XBox 360 game in Flash! waah!" <snark>Will we then see the DOJ going after Microsoft, Nintendo, and Sony?</snark>
The problem I see is that Apple is telling developers that they're prohibited from making agreements with a third party. All iPhone apps must be compiled from Objective-C/C++? Fine. All iPhone apps must be written in Objective-C/C++? Now Apple is placing restrictions on a relationship that is 100% external to their relationship with the developer. That can't be conscionable to have in a contract. The only possible goal such a restriction could have is denying the third party (such as Adobe) legitimate business. That's the part that smells like monopoly behavior to me.
American lawyer: I understand you guys require something called "metric" tools for your "metric" bolts. That's a monopoly that needs to be stopped!
Seriously though, sometimes it's not about monopoly but about controlling your system from A to Z. 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.
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
Unfortunately for Apple, Android's marketplace hardly sell any Apps. (It seems from all the arguments made here anyway).
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?
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.
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.
> 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.
But the purpose of these restrictions is to force iPhone development to be exclusive or nearly so. Their technical arguments are mostly bogus (they have a few points, but those points have *nothing* to do with the reasons Apple is doing this). The whole reason they're doing this is to keep the wall up around their walled garden.
They don't want anybody developing applications without them being under their thumb. So no Flash and no emulators, otherwise people could make applications that weren't under Apple's control. 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.
A hipster's call to arms. Or whining, as the case may be.
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...
> 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.
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.
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."
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."
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.
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.)
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.
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.
They're looking into the development tools allowed on one type of smart phone, and Comcast is allowed to get away with their shenanigans on a day-to-day basis? I watch my legitimate torrents die on the vine because Comcast doesn't like the content, then on the TV side, I have to rescan my DTV channels every month to figure out if CNN is on digital channel 86-112 or 25-8 or whatever... because Comcast doesn't want to publish their channel mappings since that would get less box rentals into homes and less pay per view orders.
As you can see from my sig, the money government spends is annoying. What they choose to spend it on is devastating.
Why are you letting these clowns ruin our country?
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.
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.)
I was going to say something along these lines, too. Most posters don't seem to have bothered to find out what an FTC "inquiry" is, and how it differs from an FTC INVESTIGATION. I think they have them confused... The inquiry is simply a response to a party claiming injury - they don't have to really provide PROOF - or the FTC responding to news reports. As a RESULT of an inquiry, the FTC may choose to INVESTIGATE - THAT is when it's serious, which posters here seem to think it already is... It's hard to see how it would get to that point, quite honestly.
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.
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).
Very true. Insightful comments. How you aren't rated up to a 5 shows that most people won't read a long post.
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.