top | item 1250799

New iPhone Agreement Bans Flash-to-iPhone Compiler & Others

525 points| swilliams | 16 years ago |daringfireball.net

480 comments

order
[+] raganwald|16 years ago|reply
Getting away from the frenzied rhetoric, my opinion is that what Apple really wants to prevent is people releasing multi-platform compilers. So taking Flash as just one example, if I can build one app and the compiler can make me an iPhone executable, an Android executable, and so forth, Apple don't want that.

In my experience so far with such "cross platform compatibility layers," they always produce results that water down each platform's individual strengths and differentiations. And of course, instead of the developer being locked into the phone platform, they are locked into the compatibility layer's platform.

Adobe's Flash compiler is a classic maneuver to "commoditize your complements," as Joel put it so well. Apple don't want to be commoditized, especially if it means having apps that don't take advantage of the iPhone's strengths.

Adobe want to lock developers into Flash and commoditize everything else as Flash-delivery devices. Apple want to commoditize applications and lock developers into their APIs.

http://www.joelonsoftware.com/articles/StrategyLetterV.html

[+] mortenjorck|16 years ago|reply
If the cross-platform experience is subpar, Apple should just let these apps fail in the market.
[+] icey|16 years ago|reply
This change doesn't just cover Flash though; it also hits all of the Mono cross-compilers (and Scheme, and everything else that happens to cross-compile).

I can't see any way that this turns out as remotely positive for developers.

[+] lispm|16 years ago|reply
Say, one wants to develop a touch user interface for a visual programming language for music composition and the core engine happens to be written in Common Lisp (say, something like PWGL or Open Music) - why can't I have that in Lisp? It is compiled, native and would use the Cocoa libs.

There are not only consumers which want to download ebooks with ads. There could be an area of innovative and experimental use where Universities want to develop novel applications - applications that might be written in Smalltalk, Lisp, Haskell - or any other language that can compile and is not Objective C. In many cases the innovation lies in the core logic and the innovative use of a touch screen. Why should I develop my core logic in a way that it is tied to the iPhone or iPad (assuming that the iPad will get the same developer agreement) and where I have to use a relatively low-level language like Objective C.

It is one thing what you assume Apple's target (Adobe, cross platform frameworks, ...) is and another thing who else is also affected by these clauses the developers have to agree to.

[+] lg|16 years ago|reply
Nah, that's bullshit. Applications written in a higher-level language and compiled down to Obj-C could be a lot better than apps written in straight Obj-C, for the same reason that applications written in Obj-C are better than applications written in straight ARM assembly.
[+] edster|16 years ago|reply
It's not just with the consoles. I used to develop Lotus Notes applications. The problem with Notes was that the barrier to entry for developers was too low such that it hurt the platform, and it made it hard to distinguish good developers and good apps from the chaff. When a bunch of unqualified developers fill the world with junk it gives the entire platform a reputation as being junky.

I now develop iPhone applications, and I personally agree with Apple in this respect. If you want to develop iPhone applications, spend some time and become proficient with the tools.

And, @raganwald is correct that it's still lock-in, it's just a matter of where the lock is.

[+] JPtw|16 years ago|reply
Performance is an easy excuse. A terrible programmer can do worse than cross compiler. If Apple do care about the so-called performance, they should judge apps by their quaility, not the process of how they are created.
[+] ghshephard|16 years ago|reply
Adobe's response, from a game-theoretic perspective, is to adhere to

   3.3.1 — Applications may only use Documented APIs
   in the manner prescribed by Apple and must not use
   or call any private APIs. Applications must be 
   originally written in Objective-C, C, C++, or 
   JavaScript as executed by the iPhone OS WebKit 
   engine, and only code written in C, C++, and 
   Objective-C may compile and directly link against
   the Documented APIs (e.g., Applications that link 
   to Documented APIs through an intermediary translation 
   or compatibility layer or tool are prohibited).
