iPhone code ban facing antitrust inquiry? The US Department of Justice and Federal Trade Commission are exploring an antitrust inquiry into Apple's ban on iPhone code translation, according to a report citing a "person familiar with the matter." The New York Post reports that the DoJ and FTC are "locked in negotiations" over which will investigate a recent change to …
Is there something in RIM's or Palm's licenses that prohibit you from writing in another language or writing your own compiler for another language to run on Blackberry or Pre hardware?
There's a difference between "we only support X development" vs. "Thou shall not develop in anything but X".
...considering that coding in anything else is quite likely to not work so hot (at least not without a ton of shims, home-built call emulations, or outright hacks)? Probably.
That's why the maker says they'll only support certain languages in the first place... they already know it'll get messy in a hurry if you use something else.
This in turn could easily mean a bad customer experience, which reflects more on them (and the carrier) than on you, even if world+dog knew that your app was coded in Ada and using a homemade runtime environment lashed together in .NET just to run it. (or pick yer own improbable-but-somehow-possible combination).
Mind that on a 'real' computer this is not really a big deal, since you can almost always make it up in CPU cycles, runtime environments, and/or extra RAM demands, and if all else fails, Moore's Law can (eventually) save you. Mobile phones OTOH work a bit different - mainly because you don't have a lot of room to play in. CPU, RAM, storage... you simply don't get much of those (yes, a mobile phone can store, oh hell, a multi-gigabyte app if you want it to, but your actual executable bits can only be so big before you run out of space - see also Android's app storage limits, and the fact that your app has to share that same space with everyone else's apps).
To top that off, the desktop (and especially server) user already knows and expects that apps will take a bit of time to warm up and get ready... mobile phone users OTOH want their app up, running and ready before their finger even relaxes pressure on the touchscreen.
Long story short, if you use anything other than the officially supported/blessed? You either get extremely lucky and it works, or you end up with something that is bloated beyond belief and will make life hard on the user, maker, carrier, and (eventually) you. Either way, there's a good chance that it will likely break come the next OS update/refresh anyway.
Where's the anti-trust case against the Nintendo Wii because you can only code using their dev kit and by submitting your game to Nintendo who then take a royalty for every sale?
Same goes for Sony and Microsoft.
Since when did lack of portability = monopolistic practices?
That makes every computer system on the planet guilty, there are very few common APIs.
And yet a vast majority of companies manage to release the same game on all 3 of those platforms at the same time in multiple markets (except where there are agreements to have it on "console X" for "n months" first).
Yes you have to use their dev kit to do the compile and test, but they dont actually block you from using an intermediate language to do the heavy lifting to get the code from box A to box B.
Strange that anyone is bothering with the Wii; yes it is the major system in the console market, and possibly in a monopoly position, but given the turnover rate of the console market the lawsuit wou;d outlast the console. Nintendo has been fielding lawsuits left and right with the success of the Wii since launch day, and had they not been control freaks I'd fell more sympathy for them.
A better example of Monopolies being taken to task over their propitiatory OS development kit is the EU / Microsoft settlements that opened up the networking/security APIs and "documentation" for windows. You could argue that Apple want a closed platform for the iPhone/iPad platforms much as Microsoft had with the PC/Sever Windows platforms, but the speculative-fiction author, Charles Stross, has proposed a far more surprising and seemingly more likely game plan that Apple could be following.
Apple wants high margins and is willing to violate the law in order to maintain them.
Simple antitrust thinking. Or, perhaps trust thinking.
There is no question that if cross-platform applications turn out to be inferior for any reason they will suffer the consequences in the marketplace. But, Apple cares not one bit about consumers. Their objective is to block competitive alternatives by making it much more expensive to write to multiple platforms. Hoping all along that developers will focus exclusively on Apple products.
That is pure stupidity.
Such a policy may not violate antitrust laws just yet. But, it remains stupid.
Crapple doesn't want anything showing the age of its hardware. They want their followers to believe that it is all still the best stuff on the market, and they DO believe so. Jobs won't admit that there could have been more performance stuffed in there. Fanbois want to believe that their hadware is perfect and superior, no matter how old it is.
"Apple wants high margins and is willing to violate the law in order to maintain them."
No, Apple want to sustain sales and not have to refund thousands of customers when something developed in some half-baked development environment suddenly stops working after a firmware upgrade. That is all.
It's the "undocumented APIs" part that is relevant here...
I haven't read the article and don't know any of the facts, but I can say for sure that whatever Apple is doing or not doing or thinking of doing or doing later or doing to someone else is absolutely right and anyone who is doing something else or disagreeing is wrong. And that includes the rest of the world.
You can close comments on this now.
Seriously, why can't the market decide. This in America of all places - where the Invisible Hand rules. Apple can do whatever the hell they want, and everyone (should be) free to decide if they want to enter into a business relationship with them. Eventually some other company will give the people what they want.
It is Apple's business to run, at their own risk. These things should settle themselves out.
Freedom is a funny ol' thing, the problem with the invisible hand of the capital markets is that it's not a set of natural laws but a set of social understandings about the interaction of markets, the invisible hand is connected to the very visible arm of the government without which it wouldn't work.
Even Adam Smith saw monopoly prioritisation as a capitalist loop hole you could drive a planet through.
The market numbers for smart phones are an interesting game actually. They are measured not on the basis of actual units sold, but on the basis of information extracted from ads.
As a result they reflect the data contracts sold, not the actual smartphones in use. Blackberry has always been on all-you-can-eat data so it is not surprisingly very prominent. iPhone was also sold with reasonable data deals so it is not surprising to see it. Android is being sold with all-you-can-eat data deals so it is showing a disproportionately large share.
At the same time a lot of Symbian smartphones like N78, N95 and even E series were sold with consumer-oriented "loads of voice noone uses, but abissmally little data" contracts. There is probably more of these in the EU than Blackberry, Android, Palm and iPhone combined.
Note: I'm no apple fanboi, but here's an instance where the FTC is way off base.
Jobs isn't anti-competitive in his stance. He's purely making sure that his vision for the user experience is kept clean and correct.
This isn't anything new. Jobs has built his whole career around this from Apple, to NeXT, back to Apple. He has firmly believed in controlling the hardware and software that he uses when he creates his products.
Note that anyone can write and develop 'acceptable' applications if they adhere to the rules.
So the FTC has no legal grounds for an investigation. If you don't like Job's decision, write apps for the 'droid, Pre, Rim, Nokia markets.
Sorry, I wonder if we're in an election year for something?
"If you don't like Job's decision, write apps for the 'droid, Pre, Rim, Nokia markets."
Not only that, but you can write apps for the iPhone for free, there's nothing stopping you from downloading the SDK and writing any old app you wish, including a Flash player. What you are prevented from doing is selling that app through iTunes App Store, but that doesn't stop you from going to Cydia and selling on that marktplace.
This "investigation" will go nowhere.
...and then let's see what he is going to say.
Also, the EU could make him bundle Mono, Flash,QT , GTK nd a kind of Pascal with Xcode. Whenever you start the Xcode installer, a random IDE will pop up and ask whether you want to install it. I want to see Master Steve's face when he announces he's got to do that.
I guess he will then join the NRA and buy some tons of fertilizer and diesel....
Some operating systems and computer systems rely heavily on mains power.
Newer emerging hardware typified by being mobile portable devices tend to rely quite heavily on effective power management and that depends on effective use of APIs in the hardware/operating system.
It is a different environment where mains power and resource heavy versus battery power and resource optimisation.
But i somehow think that the reviewers will overlook that much to the detriment of mobile battery powered devices.
"Also, the EU could make him bundle Mono, Flash,QT , GTK nd a kind of Pascal with Xcode."
Adobe might have a thing to say about that! Flash is their baby and if anyone else wrote something that interfered with how rotten it is (or heaven forbid, wrote something better) then their legal team would be raking in cash in no time!
I like your Pascal suggestion though. Perfect for early 1990s computer science students.
"code written in C, C++, and Objective-C may compile and directly link against the Documented APIs"
If you don't compile and link against the DOCUMENTED APIs then you get in a horrible mess.
Ever tried running certain Amiga Workbench 1.3 games on Workbench 2.0? A lot of them don't work simply because the developers hit on some functions that weren't documented. Guess what happened next? Undocumented APIs were changed prior to becoming documented APIs in 2.0 and any software which tapped them suddenly stopped working.
Apple really don't want to get into a situation where they release an update and suddenly have a load of calls saying "application 'xxxxx' no longer works properly, can I get my money back?"... they've found a way to avoid that situation. Surely that is to be applauded?
Now that's a really old analogy, thankfully there are some of us around here who remember those days (I did tons of programming on the Amiga). I had 1.2 myself.
Amiga OS 2.0 was a lot more optimised and therefore it was often quicker to use the OS routines in 2.0. Of course there were some amazing programmers in those days, writing everything in assembler.
"Apple really don't want to get into a situation where they release an update and suddenly have a load of calls saying "application 'xxxxx' no longer works properly, can I get my money back?"... they've found a way to avoid that situation. Surely that is to be applauded?"
Surely it is not Apple's problem if an application fails because of a firmware update that uses undocumented APIs? It is the application's coder who should get their act together.
For those of us used to RISC OS (rather than the Amiga), do you remember how many RISC OS 2 software failed on RISC OS 3 because people used the undocumented "OS_UpdateMEMC", 64, 64 SWI call to poke the memory controller into speeding up the ROMs to make BASIC run faster (barely measurable, in reality!). Or back further in time, how much Beeb software (mainly games) failed on the Master because the 65C02 didn't support the undocumented opcodes.
The lesson is simple - use undocumented stuff at your peril. That is is still happening today is perhaps more a worry to us than Jobsian control freakery. Let me guess, these coders also use two digits for the years, to save on all those unnecessary "20"s? BCD maths for the rest of the date? Oh, wait, I'm sensing deja vu here...
[bootnote - this suggests that there isn't a mechanism to downgrade/revert the firmware if problems should arise...]
I for one support an antitrust investigation. The iPhone is a great device an not only as a phone, it's truely put computing power into peoples pocket in a way many only have dreamed of. But in this case the AppStore vendor lock-in should be illegal, it's like trying to shop around for the best deal on a car only to find there is only one car dealer in existance, and they are fixing the market price.
As a software developer who's weapons of choice are C# and the .NET framework I was excited to hear about MonoTouch and being able to use my preferred toolset to develop iPhone apps. I was almost to the point of allocating a budget to buy a mac, pay the developer tax to his highness Steve, and to buy a copy of MonoTouch. Then this whole OS4.0 issue cropped up and I scrapped the plan.
*Disclaimer: I am not a fanboi but this was posted from an iPhone
"right. Because all the other smart phones and PDAs that were out in the previous 10 years were completely incapable of doing anything.... Yes, you are a fanboi."
The only apple device I own is an iPhone and the only reason I bought it was because I wanted a better data allowance than I could get with my usual nokia selection. After my iPhone contract expires I will be going after some form of Android based device, depending on what is available at the time because it is as equally capable and usable as the iPhone
I have always found older model smart phones to be slow and cumbersome with a bad UI, the only thing i ended up using my old nokia for was the GPS and below-par web browsing, on the upside all the button mashing to get through the user interface did help my texting speed.
I have had PDAs before but never liked them as much as I should because the touch interfaces to them were too problematic, the styli were always too small and toothpick like (I have big hands) and trying to touch the screen directly was also an issue in does it recognise correctly where I touched (did I mention I have big hands). The next issue was the handwriting recognition was poor, even when I sat back and tried to teach it my writing style.
All in all, in my experience the iPhone is the first device I have used that fits in my pocket, has a decent browsing experience, can run custom apps, is easy to navigate and use the UI, looks good and has some decent CPU power to boot. If that makes me a fanboi then so be it but as mentioned before, Android can do what the iPhone can and has the benefit of not being under the iron grip of Steve Jobs.
*Flames, cos I waved the fanboi flag... then burned it!
If the FCC and DoJ can't even decide who should be investigating, then the case is getting off to a week start.
Right after they finish investigation Apple's iPhone, next they should investigate why the Xbox does not allow games designed in PS3 development tools, and why the Wii doesn't accept games developed with Xbox development tools etc, etc, and so forth.
The reason no one is complaining is because these companies don't really care about third party developers making cross-platform games and do allow cross-platform libraries on the consoles' devkits. For example: you know the CRIWare logo that shows on many games? That's a cross-platform library used for video playback. And that's just one of the many cross-platform libraries that're widely used. The end result is that games can appear on more than one console (i.e. Guitar Hero games since III are available on all three major consoles).
The iPhone developers EULA, on the other hand forbids just such a library, insisting on code that is natively compiled only against documented iPhone libraries. The downside is that the libraries the source is compiling against may not exist on other platforms, effectively locking the code down to the iPhone platform. Sure, you could write a cross-platform library to allow the code to compile for other platforms (say Symbian or WinMo), but then Apple's lawyers will breathing down your neck accusing you of stealing trade secrets for doing so. And even if you can prove that you did a clean room reverse engineer (after an expensive lawsuit, no less), there's no guarantee that the code will behave predictably on the other platform.
The only solution is rewrite the code which smaller developers will shun at because they'll either need twice the amount of employees to do the job or juggle two wildly different codes of the same app (one iPhone specific, the other for the other platforms that thankfully support cross-platform translator libraries) and get confused.
It's clear what Apple is aiming for here: Platform lockdown, apps that're only exclusive to the iPhone, or worse yet (or better, depending on who's side you're on) a company that only produces app exclusively for the iPhone.
Stop, because it's already happening: many apps from smaller developers for the iPhone is not available for other platform like Symbian or WinMo.
Apple could have done this quietly: search for some common string (or binary code) on the Flash's interpreter/VM, then if found, reject the app based on that it contains a interpreter which could run executable code. Like when they rejected that C64 emulator (http://www.theregister.co.uk/2009/06/22/commodore_itunes/).
No EULA changes, no press bitching, no inquiries.
Or they could check if it eats a lot of CPU and did nothing useful. 99% of those apps would be Flash based.
No Jobs fanboi here. Just another Flashblock user who hates piece of shit software draining my batteries.
Hooray for the DoJ doing something that could actually benefit the consumer - and hooray for RiM successfully providing continued market back-pressure on Apple.
At what point shall we dump the apple tea into the harbor, then? and the fireworks, are they on standby, yet? Thanks!
I'm all for anti-trust regulation and thought Microsoft should have been split up but the iPhone only has 25% market share. The app developer still has plenty of opportunity with other handsets. This contrasts with OEMs who did what Microsoft told them because buying retail or switching to another OS would destroy razor thin profit margins.
Of course, the SDK terms are still obstructive and evil but the FTC doesn't go into heavy regulation. Americans don't like regulation. So why are the FTC doing this now?
What Apple appears to be doing is locking down developers to the platform so it takes a monumental effort that's short of a complete rewrite to allow the same code to compile on a different platform's toolchain. I won't be surprised if Apple's libraries become more and more exotic and it'll become harder to write code that compiles with minimal tweaking on other toolchains.
Why don't Apple just declare it outright, that programs written for the iPhone belongs to Apple and porting it to other platforms is illegal. That appears to be what they're aiming for anyway.
...would force programmers to think a little bit more than just casting and memcpy()ing around things like crazy.
There exist serious applications written in Delphi and it definitely is not a toy, despite the fact that it was originally conceived as a language for CS students learning programming.
HP's MPE operating system was done in something very Pascal-like and that OS was handling thousands of users during the 1980s connected to a single MPE host. A kind of mini-mainframe. The habit of using C/C++ is simply the ugly secret of the IT industry. Everybody is doing it, because everybody did this for a long time.
And because Delphi only ran on Windows. Now we have the Free Pascal "Lazarus" on Windows, Linux and several CPU architectures.
"The habit of using C/C++ is simply the ugly secret of the IT industry. Everybody is doing it, because everybody did this for a long time."
Wrong. Sorry, but you are very wrong. The reason the IT industry codes in C/C++ is because you can write fast code (also deterministically fast code - a GC cycle will never interrupt your code at a key point). The only language that you can generally get more speed out of is Fortran, and then only if your code contains a lot of vector maths.
Delphi was a great language for the simple reason that it made UI development on windows easy for the first time. C++ Builder (also from Borland) built on that (but oddly enough still used the pascal libraries). Now though, virtually every tool has developed to beyond the state of Delphi - and for Windows development, most people (who don't need the speed) have gone .Net.
The dirty secret about C++ is that, whilst you can code in a grown up, object oriented way, you can also get down and dirty directly with the hardware. Memcpy might look ugly, but it is still the fastest way to copy an object or set of objects.
The iPhone system libraries and primary development language is Objective-C, which grafts the method passing object orientation of Smalltalk onto C. It's a fully reflective runtime with complete dynamic dispatch, and you can write in a completely typeless manner if you want.
C++ and, I believe, Object Pascal, are from the Simula school of statically bound, typed languages.
It's a strict superset of C and C++ code is fully callable (and may call Objective-C, and the languages may intermingle within methods and functions), but it's not the way Apple would prefer you proceed.
In practice, you pretty much never directly manipulate memory in the memcpy style in Objective-C unless you've chosen to do some low level optimisation work or are dealing with a C library such as OpenGL.
First up, US monopoly laws aren't based on market size, they are based on whether or not you illegally use your monopoly position in one area to extend it to another. Steve obviously has a monopoly on Iphone. He has created a market for apps on the Iphone. Now he is attempting to improperly reclaim that market by exerting the influence of his monopoly on the Iphone.
I think that both Steve and the monopoly law are asses. I wish they could both lose. So maybe I'm not so ambivalent, but I sure can't pick a winner.
bought a super-duper battery-powered floor mop (don't ask me why - I've been married to her for 30 years out and there are some things I still can't fathom). It sprayed special cleaner on to the floor and then mopped it up again with special mopping-pads. It was made by Flash and used special bottles of Flash Liquid and special Flash mopping-pads.
Flash has a monopoly on Flash battery-powered floor mops.
I don't see anyone making a huge fuss that you can't buy bottles of Cilit-Bang or jif to use in it.
Apple is not a monopoly of any defined platform. They are a monopoly of platforms in the middle of becoming. Once all the stitches are pulled tight, and courts recognize them, the barriers to entry will already exist. No law against needlework.
They are also like the morning sun. Golden and magical, and blowing off a highly charged wind.
... the attention to detail and invoking documented APIs is further extended to all Apple devices.
Wouldn't that be a wonderful way to have fully operational devices such as print/scan/copy/fax machines?
These cross-platform compiler things tend to do an awful job in unskilled/lazy hands.
"Wrong. Sorry, but you are very wrong. The reason the IT industry codes in C/C++ is because you can write fast code (also deterministically fast code "
But C/C++ is definitely not the only way to do that. Ada, Pascal, Modula 2 are just a few other options. The aerospace sector is very happy with Ada and that is exactly because the language forces you to operate in a much cleaner way than C/C++ allows you to do.
I agree that the GC-based languages are a regression, because of their non-deterministic runtime (or the requirement to pre-allocate the total set of objects that will ever needed).
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
