It seems like every few months, John Gruber hits another clout milestone. Now Steve Jobs's own statements are a self-described tl;dr of Gruber's posts? Not too shabby.
Anyway, the puzzling thing here is that as Greg says, most iPhone OS apps are written in one of the whitelisted languages already. Couple that with what I think is the likely fact that Apple is being honest about its motives (namely that it doesn't want its roadmap to have to consider third-party toolkits in any way), and it's confusing. Why would they go to the trouble of pissing everyone off to bring about a result that had largely brought itself about?
Two answers. One, I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular. Two (and I think this is a huge part of it), Apple seems to have simply underestimated how mad this would make developers.
I wouldn't be surprised if the company went back on 3.3.1, or at least moderated it. Apple's only willing to be a jerk when it and the public agree about the level of jerkitude at hand. If Apple gets more ire than it was expecting, there's precedent for it backing down.
> I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular.
I guess Apple has been surprised by apps popularity. Their original policy was that 3rd party applications ought to be web apps (initially, it was the only way to go).
Embedded applications make sense:
* for super-tightly integrated user experience: but then, you don't want any lowest common denominator middleware on the way, as they guarantee a crappy experience (typically way worse than a decent and portable web app, see below).
* for driver-like stuff that do magic (but Apple always hated the idea of 3rd parties writing such sensitive code, which is one of the reasons why OSX is way more stable than Windows)
* because in some countries, users are stuck with a not-so-reliable 3G carrier, so being able to run offline is valuable. Hopefully that's a temporary situation, and I understand that HTML5 allows to write offline-compatible web apps anyway.
* because it's culturally accepted to pay a couple of dollars for a fart simulator app, but most people won't pay a dime to access the New York Times content in a web site. That's the reason why most apps are apps rather than web sites, but that's a problem with the web, not Apple's business.
This last point is at the core of most issues with Apple's tight control on iPhone apps: most of them should have been web app. They've been written as apps not to benefit from the iPhoneOS platform, but to benefit from the AppStore's easy monetization and publicity. It's about the AppStore, not about the iPhone!
I would be surprised if they did go back on 3.3.1. They're hurting themselves with the backlash, yes, but they're hurting other mobile platforms far more, further securing their position as the #1 mobile platform to develop for.
That said, I'd be surprised if Apple spends too much effort policing the rule. The fact that it exists in the first place will probably be enough FUD to prevent third party toolkits from taking off at all. They'll probably do some kind of automated signature testing for Flash, Unity etc and leave it at that. The upside of that is you'd probably be able to sneak a Clojure or whatever app in and nobody would probably care too much.
I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular.
I don't think is it. I remember when Metrowerks PowerPlant was the main framework. Apple had let their own MacApp and MPW languish. Arguably Metrowerks CodeWarrior saved the Mac as a development platform.
It's funny, his main example of a "high quality cross platform app" was Mozilla Firefox. In my opinion, Mozilla Firefox is a prime example of why the intermediate layers (if Firefox uses one, I'm not sure) and the cross platform stuff is a bad idea. It uses its own weird certificate store instead of using the operating system's, its interface does not have a Cocoa feel in any sense of the term, etc.
But we're talking about whether cross platform apps are of such a low quality that banning that outright is a good thing, how can anyone suggest Firefox isn't a counter example to that?! Compare Firefox to the average App Store offering and I think its obvious that this Section 3.1.1 is bullshit. This move by Apple is just an attack on Adobe that is catching innocent developers in the crossfire.
Firefox may not have a Cocoa feel but he prefers it over Safari anyway since it serves him better. So apparently native look 'n feel isn't all that for some people in their choice of applications.
I feel the same way about Safari on my iPhone. I quickly ditched that for a better browser.
There are a great number of application that does not have a native look and feel, does not use built-in resources from the operating systems that I use and yet I think they are great (Firefox, Vim, Apache Directory Studio), even WebKit (and WebKit2) is a cross platform layer on top of WebCore[1][2].
No, if anything, Firefox is proof that you can write a bad 'native application' in C directly with the APIs provided by the OS. It's entirely possible to write something that is more native than Firefox but is based on another language, like Ruby, a Lisp, ML, etc.
When Steve Jobs got a demo of the graphical user interface and object-oriented software at Xerox PARC, he saw a computer that could be interactively programmed. In Smalltalk.
When Steve Jobs started with NeXT in the mid 80s he got a demo of a novel program that can be used to interactively design general user interfaces - the first program of its kind.
It was written in Lisp by Jean-Marie Hullot. It was called SOS Interface, marketed also as Action! by the company Expertelligence.
Steve Jobs hired him and Jean-Marie created the Interface Builder - which became one of the most important tool on NeXT OS. Then for Mac OS X and now for iPhone OS.
This innovation is now hindered by Apple. The innovative software may not be written in Lisp anymore, but it is not necessarily Objective-C either.
With the Mac everybody got a copy of HyperCard - everybody could write and design programs in a simple way - using the built-in HyperTalk. Xerox had such a software years before - called NoteCards and written in InterLisp-D.
With the iPad, which is much more capable than the Mac where SOS Interface and HyperCard were developed, everybody is degraded to be a consumer. The goal is no longer to be a maker, a creator, a programmer. You can't even use a shell to connect to your own iPad.
There is huge domain of visual programming and end user programming to be explored on touch screen devices. Maybe Apple is working on that and hiding this (like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks) - from what we see now Apple hinders innovation and innovators in these areas.
I want a 'DynaBook' and not a media player.
Steve Jobs did not really understand what he saw at Xerox PARC when he got the demos of the Smalltalk system. He got the idea of the graphical user interface. But what he overlooked was the concept of object-oriented programming. He later with NeXT understood that. But what he never really got was the importance of interactive programming, end-user programming - the role of the user being able to program his computer in a straight-forward way. The cultural importance of being able to write, understand and change software.
Here we go again.
I got a free copy of Xcode, IB and Dashcode with every release of OS X I had. I can
code in C, C++, Objective-C (with a choice of compilers gcc or clang), PHP, Perl, Python, Ruby (including RoR), Java right out of the box. SQLite is also there and maybe some stuff I don't even know I have.
Existence of iPad (and iPhone) does not hinder innovation — it fosters it. Three years ago
there was no iPhone, no iPhone OS, no App Store. Now we have a new platform with not far from 200 000 (just think about it) applications written for it. iPad gives an opportunity
truly explore what's possible on multitouch device with dedicated UI.
I am a web developer, but I do not complain that I cannot easily write my code in the browser itself. Nor do I want to.
Just think about it: if there were no iPad you could not code for it even in Obj-C.
The false dichotomy is the assumption that since Apple makes two portable devices, one that creates content (Macbook) and another that consumes it (iPhone/iPad), that there must be two kinds of people, content creators and content consumers.
There is no reason not to own a laptop and a tablet for much teh same reason that many people own an iPod and an iPhone and a laptop.
In my own case, I own a laptop for development, a mini for displaying media on my 37" display at home, an iPhone for calls and portable content consumption, and an iPod Classic for music in my car.
All of these together cost less than my first development system. I think that people who want to create content and programs will do so, and the iPad does nothing to hinder them.
Don't you think the fact that iPad SDKs and programming tutorials are readily available from Apple, plus the fact that Apple still sell Macs which interface with the iPad (but which they obviously don't want the iPad to render obsolete), contradicts your vision of the present trend? I mean the iPhone surely spurned a HUGE number of people to become (in your terms) 'creators' - and that was before non-Apple developer tools were even on the table.
Stop thinking of the iPhone/iPad as if they're just small Macs. They are neither general purpose computers, nor are they RAD platforms. They're consumer devices with restricted capabilities and resources.
No innovation has been hindered, in fact it has been enabled. Smalltalk, SOS and others are tools that make certain kinds of experiment easier.
I remember when RAD tools were only meant for building prototypes, with the assumption that the program would be rewritten in a conventional language afterwards. They only became the delivery environment after consumer machines gained so much RAM and CPU power that the benefits of optimization became negligible.
Well, these are cell phones, batteries with CPUs. We're back in the 80s again. Section 3.3.1 does not prohibit anyone from developing iPhone software with whatever cross-compiler or funky toolkit they like, it only prevents them from deploying the output to consumers through the App Store.
>like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks
The point Jobs was making was that a device used exclusively for reading would never be successful. He wasn't suggesting that it would be pointless to participate in the ebook market, just that it would need to be on a general purpose mobile platform.
So, I can understand why developers dislike and hackers despise the new 3.3.1 rules. What programmer, in their right mind, wants to have the language they develop in dictated to them?
But, for just a moment, I'm hoping that some of you can appreciate how miserable an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
At times, those applications have been _so_ bad as to be an advertisement for windows. I'm an Apple fanboy, and own three generations of Apple MBPs, three iPhones, and, of course, an iPad - but to this day, at work, I still keep a 2003 class Windows XP system with Microsoft Excel on it to get work done - The painful experience that is Office 2008, (and don't get me started on "NeoOffice") single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
When I read Jobs's response, I could only imagine that he was having bad flashbacks to some of the x-platform disasters of years past.
I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
> I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
Well, OK, but the other possibility is that the executives at the few development shops out there capable of putting out a AAA title take one look at Apple's terms, observe that their entire investment could be arbitrarily yanked by another commercial organisation without compensation, kill the iPhone/iPad development before it starts, and target more open platforms that don't come with the same absurd levels of risk instead.
In the long run, the developers will always win, because someone will always make a platform where good developers can write good software, and then people will buy that platform to get that software. On the other hand, no-one cares about the platform, even if it's Apple, once the initial "Oh, shiny!" moment wears off and you actually have to get stuff done.
> an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
I'm not sure that proves your point here. Microsoft has had a Mac development team since the very first Macintosh. They write native software that is not a port of the Windows versions. In the past, IE for the Mac actually had more features (and was more standards compliant) than the Windows version. All this proves is that, yes, native apps can be crap. Which is exactly why this rule is entirely pointless. It's the not the development tool that matters, it's the developer.
> single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
They're also eliminating any other tool or language which can also be written directly for the iPhone OS. Something like MonoTouch uses the iPhone API directly, it just happens to allow developers to use C# instead of Objective-C. No translation necessary.
Even Adobe Flash apps being recompiled for the iPhone isn't a big deal. A high quality Flash game like Bejeweled, for example, is going work great on the iPhone if Adobe did their job right. That is an opportunity for you to have apps you wouldn't otherwise have and it's not wasting programmer resources rewriting it to achieve the same result for nothing.
Rule 3.3.1 does not mandate high quality applications. If you want that, make Apple use their approval process for that instead of their own selfish interests. This rule does nothing to give you want you want.
I would not consider Firefox to be a "top-notch" Mac app. Every time I used it it felt slow, awkward, and clunky. I'd even find myself using non-native keyboard shortcuts (despite the native ones being available; e.g. F5 vs. Cmd+R) simply because it took me out of the "Mac native" world. No matter how close its emulation came there was always something to throw me off, mostly little GUI idiosyncrasies.
It's not good on Windows either. It still better than IE though, but way behind Google Chrome. Chrome is fast and when I browse, I want to quickly scan pages and run JavaScript.
FireFox exists in my desk only because it has FireBug and a couple of other web dev. tools.
Firefox was my default browser on Windows since v. 0.6 when it wasn't a Firefox yet but Phoenix.
It was still my default when I switched to Mac, but with the
release of Safari 3 Firefox was relegated to development/tools role. I'd say the only area it beats Safari is extensions. Alas, Chrome also has those now. When Web Inspector matches Firebug, my usage of FF will be for testing only :(
And yet, I'm writing this from FF on OS X right now because the awesomebar is just that damn good.
I've actually seen the benefits of the cross-platform approach first-hand, too. I've copied my same profile from mac to linux to windows and it Just Worked every time, extensions and all.
Well, at least we know he's listening and is concerned enough to respond to the criticism. Where this leads will be interesting to see, it's only been two days after all.
You know they are worried when they are using their PR backchannel. (But damn, what a great tool from a PR perspective.)
(I don’t really know whether Firefox is such a good example. It’s a great program because it first challenged IE, not because it’s anything close to a native feeling app. There must be better examples out there, right?)
For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve. Obviously Apple employs some very talented programmers, or else we wouldn't be here talking about the iPhone. But surely Steve has a working understanding of the issue? Compared to Wozniak, he may have been the less technical of the two, but reviewing his history at Apple, Pixar, and NeXT, I think we can agree that he has a much better understanding of his products than many CEOs.
Apple knows what they're doing. As usual, they are just very conservative and arrogant, which I'm personally OK with (in general) because they make great products.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve.
It is, however, fair to say that Jobs is overlooking some very basic computer science. There is no reason why a tool like Flash can't emit Objective C, and there is no guaranteed way for an app reviewer to tell the difference.
The quality argument is bunk, in a very obvious way. Apple reviews each individual app anyway before it can enter the App Store. In other words, given a review of an individual app, the original platform and the app's quality are d-separated (in the Bayes Net sense).
And, obviously, such a meta-platform would be out of Apple’s control. Consider a world where some other company’s cross-platform toolkit proved wildly popular. Then Apple releases major new features to iPhone OS, and that other company’s toolkit is slow to adopt them. At that point, it’s the other company that controls when third-party apps can make use of these features.
This has happened before. It's called the web, and it's beautiful. Slow to adopt? Hells yes. But I love it because it runs everywhere.
The web is many things, but it is _not_ beautiful. It is a mess. It happened by accident, evolved beyond anyone's control and is now a beast loose upon the world. Unlovely in the extreme.
And it does _not_ run everywhere. With lots of work, you can make it run a lot of places; enough to be worth the effort. It is certainly useful, but not _nearly_ as useful as it could be.
Ted Nelson, who created the term hypertext, famously said, "HTML is precisely what we were trying to PREVENT-- ever-breaking links, links going outward only, quotes you can't follow to their origins, no version management, no rights management."
While politically I myself am very much in favor of open standards, for reasons I shouldn't have to explain _here_, I'm also vastly disappointed in the quality of most of the results, if from no other viewpoint than a human factors one. Like the talking dog, proponents seem happy that it talks (works) at all, and don't seem nearly concerned enough about what it's saying...
If I may: The salient difference between the web and a meta-platform like Flash is that while Adobe controls flash, nobody controls the web.
If Apple wants to build hardware acceleration for CSS animations on iPhone, it does so. If Apple wants to fix a bug in Javascript, it does so. If Apple wants to close a security hole in Safari, it does so.
Whereas if Adobe feels like making Flash slow as shit on OS X, it does so. If Adobe doesn't feel like fixing a bug on OS X, it doesn't fix a bug on OS X. If Adobe can't be bothered to fix a security bug on OS X, Adobe leaves a huge security hole open on OS X.
The web is a "worse is better" alternative to native iPhone apps, but at least it's open and offers opportunities as well as dangers for Apple.
Regardless of the content of Jobs' response, and regardless of the merits or flaws of Section 3.3.1 for Apple, developers and consumers: It is interesting to see that Jobs is aware of the dissatisfaction with this clause. The man isn't stupid, and maybe he will pay attention as more developers look for other platforms with more open developer licenses.
I've always seen Jobs as being highly principled and opinionated about the technology he helps create, but not particularly greedy (it is perhaps fortuitous that his principles have contributed to Apple's financial success).
I get the impression that Section 3.3.1 was changed as-is because Jobs honestly believes that restricting use of cross-platform toolkits and compatibility layers will help keep the iPhone platform and AppStore true to his vision of what those platforms "should be" (whether or not this is actually the case). I also don't think Jobs is explicitly trying to lock developers into the Objective-C/Cocoa development platform (though this might be a welcome side-effect of this decision from Apple's POV).
Philosophically I don't agree with Section 3.3.1. However I can see, on the one hand, how it fits in with what I understand of Jobs' character and motivations about his technology. And on the other hand I can see how it makes good business sense for Apple in the short-term. In the long-term it may not work out as well if it induces a developer-exodus. But since Jobs is paying attention, we'll see what happens when that time comes.
"Intermediary layers" are what make modern programming productive. We don't all write in processor-specific assembler because it's not (developer-time) efficient, and because we can accomplish a given task without having to resort to such a low level. For example, it's far more efficient to write in higher-level C and compile for the platform as necessary. The entirety of the software development ecosystem is "intermediary layers". C compiled to a platform target with GCC is sure as hell an "intermediary layer".
I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products". What an arrogant line to feed to developers. At least he's being direct (if not honest) with Apple's intent to fully lock developers into the Apple-blessed toolchain, from the initial concept to the final product. Ugh.
>I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products".
Is that not true though? In most cases, apps that use an intermediary layer will not be as polished or usable as an app developed using the native tools.
Whether throwing mud at cross-compiled apps is valid or not (personally I'd say its validity fades in light of the voluminous bad apps already available... although i do remember Apple already taking some measures against those), I think it's merely a footnote to a sensible business decision. Apple need to preserve their lead, build a wall of incompatibility (now that it's necessary), and avoid this 'de facto cross-platform standard' which would greatly benefit Adobe and others but greatly hinder iPhone. If the iPhone ever loses its strong position you can bet Apple will embrace Flash, Java and cross-compilers in a heartbeat.
This is exactly right. Until they see real damage from the decisions they're making in the form of lost revenue and non-record quarterly performances, why not take the strongest "negotiating" position possible. You can always back down later.
From what I've seen of the CS5 packaging for iPhone, there are no native UI controls. Adobe claims to have a project to port Flex to iPhone, and I can't assume that it will use native UI controls. Since the iPhone is all about the rich user experience, perhaps by limiting access to the AppStore for prior-life Flash 2D games, Apple is protecting the dilution of the quality of the games.
As for the other build an iPhone app application frameworks, the quality of the finished product varies from lackluster to average. At the worst, the finished app looks like one of the RSS reader apps that Apple is now trying to filter out of its AppStore. At the best, it's something like Location Scout. I believe by limiting access to third-party application builders, Apple is going to continue to increase the quality of iPhone apps. Titanium, Adobe et al will never generate anything like Tweetie 2. And, I believe Apple wants more Tweetie 2-caliber applications. To increase the S/N ratio. I believe Apple wants less crap and cookie cutter applications, even though some of the top 25 Free and Paid lists may from time to time have those types of 'Fart' type apps.
Apple is a premium brand. Even for developers. There are barriers to developer entry. It is kind of a privilege to write iPhone apps as you need $99/yr and an Intel Mac. The Cocoa/UIKit framework and CoreData persistence are tools that Apple engineers have invested centuries of programmer years in developing. There aren't many private APIs in Apple land; almost all of the standard iPhone apps could be recreated by third-party developers. And now with OS 4.0, I believe only a small fraction could not be recreated. As another example, Titanium et al. are not using CoreData - CoreData is designed to make managing and persisting an object graph easier. Which is what you need for non-cookie cutter applications. I have yet to find one application built on RhoMobile, Titanium, Ascena etc that leverages CoreData.
And, I wouldn't be surprised if they start rejecting apps for quality (as in what does this app provide that is of value).
"He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
From what I've seen of the CS5 packaging for iPhone,
there are no native UI controls. Adobe claims to have
a project to port Flex to iPhone, and I can't assume
that it will use native UI controls.
I hope you're not implying that the speed of development is an indicator of bad quality.
Any environment where you're working with JavaScript (or Ruby, or Python...) is going to have faster dev time than working with a compiled language. It's not just having to type way less, but less brainless typing leads to better flow.
I'm doing both right now, and I love Titanium because it gets me in the zone, whereas with ObjC, so often I have to turn on autopilot to get through the boring stuff when I create a new model or class or something.
> "He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
Getting a functional prototype to work should be simple and fast. (There's a big difference between a functional prototype and a finished product!) The fact that it's not fast using the Apple toolchain is exactly what's wrong with them. Developer time/effort is limited. A good dev environment should make the common stuff easy; since Apple seems disinclined to provide tools that do this themselves, our big hope for improvement in that regard was that third parties would get in there and fix the problem with products like Corona or Titanium.
Is there an alternative way for Apple to meet its goal of prohibiting extra layers of cross platform toolkits, without mandating the choice of programming language?
Could they somehow say that programs must use native CocoaTouch widgets, while still allowing for people who want to compile from Scheme into Objective C or C?
This makes an interesting thought experiment: what if Adobe decides to take on Apple directly by throwing their weight behind Apple's main competitor, Android. CS5.1 is shipped as a free upgrade to CS5 and replaces the iPhone-compiler with an Android-compiler. Organizations with existing Flash content decide that they had might as well do a quick/dirty port of their apps using CS5.1.
What will the results of this be?
* Lots of Flash content gets released on Android. This expands Android's software market considerably, though with a cost in performance/platform-integration (both in terms of UI and in terms of taking advantage of low-level capabilities).
* Many of the best/most popular and money-making Flash apps will get an iPhone OS-native port. The cost to write an iPhone app is relatively low; if you're talking about a game, the vast majority of the cost is usually in the assets. The iPhone developer tools are very good, there are lots of developers: finding an iPhone developer willing to make a native port of your game engine isn't difficult or expensive relative to the number of users you open up your investment to. Thus iPhone potentially gets the best version of many originally-Flash apps.
Thus, Android continues to have more possibilities (theoretical and, in some cases, actual), but a lower overall level of quality, integration, and performance... an issue its apps are already widely accused of. And iPhone, which has a tremendous lead in number of apps, loses out on a few — again, a fairly unpopular set which would have generally not fit in on the platform as well and would have slowed Apple's ability to require adoption of new platform capabilities.
It's hard to see the downside to Apple here. And it's hard to see how this does anything but make Android less attractive and iPhone more attractive for most mainstream (the overwhelming majority) users.
I think 3.3.1 is a smart choice from apple's perspective. They need to raise the barrier of entry into the app market and make developing apps more difficult, because there is currently an oversupply. Even if the clause turns away a ridiculous 70% of would-be app developers, I don't think apple will suffer.
Monotouch has been out since November 2009, Adobe CS5 isn't out for the iPhone yet, and as for Titanium I don't know the exact time period but it's not been long.
The only platform producing apps for a longer period of time has been Unity3D, which now advertises itself as having over 600 appstore games.
So your argument about raising the barrier to entry is weak, as these tools have only just emerged in the last 6 months. Prior to that we've seen thousands of poorly written, leaking objective-C applications on the AppStore. I've seen 2 RSS readers and the official digg.com app crash straight to springboard in the last 2 weeks, all written in objective-C.
Just because the language is closer to C and enforces memory management doesn't make its barrier any higher or require any greater skills - it means you'll get a tonne of apps that aren't releasing or reference counting and crash. I'm sure all this was hotly debated 10 years ago and garbage collection won.
If apple allows cross-compilation like that from titanium and adobe, then guess which platform gets the apps first? That's right - all the others!
Because apple is so slow and nitpicky with their approval process, if they allow this to happen their own policies will make sure they lose out to the less moderated platforms.
I think this is a good reason why apple is doing what it is. They want to maintain the app advantage as long as possible.
Seems to me there is an easier way - make your approval process better!
Apple may have other motives, but the effect of this is still positive; encouraging a higher standard of quality is a good thing for a massive platform.
Remember, Microsoft didn't do this with Windows. Where did we end up? For years, an incredibly bad user interface became the norm, with shaky programming APIs to match. Most 3rd party developers simply copied whatever Microsoft was doing (out of laziness?), causing other applications and APIs to also be horrible.
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
So it seems, at least from his comment and the context it was in, the intention of the clause is to remove layers that are other people's products.
There are two sides to the "hinders progress" claim. One is that, with an intermediary layer, new features added by Apple cannot be used by anyone relying on an intermediary layer to build iPhone apps until the maintainers of the intermediary layer add support for it. From what few comments we've gotten out of Apple, it seems they are trying to avoid a situation in which there is a large ecosystem of developers who are unable to directly exploit Apple's newest innovations on the platform, and instead work with least-common-denominator that their layer provides.
I think this is a totally reasonable thing to want.
The other side to this is that there is probably not a good technical way to make people obey. Innovation directly on top of a platform can involve abstraction into layers. For example, most of the best games all involve multiple layers of abstraction, in the form of a managed runtime for the game, some sort of scripting engine (or template/meta-language for specifying behavior), dynamic compiler (for shaders, AI and other tasks), etc.
The first thing a good programmer does when faced with a complex and uncertain problem is to build a grammar to express their ideas in on top of the foundation you're given. In C, this usually involves writing sets of routines that form a second (usually ad-hoc) 'language' that can be composed together to form complex ideas without having to hand-code everything over and over.
I see tons of bad and dumb Objective-C iPhone, iPad and Mac apps. It's completely possible to write first-class stuff in something other than Objective-C or C. ML variants, such as OCaml, SML and now even Haskell are speed demons in comparison to Objective-C. (The thing that makes Objective-C 'fast' is that when you need it to be fast, you just write the routines only in C, without message dispatching. Want to know how much fun it is to write GUI glue in C? Not very.)
I hope this means Apple is not going to start rejecting apps that are polished, fast, and innovative simply because they are built or expressed with tools other than C. I realize a lot of Flash->Objective-C compiled stuff would be crap. A lot of Objective-C stuff is crap, too. But some guy with his own hand-rolled Scheme runtime with message passing mapped onto the UIKit classes implemented with closures? If you reject that, you're going to piss off the very best developers, and dig yourself into the kind of hole that no technology company in history has been able to maintain mindshare once inside.
Addendum: if it's true that Apple's primary intention of removing layers is to keep their APIs and ecosystem nimble, then I would expect them to not reject games made with intermediary software, such as Unity3D. Games usually play outside of the main OS framework kits and are not as beholden to new UI features as normal application kit programs.
[+] [-] karzeem|16 years ago|reply
Anyway, the puzzling thing here is that as Greg says, most iPhone OS apps are written in one of the whitelisted languages already. Couple that with what I think is the likely fact that Apple is being honest about its motives (namely that it doesn't want its roadmap to have to consider third-party toolkits in any way), and it's confusing. Why would they go to the trouble of pissing everyone off to bring about a result that had largely brought itself about?
Two answers. One, I think Apple feared that more third-party toolkits are on the way, and that they'll become more popular. Two (and I think this is a huge part of it), Apple seems to have simply underestimated how mad this would make developers.
I wouldn't be surprised if the company went back on 3.3.1, or at least moderated it. Apple's only willing to be a jerk when it and the public agree about the level of jerkitude at hand. If Apple gets more ire than it was expecting, there's precedent for it backing down.
[+] [-] fab13n|16 years ago|reply
I guess Apple has been surprised by apps popularity. Their original policy was that 3rd party applications ought to be web apps (initially, it was the only way to go).
Embedded applications make sense:
* for super-tightly integrated user experience: but then, you don't want any lowest common denominator middleware on the way, as they guarantee a crappy experience (typically way worse than a decent and portable web app, see below).
* for driver-like stuff that do magic (but Apple always hated the idea of 3rd parties writing such sensitive code, which is one of the reasons why OSX is way more stable than Windows)
* because in some countries, users are stuck with a not-so-reliable 3G carrier, so being able to run offline is valuable. Hopefully that's a temporary situation, and I understand that HTML5 allows to write offline-compatible web apps anyway.
* because it's culturally accepted to pay a couple of dollars for a fart simulator app, but most people won't pay a dime to access the New York Times content in a web site. That's the reason why most apps are apps rather than web sites, but that's a problem with the web, not Apple's business.
This last point is at the core of most issues with Apple's tight control on iPhone apps: most of them should have been web app. They've been written as apps not to benefit from the iPhoneOS platform, but to benefit from the AppStore's easy monetization and publicity. It's about the AppStore, not about the iPhone!
[+] [-] reitzensteinm|16 years ago|reply
That said, I'd be surprised if Apple spends too much effort policing the rule. The fact that it exists in the first place will probably be enough FUD to prevent third party toolkits from taking off at all. They'll probably do some kind of automated signature testing for Flash, Unity etc and leave it at that. The upside of that is you'd probably be able to sneak a Clojure or whatever app in and nobody would probably care too much.
[+] [-] gaius|16 years ago|reply
I don't think is it. I remember when Metrowerks PowerPlant was the main framework. Apple had let their own MacApp and MPW languish. Arguably Metrowerks CodeWarrior saved the Mac as a development platform.
[+] [-] cmelbye|16 years ago|reply
[+] [-] greendestiny|16 years ago|reply
[+] [-] aerique|16 years ago|reply
I feel the same way about Safari on my iPhone. I quickly ditched that for a better browser.
[+] [-] DougBTX|16 years ago|reply
[+] [-] zppx|16 years ago|reply
[1]: http://trac.webkit.org/wiki/HighLevelOverview
[2]: http://trac.webkit.org/wiki/WebKit2
[+] [-] tumult|16 years ago|reply
[+] [-] lispm|16 years ago|reply
When Steve Jobs started with NeXT in the mid 80s he got a demo of a novel program that can be used to interactively design general user interfaces - the first program of its kind.
It was written in Lisp by Jean-Marie Hullot. It was called SOS Interface, marketed also as Action! by the company Expertelligence.
Steve Jobs hired him and Jean-Marie created the Interface Builder - which became one of the most important tool on NeXT OS. Then for Mac OS X and now for iPhone OS.
This innovation is now hindered by Apple. The innovative software may not be written in Lisp anymore, but it is not necessarily Objective-C either.
With the Mac everybody got a copy of HyperCard - everybody could write and design programs in a simple way - using the built-in HyperTalk. Xerox had such a software years before - called NoteCards and written in InterLisp-D.
With the iPad, which is much more capable than the Mac where SOS Interface and HyperCard were developed, everybody is degraded to be a consumer. The goal is no longer to be a maker, a creator, a programmer. You can't even use a shell to connect to your own iPad.
There is huge domain of visual programming and end user programming to be explored on touch screen devices. Maybe Apple is working on that and hiding this (like Jobs claimed that 'nobody reads anymore' and some time later Apple now sells iBooks) - from what we see now Apple hinders innovation and innovators in these areas.
I want a 'DynaBook' and not a media player.
Steve Jobs did not really understand what he saw at Xerox PARC when he got the demos of the Smalltalk system. He got the idea of the graphical user interface. But what he overlooked was the concept of object-oriented programming. He later with NeXT understood that. But what he never really got was the importance of interactive programming, end-user programming - the role of the user being able to program his computer in a straight-forward way. The cultural importance of being able to write, understand and change software.
[+] [-] rimantas|16 years ago|reply
Existence of iPad (and iPhone) does not hinder innovation — it fosters it. Three years ago there was no iPhone, no iPhone OS, no App Store. Now we have a new platform with not far from 200 000 (just think about it) applications written for it. iPad gives an opportunity truly explore what's possible on multitouch device with dedicated UI.
I am a web developer, but I do not complain that I cannot easily write my code in the browser itself. Nor do I want to.
Just think about it: if there were no iPad you could not code for it even in Obj-C.
[+] [-] raganwald|16 years ago|reply
There is no reason not to own a laptop and a tablet for much teh same reason that many people own an iPod and an iPhone and a laptop.
In my own case, I own a laptop for development, a mini for displaying media on my 37" display at home, an iPhone for calls and portable content consumption, and an iPod Classic for music in my car.
All of these together cost less than my first development system. I think that people who want to create content and programs will do so, and the iPad does nothing to hinder them.
[+] [-] Tycho|16 years ago|reply
[+] [-] clawrencewenham|16 years ago|reply
No innovation has been hindered, in fact it has been enabled. Smalltalk, SOS and others are tools that make certain kinds of experiment easier.
I remember when RAD tools were only meant for building prototypes, with the assumption that the program would be rewritten in a conventional language afterwards. They only became the delivery environment after consumer machines gained so much RAM and CPU power that the benefits of optimization became negligible.
Well, these are cell phones, batteries with CPUs. We're back in the 80s again. Section 3.3.1 does not prohibit anyone from developing iPhone software with whatever cross-compiler or funky toolkit they like, it only prevents them from deploying the output to consumers through the App Store.
[+] [-] jstevens85|16 years ago|reply
The point Jobs was making was that a device used exclusively for reading would never be successful. He wasn't suggesting that it would be pointless to participate in the ebook market, just that it would need to be on a general purpose mobile platform.
[+] [-] ghshephard|16 years ago|reply
But, for just a moment, I'm hoping that some of you can appreciate how miserable an experience Apple users have had with the couple decades of various levels of cross-platform development that Microsoft has done.
At times, those applications have been _so_ bad as to be an advertisement for windows. I'm an Apple fanboy, and own three generations of Apple MBPs, three iPhones, and, of course, an iPad - but to this day, at work, I still keep a 2003 class Windows XP system with Microsoft Excel on it to get work done - The painful experience that is Office 2008, (and don't get me started on "NeoOffice") single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
When I read Jobs's response, I could only imagine that he was having bad flashbacks to some of the x-platform disasters of years past.
I appreciate and respect that developers don't want to be told how to develop, but if the end result is that the few development shops out there capable of putting out a AAA title like Microsoft Excel, have to pony up a few more developer resources and put out a world class app directly for the iPhone OS, rather than just creating some half-baked x-platform experience, I'm in favor of 3.3.1.
[+] [-] Silhouette|16 years ago|reply
Well, OK, but the other possibility is that the executives at the few development shops out there capable of putting out a AAA title take one look at Apple's terms, observe that their entire investment could be arbitrarily yanked by another commercial organisation without compensation, kill the iPhone/iPad development before it starts, and target more open platforms that don't come with the same absurd levels of risk instead.
In the long run, the developers will always win, because someone will always make a platform where good developers can write good software, and then people will buy that platform to get that software. On the other hand, no-one cares about the platform, even if it's Apple, once the initial "Oh, shiny!" moment wears off and you actually have to get stuff done.
[+] [-] wvenable|16 years ago|reply
I'm not sure that proves your point here. Microsoft has had a Mac development team since the very first Macintosh. They write native software that is not a port of the Windows versions. In the past, IE for the Mac actually had more features (and was more standards compliant) than the Windows version. All this proves is that, yes, native apps can be crap. Which is exactly why this rule is entirely pointless. It's the not the development tool that matters, it's the developer.
> single handedly make me appreciate the fact that Apple is dictating that people write dedicated, high quality applications, directly for the iPhoneOS, rather than trying to do some crufty translation to that platform.
They're also eliminating any other tool or language which can also be written directly for the iPhone OS. Something like MonoTouch uses the iPhone API directly, it just happens to allow developers to use C# instead of Objective-C. No translation necessary.
Even Adobe Flash apps being recompiled for the iPhone isn't a big deal. A high quality Flash game like Bejeweled, for example, is going work great on the iPhone if Adobe did their job right. That is an opportunity for you to have apps you wouldn't otherwise have and it's not wasting programmer resources rewriting it to achieve the same result for nothing.
Rule 3.3.1 does not mandate high quality applications. If you want that, make Apple use their approval process for that instead of their own selfish interests. This rule does nothing to give you want you want.
[+] [-] vito|16 years ago|reply
[+] [-] csomar|16 years ago|reply
FireFox exists in my desk only because it has FireBug and a couple of other web dev. tools.
[+] [-] rimantas|16 years ago|reply
[+] [-] jbellis|16 years ago|reply
I've actually seen the benefits of the cross-platform approach first-hand, too. I've copied my same profile from mac to linux to windows and it Just Worked every time, extensions and all.
[+] [-] alanthonyc|16 years ago|reply
Thanks for emailing him.
[+] [-] ugh|16 years ago|reply
(I don’t really know whether Firefox is such a good example. It’s a great program because it first challenged IE, not because it’s anything close to a native feeling app. There must be better examples out there, right?)
[+] [-] mattparcher|16 years ago|reply
For developers, this is the person who knows nothing about programming yet insists that you use X tool and write it in Y language.
The author seems to imply that either Steve Jobs or Apple itself "knows nothing about programming". That seems wholly unfair, especially for Apple, and even for Steve. Obviously Apple employs some very talented programmers, or else we wouldn't be here talking about the iPhone. But surely Steve has a working understanding of the issue? Compared to Wozniak, he may have been the less technical of the two, but reviewing his history at Apple, Pixar, and NeXT, I think we can agree that he has a much better understanding of his products than many CEOs.
Apple knows what they're doing. As usual, they are just very conservative and arrogant, which I'm personally OK with (in general) because they make great products.
[+] [-] CamperBob|16 years ago|reply
It is, however, fair to say that Jobs is overlooking some very basic computer science. There is no reason why a tool like Flash can't emit Objective C, and there is no guaranteed way for an app reviewer to tell the difference.
[+] [-] endtime|16 years ago|reply
[+] [-] fab13n|16 years ago|reply
Yet the TOS are useful, as a good set of guidelines: TOS compliance is very strongly correlated with chances of having your app accepted.
[+] [-] rimantas|16 years ago|reply
[+] [-] mclin|16 years ago|reply
This has happened before. It's called the web, and it's beautiful. Slow to adopt? Hells yes. But I love it because it runs everywhere.
[+] [-] commieneko|16 years ago|reply
And it does _not_ run everywhere. With lots of work, you can make it run a lot of places; enough to be worth the effort. It is certainly useful, but not _nearly_ as useful as it could be.
Ted Nelson, who created the term hypertext, famously said, "HTML is precisely what we were trying to PREVENT-- ever-breaking links, links going outward only, quotes you can't follow to their origins, no version management, no rights management."
While politically I myself am very much in favor of open standards, for reasons I shouldn't have to explain _here_, I'm also vastly disappointed in the quality of most of the results, if from no other viewpoint than a human factors one. Like the talking dog, proponents seem happy that it talks (works) at all, and don't seem nearly concerned enough about what it's saying...
[+] [-] raganwald|16 years ago|reply
If Apple wants to build hardware acceleration for CSS animations on iPhone, it does so. If Apple wants to fix a bug in Javascript, it does so. If Apple wants to close a security hole in Safari, it does so.
Whereas if Adobe feels like making Flash slow as shit on OS X, it does so. If Adobe doesn't feel like fixing a bug on OS X, it doesn't fix a bug on OS X. If Adobe can't be bothered to fix a security bug on OS X, Adobe leaves a huge security hole open on OS X.
The web is a "worse is better" alternative to native iPhone apps, but at least it's open and offers opportunities as well as dangers for Apple.
[+] [-] metachor|16 years ago|reply
I've always seen Jobs as being highly principled and opinionated about the technology he helps create, but not particularly greedy (it is perhaps fortuitous that his principles have contributed to Apple's financial success).
I get the impression that Section 3.3.1 was changed as-is because Jobs honestly believes that restricting use of cross-platform toolkits and compatibility layers will help keep the iPhone platform and AppStore true to his vision of what those platforms "should be" (whether or not this is actually the case). I also don't think Jobs is explicitly trying to lock developers into the Objective-C/Cocoa development platform (though this might be a welcome side-effect of this decision from Apple's POV).
Philosophically I don't agree with Section 3.3.1. However I can see, on the one hand, how it fits in with what I understand of Jobs' character and motivations about his technology. And on the other hand I can see how it makes good business sense for Apple in the short-term. In the long-term it may not work out as well if it induces a developer-exodus. But since Jobs is paying attention, we'll see what happens when that time comes.
[+] [-] cheald|16 years ago|reply
"Intermediary layers" are what make modern programming productive. We don't all write in processor-specific assembler because it's not (developer-time) efficient, and because we can accomplish a given task without having to resort to such a low level. For example, it's far more efficient to write in higher-level C and compile for the platform as necessary. The entirety of the software development ecosystem is "intermediary layers". C compiled to a platform target with GCC is sure as hell an "intermediary layer".
I can't help but think that what Jobs means here is "intermediary layers that aren't ours automatically produce inferior products". What an arrogant line to feed to developers. At least he's being direct (if not honest) with Apple's intent to fully lock developers into the Apple-blessed toolchain, from the initial concept to the final product. Ugh.
[+] [-] jstevens85|16 years ago|reply
Is that not true though? In most cases, apps that use an intermediary layer will not be as polished or usable as an app developed using the native tools.
[+] [-] Tycho|16 years ago|reply
[+] [-] yankeeracer73|16 years ago|reply
[+] [-] wallflower|16 years ago|reply
As for the other build an iPhone app application frameworks, the quality of the finished product varies from lackluster to average. At the worst, the finished app looks like one of the RSS reader apps that Apple is now trying to filter out of its AppStore. At the best, it's something like Location Scout. I believe by limiting access to third-party application builders, Apple is going to continue to increase the quality of iPhone apps. Titanium, Adobe et al will never generate anything like Tweetie 2. And, I believe Apple wants more Tweetie 2-caliber applications. To increase the S/N ratio. I believe Apple wants less crap and cookie cutter applications, even though some of the top 25 Free and Paid lists may from time to time have those types of 'Fart' type apps.
Apple is a premium brand. Even for developers. There are barriers to developer entry. It is kind of a privilege to write iPhone apps as you need $99/yr and an Intel Mac. The Cocoa/UIKit framework and CoreData persistence are tools that Apple engineers have invested centuries of programmer years in developing. There aren't many private APIs in Apple land; almost all of the standard iPhone apps could be recreated by third-party developers. And now with OS 4.0, I believe only a small fraction could not be recreated. As another example, Titanium et al. are not using CoreData - CoreData is designed to make managing and persisting an object graph easier. Which is what you need for non-cookie cutter applications. I have yet to find one application built on RhoMobile, Titanium, Ascena etc that leverages CoreData.
And, I wouldn't be surprised if they start rejecting apps for quality (as in what does this app provide that is of value).
"He downloaded Titanium on a Saturday morning, and by Sunday night he had a functional prototype of his Location Scout app..."
http://www.appcelerator.com/partners/case-studies/locationsc...
http://labs.adobe.com/wiki/index.php/Applications_for_iPhone...
[+] [-] rimantas|16 years ago|reply
A couple of telling examples: http://adobegripes.tumblr.com/post/296745150/photoshop-why-i...
http://adobegripes.tumblr.com/post/236090781/the-many-slider...
[+] [-] mclin|16 years ago|reply
Any environment where you're working with JavaScript (or Ruby, or Python...) is going to have faster dev time than working with a compiled language. It's not just having to type way less, but less brainless typing leads to better flow.
I'm doing both right now, and I love Titanium because it gets me in the zone, whereas with ObjC, so often I have to turn on autopilot to get through the boring stuff when I create a new model or class or something.
[+] [-] glenra|16 years ago|reply
Getting a functional prototype to work should be simple and fast. (There's a big difference between a functional prototype and a finished product!) The fact that it's not fast using the Apple toolchain is exactly what's wrong with them. Developer time/effort is limited. A good dev environment should make the common stuff easy; since Apple seems disinclined to provide tools that do this themselves, our big hope for improvement in that regard was that third parties would get in there and fix the problem with products like Corona or Titanium.
[+] [-] jimbokun|16 years ago|reply
Could they somehow say that programs must use native CocoaTouch widgets, while still allowing for people who want to compile from Scheme into Objective C or C?
[+] [-] glhaynes|16 years ago|reply
What will the results of this be?
* Lots of Flash content gets released on Android. This expands Android's software market considerably, though with a cost in performance/platform-integration (both in terms of UI and in terms of taking advantage of low-level capabilities).
* Many of the best/most popular and money-making Flash apps will get an iPhone OS-native port. The cost to write an iPhone app is relatively low; if you're talking about a game, the vast majority of the cost is usually in the assets. The iPhone developer tools are very good, there are lots of developers: finding an iPhone developer willing to make a native port of your game engine isn't difficult or expensive relative to the number of users you open up your investment to. Thus iPhone potentially gets the best version of many originally-Flash apps.
Thus, Android continues to have more possibilities (theoretical and, in some cases, actual), but a lower overall level of quality, integration, and performance... an issue its apps are already widely accused of. And iPhone, which has a tremendous lead in number of apps, loses out on a few — again, a fairly unpopular set which would have generally not fit in on the platform as well and would have slowed Apple's ability to require adoption of new platform capabilities.
It's hard to see the downside to Apple here. And it's hard to see how this does anything but make Android less attractive and iPhone more attractive for most mainstream (the overwhelming majority) users.
[+] [-] steve19|16 years ago|reply
[+] [-] metamemetics|16 years ago|reply
[+] [-] schemas|16 years ago|reply
The only platform producing apps for a longer period of time has been Unity3D, which now advertises itself as having over 600 appstore games.
So your argument about raising the barrier to entry is weak, as these tools have only just emerged in the last 6 months. Prior to that we've seen thousands of poorly written, leaking objective-C applications on the AppStore. I've seen 2 RSS readers and the official digg.com app crash straight to springboard in the last 2 weeks, all written in objective-C.
Just because the language is closer to C and enforces memory management doesn't make its barrier any higher or require any greater skills - it means you'll get a tonne of apps that aren't releasing or reference counting and crash. I'm sure all this was hotly debated 10 years ago and garbage collection won.
[+] [-] corruption|16 years ago|reply
Because apple is so slow and nitpicky with their approval process, if they allow this to happen their own policies will make sure they lose out to the less moderated platforms.
I think this is a good reason why apple is doing what it is. They want to maintain the app advantage as long as possible.
Seems to me there is an easier way - make your approval process better!
[+] [-] makecheck|16 years ago|reply
Remember, Microsoft didn't do this with Windows. Where did we end up? For years, an incredibly bad user interface became the norm, with shaky programming APIs to match. Most 3rd party developers simply copied whatever Microsoft was doing (out of laziness?), causing other applications and APIs to also be horrible.
[+] [-] tumult|16 years ago|reply
We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.
So it seems, at least from his comment and the context it was in, the intention of the clause is to remove layers that are other people's products.
There are two sides to the "hinders progress" claim. One is that, with an intermediary layer, new features added by Apple cannot be used by anyone relying on an intermediary layer to build iPhone apps until the maintainers of the intermediary layer add support for it. From what few comments we've gotten out of Apple, it seems they are trying to avoid a situation in which there is a large ecosystem of developers who are unable to directly exploit Apple's newest innovations on the platform, and instead work with least-common-denominator that their layer provides.
I think this is a totally reasonable thing to want.
The other side to this is that there is probably not a good technical way to make people obey. Innovation directly on top of a platform can involve abstraction into layers. For example, most of the best games all involve multiple layers of abstraction, in the form of a managed runtime for the game, some sort of scripting engine (or template/meta-language for specifying behavior), dynamic compiler (for shaders, AI and other tasks), etc.
The first thing a good programmer does when faced with a complex and uncertain problem is to build a grammar to express their ideas in on top of the foundation you're given. In C, this usually involves writing sets of routines that form a second (usually ad-hoc) 'language' that can be composed together to form complex ideas without having to hand-code everything over and over.
I see tons of bad and dumb Objective-C iPhone, iPad and Mac apps. It's completely possible to write first-class stuff in something other than Objective-C or C. ML variants, such as OCaml, SML and now even Haskell are speed demons in comparison to Objective-C. (The thing that makes Objective-C 'fast' is that when you need it to be fast, you just write the routines only in C, without message dispatching. Want to know how much fun it is to write GUI glue in C? Not very.)
I hope this means Apple is not going to start rejecting apps that are polished, fast, and innovative simply because they are built or expressed with tools other than C. I realize a lot of Flash->Objective-C compiled stuff would be crap. A lot of Objective-C stuff is crap, too. But some guy with his own hand-rolled Scheme runtime with message passing mapped onto the UIKit classes implemented with closures? If you reject that, you're going to piss off the very best developers, and dig yourself into the kind of hole that no technology company in history has been able to maintain mindshare once inside.
Addendum: if it's true that Apple's primary intention of removing layers is to keep their APIs and ecosystem nimble, then I would expect them to not reject games made with intermediary software, such as Unity3D. Games usually play outside of the main OS framework kits and are not as beholden to new UI features as normal application kit programs.