by simply generating Objective-C as their Object Code. Developers then compile this for their target platform (iPhone) and stay within the bounds of 3.3.1. I see Apple is trying to put a kibosh on this with the "originally written" clause, but, that will be a stretch to enforce.
[+] sergeo|16 years ago|reply
Agree, from my experience any good software for a platform should take as much advantage of the platform as possible. And then work around platform limitations. Any cross-platform apps look non-native, missing subtle platform conventions, and ultimately feeling awkward on such a distinctive platform as iPhone OS. This seems to be a consistent line of Apple's, ultimately aiming to project the "quality" image of the platform, and not diluting the valued brand. This is the same line as John Gruber suggested pondering the purge of overly explicit apps. It did not come down to purging crapware developed natively with Xcode yet, but with thousands of apps in each category, the purgatory moment in one form or the other (e.g. if not purging outright, but subjectively separating into premium and "others" stores) probably is not too far ahead.
[+] lwhi|16 years ago|reply
It's not just about quality.

As with everything Apple does - there are company-centric motives, which have been neatly balanced against a set of consumer-centric motives.

Apple is run by smart people, who realise they have a dedicated following. By making the 'we don't want to diminish the quality of the App pool' argument clear, they allow their ardent followers to do battle for them.

The corollary of this is that Apple ensure that their platform receives the developer investment it requires, enabling the company to become a permanent fixture in the mobile market.

If Flash developers didn't have to make a new investment of time and money to learn their platform - what would stop this pool of developers from leaving Apple's side tomorrow?

They want full control over what is allowed _into_ their market, and they want a dedicated team of developers who won't walk away.

If Flash was allowed, neither of these requirements would be assured.

[+] MutantSushi|16 years ago|reply
Sure, 'multiplatform compiling/targeting' is one thing. But banning non-approved languages is silly. Even apple is funding projects like RubyCocoa and bringing Python compatability to the Cocoa API. If somebody wants to write an app using CocoaTouch but finds Ruby, Python, Lua, or Mono to be a better fit for the project or their own capabilities than Obj-C, why stop them from doing so? If the apps still have to interface with Cocoa somehow, how are such app's any more/less native than one written in Obj-C? Such a policy does nothing to stop somebody from writing a cross-platform targetting framework that uses Obj-C. The language is not the real issue.
[+] gregbulmash|16 years ago|reply
Imagine if Microsoft had come out with an App Store for Windows 7 and decreed that the only way to run apps on Windows 7 was to get them from the Microsoft App Atore. If you wanted to create apps for Windows 7, you'd have to use Visual Studio and a Microsoft compiler, you'd have to pay an annual fee to be a an accepted Microsoft App Store developer, and if you wanted to charge for your application, you'd have to pay Microsoft a 30% commission on the sale price.

People would lose their damn minds.

If you're the dominant OS in the smartphone market or in the desktop market, where's the difference?

Apple has to unlock the iPhone and let people get their apps from wherever they want.

If people want the security of knowing an app is Apple approved to work and play nice with others on their systems, they can go through the App Store.

It's not their rules, but the fact that they remove choice from the market for both consumers and developers by FORCING themselves into the consumer/developer relationship as a restrictive middleman.

[+] colinwiseman|16 years ago|reply
I can understand Apple wanting to lock down their property to make sure what comes on it is quality and secure. Look at MS, anyone can develop almost anything on it, and what we have is a massive bug and virus trap.

BUT... Microsoft was given into trouble by the competition commission over the tight reign it had on Windows. Now what are we saying, Apple should be allowed to get away with near enough the same things Microsoft got fined for? just because they are Apple?

If Apple just lets this happen, and lets iPhone apps be developed on other OSs/SDKs/whatevers, then if a developer wants to produce a piss poor version of something then let them. Apple can then say yeah or nay when the App goes into the Store. They are still going make money, their phones are still going to be bought in droves.

Open the doors Apple, you might let something good in.

[+] bpod|16 years ago|reply
I agree with Apple, 80% of apps are crap and are deleted after a few weeks, thats not a good app and not how apple what to be seen as having a junk yard of crap apps ? Would you delete Photoshop after a couple of weeks ? No, why ? because it's a good bit of kit, and Apple want to keep that inline with there image.

I am not a developer but have been investigating starting a development company, I have seen 1,000 of bedroom chancers on the fourms....

Yeah man lets make an app and cash in, lets make an app called twitbook, it's a cross between a twit and a book we will get 1,000 downloads a day and we will spend it all the profit on weed, yeah man good idea ! Ok lets start... we can't code but we can use 3rd party apps that even my mum can use and we are done.

Yeah I am exaggerating slightly but thats how the market is going, it means that the app store is constantly full of shite with shite apps and will get worse if these 3rd parties are allowed to run riot to let any Tom Dicks and Harrys to release apps, which will happen if it's allowed to. Apple does not want to encourage that and nore do I, I want quality not quantity apps.

This is a new phenomenon for the world so Apple are bound to make mistakes on how they operate it and they have realised this is a bad thing that is happening to THEIR brand.

I have seen so many good serious developers with good apps, they complain they are not getting seen on the app store and above is the main factor for that, piles of it.

These guys can code with their eyes closed and yes the 3rd parties apps maybe an inconvenience but I am sure they can work round it and actually get the coverage and sales they deserve.

In the short it's not good but the long of it is that it will be good for the people who know what they are doing hence brining us apps that don't sit on our phones for a few days and get ditched.

Why are people screaming about this ? It's all about money on both sides, not future development of the up and coming kids, end off.

If I rent a room in your nice house and start pissing on the carpet would you want to boot me out ?

As far as i remember it was always Apple being victomised by other OS and software companies, how the tables have turned and good on em.

[+] gromitski|16 years ago|reply
I'm sorry but that is a terrible excuse for what they've done. As a flash developer hit hard by the recession, having another (strong) string in my bow was essential for survival. Like others in my industry, I don't have time to completely re-train every time a new product comes onto the market. Being able to produce for a different device using my current skills is a blessing. Apple should be thoroughly ashamed with themselves and I for one will be approaching the Monopolies Commission regarding this.
[+] statictype|16 years ago|reply
What you're saying makes sense, but at the end of the day - it doesn't matter what Apple wants to do, what matters is what they have actually done.

If they wanted to eliminate cross-platform apps, they could have just as easily put something which specifically mentions that in their terms of service. It wouldn't be any more ridiculous than the conditions they have put in place right now.

These new terms of service effectively bar tools like Monotouch - a development environment that exclusively targets the iPhone OS.

[+] bliss|16 years ago|reply
This is seriously putting me off. I was not thinking of a third party approach, but it limits me when I want to use my OWN scripting language when developing apps.

Does this stretch to build scripts??

[+] brianshaler|16 years ago|reply
Okay, so cross platform compatibility layers water down each platform's individual strengths and differentiations. What happens when a small team of developer needs to re-write their application to reach more devices? While the platform with the most users will probably get the most polish, the rest will probably flounder at v0.9. I guess Apple could be counting on being the platform getting the attention. Let's see how that works out for them in the next 5 years!
[+] sunilshah_99|16 years ago|reply
Apple is really trying hard to enclose and seal a closed garden environment, that much more lucrative for them. HOWEVER, 98% of video seen is currently viewed via flash. If Adobe have a cross compiler that works and apps can be translated WELL onto the apple platform, why should apple care? if they dont work, the user will decide!! Is this Microsoft all over again? And is it non-competitive? A legal suit looms over apple's head. One I suspect they will lose.
[+] bettynormal|16 years ago|reply
MonoTouch isn't really a cross platform toolkit. It is not providing a replacement API for Apple's APIs just allowing them to be called from C# and allowing you to use extra code you have in C# that Apple by definition doesn't have.

the Modern C# language provides many advantages over the Objective C used on the iPhone which does even have garbage collection.

If they intend to succeed in the Enterprise they should of encouraged MonoTouch not squashed it.

[+] bettynormal|16 years ago|reply
How can anyone now develop a business and future with Apple when it could all be taken away at a moments notice.
[+] slashdotdot|16 years ago|reply
I presume all these other programming environments allow one to target the iPhone/Pad/Pod using a PC. Is Apple, with all their (new) clauses, trying to say in a round-about way "If yer wanna target our iDevices, buy a Mac"..? After all, Mac sales is where they make the most money.
[+] bettynormal|16 years ago|reply
20 years ago I used to rave about how Objective C was 10 years ahead of anything else out there. Unfortunately it's now 10 years behind C#....
[+] phifty|16 years ago|reply
They dont want anyone peeing in their pool. They purge the pornspam apps, they purge the rss-reader apps. I personally think this is a good thing, because developing a native iPhone app in C/C++/Objective-C means you will more likely have a vested interest in the iPhone/Mac platform other than to make a quick buck with a flatuence app. At the very least, you're a more dedicated developer.
[+] pg|16 years ago|reply
I don't like this at all. Maybe they only meant to hit Flash, and maybe not, but as written this is in direct opposition to one of the most important principles of software development. Apple themselves must have benefited countless times from writing software in layers. But no layer above their layers is permitted?

I wonder if the open source world can successfully fight back, by making compilers that generate code the app store police can't tell from hand written.

[+] jrockway|16 years ago|reply
I wonder if the open source world can successfully fight back, by making compilers that generate code the app store police can't tell from hand written.

I think the answer is definitely yes. Apple's software engineering is not that great. There is always some hole in Safari that allows root access to the entire device. They can't get atomic syscalls working in OS X. Does anyone really think they can recruit and afford people that can tell computer-generated software from hand-written software?

My guess is that this is a scare tactic to keep anyone thinking of supporting two platforms at once to "not want to risk it" and go for the iPhone instead. More users, only so many hours that the developer can be awake, safer to just go with the iPhone. (Of course, you are already risking it anyway; use the wrong multi-touch gesture -- app denied. Use a Google service -- denied. Do something useful that Apple wishes they thought of first -- denied. And people wonder why there are so many fart apps...)

My next guess is that this tactic will be successful. People seem to adore doing whatever Apple tells them to do. It frightens me.

What I've learned from iPhone vs. Android (among other things) is that people will pick pretty and mean over average and nice.

[+] yesimahuman|16 years ago|reply
Even if it can, that's not the point.

Is this the kind of company you want to build software for? This is bullshit. Do I really even want to play along anymore?

This company makes great products, but they can do completely dickish things.

[+] icey|16 years ago|reply
I don't really have a politically correct way to say this: What a horseshit maneuver by Apple.
[+] paulsmith|16 years ago|reply
Putting aside the intention of this agreement which does seem targeted at the Flash-to-iPhone compiler, this just seems overly broad and silly from a "how things work" point of view.

Let's say I write an iPhone app originally in Scheme (like this guy did: http://jlongster.com/blog/2009/06/17/write-apps-iphone-schem...), and compile it down to C, which is then compiled to object code and linked against the iPhone libraries. At this point, the object code is the same (or functionally the same in terms of its syscalls, library calls, and general program flow) as if I had originally written it in C, except that I would have lost the unique developer efficiencies I got from using Scheme in the first place. I'm not saying Scheme is better or should be an officially sanctioned source language for the iPhone SDK. I'm just saying, where the rubber meets the road -- object code linking against libraries and making certain calls -- there is no difference to the computer what the original source was.

Seems very silly.

[+] ezy|16 years ago|reply
Say hello to the new boss, same as the old boss. The corporate pissing matches have started in earnest...

When Alan Kay said Apple would take over the world with an iPad, I don't think he realized that eToys or anything like eToys would never be allowed to run on the device and that a majority of the apps will probably have commercial spots embedded within them. Actually it reminds me of "educational" tv all over again...

I'm starting to see the point of people who complain about the consume vs. create nature of the iPad...

[+] dejb|16 years ago|reply
> Say hello to the new boss, same as the old boss

Who do you mean by this? Microsoft doesn't make sense in this context.

[+] ptomato|16 years ago|reply
"a majority of the apps will probably have commercial spots embedded within them"

The majority of apps on the app store already do. Free apps, ad-supported. Apple just wants the ads to not suck so much, but hey, nobody has to use iAds.

[+] archgrove|16 years ago|reply
I can think of only two (tenuously) justifiable reasons for this.

1 - Perhaps, during the beta, they want code written in C (and derivatives) to aid in debugging framework bugs. Rather than "My App doesn't WORK!!!!! (Using MonoTouch Vxxyy)", they can get a repro using a stack they know and control top to bottom. In this case, I can see it as justified.

2 - If it's specifically to target cross-compilers as a business decision, to ensure that iPhone only gets "exclusives", then I suppose it's their prerogative. It will probably backfire long-term, as their market share isn't that dominant. "Browser, Palm, Android + all else" or "iPhone" makes the iPhone a secondary port target versus a first class platform.

If it's any other reason, it is ridiculous. It makes me seriously question my upcoming Mac Pro & iPad purchases. Even though I currently develop for Mac and iPhone using only Obj-C, I can't build a development strategy around a schizophrenic "partner". What's next - documentation not written in Pages? Failure to use Steve's favourite colour in the background? It's getting... bizarre.

[+] tumult|16 years ago|reply
This is unsavory in the extreme. I had been writing an iPhone app in Haskell, and now I have to can it? What the fuck? Fuck you, Apple! Blowhards.

Hope you guys enjoy the mass exodus of decent developers from your dumbass platform with kiddie languages.

[+] jrockway|16 years ago|reply
Who's going to know? My C happens to look exactly like what Chicken Scheme generates!
[+] jim-greer|16 years ago|reply
'Additionally, developers may not consume energy drinks or snack foods with preservatives while developing Applications'
[+] WilliamLP|16 years ago|reply
> Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine

Controlling programmers like this seems positively insane, doesn't it? Does this mean that games can't do scripting in something like Lua either, under the letter of Apple's law?

[+] zhyder|16 years ago|reply
Oh man, just when I was impressed with what they're doing in iPhone OS 4.0, they throw this in.

I was hoping to finally develop for the platform thanks to background services, but my moral objection is now at par with my profit motive.

[+] gte910h|16 years ago|reply
Hey lookie there, I can return this iPad still. I'll go buy a second android phone for my Development shop. Great Job Apple!
[+] dugmartin|16 years ago|reply
Wow. Just wow.

I was planning on building an app in Titanium. I guess I'll wait and see how this shakes out first.

btw, at the time of writing this comment Titanium's developer center is hosed. Maybe it became self aware at the same time and commited suicide.

http://developer.appcelerator.com/

[+] orangecat|16 years ago|reply
1. Apple takes iPhone stability and security Very Seriously.

2. ???

3. Therefore, if you write native iPhone apps, you must use C derivatives that expose raw pointers and direct memory access.

[+] alex_c|16 years ago|reply
Welcoming explanations for how this is a good thing for Apple's end users.
[+] swilliams|16 years ago|reply
Is there a legitimate reason for this, or is Apple just thumbing their noses at Adobe (and everyone else)?

Is Apple primarily annoyed that Adobe's app and MonoTouch aren't doing it the "Apple" way? Or do they not like that those frameworks present non-standard UI's (I haven't used MonoTouch, so I don't even know if that's the case here)?

[+] andreyf|16 years ago|reply
Looking forward to Adobe's response. Going to wager it'll be in the form of a lawsuit, and that the FCC will get involved. Whip out the marshmallows, this should be interesting :)
[+] AndrewO|16 years ago|reply
While Adobe is going to bear the brunt of this, this looks like a calculated move against Android as well. By precluding things like PhoneGap (if it turns out that it's "an intermediary translation or compatibility layer"), they're forcing developers that can only afford to write an application once to choose one platform. Right now, iPhone is the easy choice for a lot of developers, just based on market.

The end result being fewer apps for Android and a less vibrant software ecosystem.