Steve Jobs’ Response: A Brief Followup

The attention that yesterday’s post received is astounding, but unfortunately from the looks of it a lot of people seem to have a poor understanding of the situation. I feel compelled to address some of the sticking points.

On MonoTouch and other 3rd Party Tools

Some people appear to be under the mistaken impression that these changes are designed to prevent Java-like “non-native” UIs on the iPhone.

To be clear, the situation on the iPhone is completely different from that of the Mac. From the user’s perspective, you cannot tell the difference between an application written using MonoTouch or NimbleKit or Unity3D (non-Apple sanctioned tools that allow developers to code for the iPhone in non-C languages), and those written using Apple’s tools and Objective-C.

They look and feel exactly the same.

This is because they’re all using Apple’s UIKit to display the UI. In the case of Unity3D, which produces OpenGL games, you can’t tell whether the game was made using Unity3D or directly in Xcode, so it’s dubious that this is solely about “quality control” and keeping a uniform UI. If that was their sole motivation they could simply mandate that all non-OpenGL user interfaces make use of the native Cocoa frameworks and widgets.

Is it possible that these applications might be somehow better, perhaps faster, were they written directly with Apple’s tools? Maybe. Is that reason enough to outright ban them though? There are already hundreds of apps on the AppStore built using Unity3D, some of which are best-sellers.

There appear to be rumors online that even the Tap Tap Revenge game that Steve demoed during the iPhone 4.0 keynote is partially written in the Lua programming language. Oops.

It’s not surprising though (if true), because many popular games use a non-C scripting language for their game’s logic. It’s a versatile and common practice that gives developers (and even users) flexibility and creative freedom.

Whether Apple will remove these games I don’t know (I doubt it really). If they don’t, it’s hypocrisy because the wording of Section 3.3.1 clearly forbids it, and if they do then a bunch of great apps get pulled, a bunch of great developers get screwed, and a bunch of users are left disappointed. Even if they don’t pull these apps, Section 3.3.1, in its current state, is likely to deter future developers from taking advantage of these powerful techniques.

On Firefox

Many commenters seemed to be confused as to why I brought up Firefox. That discussion was tangential to the issues with Section 3.3.1. Steve referred to the “intermediate layers” that have existed on the Mac, suggesting that they all ultimately lead to sub-standard applications:

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.

Though there is truth to that I feel it is only half the story.

The question isn’t whether you agree or disagree about the quality of cross-platform applications, but whether they should be allowed to exist on a platform at all (please don’t forget we’re still talking about the Mac, not the iPhone, where most, if not all, 3rd party toolkits produce native-looking applications).

As far as the Mac is concerned, I’m grateful for the existence of high quality cross-platform software such as Firefox. A lot of people were puzzled at why I chose Firefox as an example of high-quality cross-platform software, the reason is simple: it fulfills my needs for web browsing better than every other web browser.

Only because so many people brought it up, here’s a brief list of features that explains why I feel this way, and please note that I consider the availability and quality of plugins/add-ons as part of the browser’s whole:

  • The Firefox AwesomeBar is awesome. It’s like Spotlight for your web browser.
  • Firefox’s bookmarks allow both tags and descriptions, which I make heavy usage of.
  • I love Firefox’s find-as-you-type feature.
  • I can drag my Firefox data folder to any machine on just about any operating system and everything will just work there.
  • I’ve noticed that Firefox uses far less RAM than Safari on my MacBook Pro. Where Safari will use upwards of 1.5GB of RAM, Firefox will use only about 800MB for the same “level of browsing,” and it’s far better about clearing that out when you close windows. To those who claim the opposite to be true, I suggest you delete your Firefox application support folder and reinstall the latest version.
  • Firefox’s diverse and remarkably powerful addons are my #1 reason for using it. Many of the addons that I use have no equivalent on other browsers, and this simply seals the deal for me. Some of my personal favorites, in no particular order, include: Tab Mix Plus, ProxyButton, Session Manager, URL Link, WikiLook, Adblock Plus, BlockSite, DownloadHelper, Firebug, and Greasemonkey.

Why does Firefox have so many awesome add-ons while Safari and other browsers do not? Oh, that’s right, it’s because Firefox runs on just about every operating system, and the addons are cross-platform as well. Firefox’s users thereby reap the benefits that an open platform and an army of developers provides.

Sure, Firefox doesn’t integrate with OS X’s Services and other Cocoa-only things, but for me it more than makes up for those relatively benign flaws, and I’m grateful to have it prominently displayed in my Dock.

EDIT: It appears the latest versions of Firefox do integrate with OS X’s Services. Some minor Cocoa functionality still appears to be missing (like the Dictionary lookup shortcut, though there are add-ons for that), but this is certainly a pleasant surprise. I could only find this two year old article referencing the changes.

Conclusion

Don’t let the digression on Firefox fool you into thinking that I’m demanding Apple allow XUL apps like Firefox on the iPhone. That’s not what Section 3.3.1 is about.

Section 3.3.1 bans applications that look and behave like all the other “native” apps on the iPhone, but are “originally written” in languages other than C/C++/Objective-C. Details here and here, and there’s also this excellent 37signals post.

Update (4/12/10): Existing iPhone Apps Breaking the TOS

Update (9/10/10): Eventually, Apple updated and relaxed their terms.

27 thoughts on “Steve Jobs’ Response: A Brief Followup

  1. Chris Allen

    Thanks for pointing out the very common practice of using intermediary tools when creating 2D and 3D games for the iPhone platform. In addition to Tap Tap Revenge using Lua, it’s been rumored that EA uses Lua in its games production as well. Why is that any different than our company using Unity3D for our games? Will Apple put a stop to all of EAs games as well? The idea of limiting the tool set of a developer is preposterous, and I fully am behind your point of view.

  2. Josh Presseisen

    Ravensword: The Fallen King was made with Unity3d and was featured as one of the best games of 2009 by Apple themselves, in their ‘iTunes Rewind: Best Games of 2009′
    The game was also featured several times in various places on the App store. I can’t imagine why they would want to ban Unity and hinder us from making Ravensword 2, an even bigger and bolder RPG for the iPhone/iPod Touch/iPad. This news is very disturbing – considering we’ve been plugging away at it, (and other games) using Unity for the past several months.

  3. Nicolas Goles

    Almost every gamedev in the industry and a lot of indies use scripting languages like LUA, to leverage the power of their engines. It’s a very common practice.

  4. folle rec

    I think Steve Jobs’ worry is that, what if they implement something new, something that requires some recoding to make apps support that new feature. For example, multi-tasking. Then they release the new OS.

    For most of the popular apps written in Objective-C/CocoaTouch, they can easily update their code, submit it, and the new feature is supported.

    For apps that use intermediary tools, they’ll have to wait for the tool maker to support that new feature. What if it takes them months? Worse, what if they don’t implement at all? Or half-worse, what if they implement it but don’t get it right, but think they do?

    If an app using the intermediary tools were popular enough, it would annoy the hell out of their users. Instead of having the new features supported correctly from the get-go, users have to go through an annoyance phase.

    I get your point though about flexibility, etc. But for the common person, I don’t think this flexibility is important. They’d rather have something that works and works well. Flaws are more noticeable with something as intimate as the iPhone.

    However, I think Apple should change it to accept gaming engines for games. I do think that standard apps that use standard UI interfaces should be restricted for the reasons above.

  5. Paul Sorensen

    So would a MonoTouch app for the iPhone and iPad have exactly the same code as the same app for an Android device?

    Unless the answer is “no” then you are mistaken that “they look and feel exactly the same”. Some things are done differently on an iPhone then they are done on an Android phone. And unless the app taylors to the platform then they will not “look and feel” exactly as apps written specifically for their host OS.

  6. Greg Slepak Post author

    @Paul: The answer is no, they don’t have the same code. MonoTouch tailors specifically to the iPhone OS.

  7. James Tarpley

    These are very interesting points of view – as a user (vs software writer) I have a slightly different point of view, more in agreement with Apple. I appreciate the software developer’s issues and agree with their desire for freedom to innovate. I also agree that Firefox offers features and speed that Safari does not. That said, I prefer to use Safari. Why, Safari offers greater GUI standardization or consistency with other core Apple apps. Users want standardized consistency between applications – that has been the beauty of the Mac OS and the core Mac apps and the standard by which users judge non-Apple written apps. iPhone, iPod, & iPad mobile apps intrinsically need to adhere to the standards as prescribed by Apple in order to provide a consistent and stable user experience – this is vital to user satisfaction as well as to the success and viability of the platform. And, is this not this not essential to the “app” purchase experience, that the purchaser knows that the app will conform to expectations – after all, the user purchases most apps, if not all, without prior trial use.

    Furthermore, software writers and developers should appreciate that the majority of Mac users (as well as iPhone, iPod, etc users) are attracted to the format not because of applications you might write, but because of the platform and devises that Apple has provided. As a stockholder, I agree that Apple has every right to protect the platform; as a user, I insist that Apple has an obligation to assure the user a satisfactory and predictable experience. That should not and does not preclude innovation. Otherwise, I would have been using a Wintel PC since 1984 instead of a Mac.

    Thanks

  8. Paul Sorensen

    @GregSlepak Ok, so you’re saying that a developer would change the code of their “MonoTouch” app in order to tailor it for “MonoAndroid” (if/whenever that exists) and vice-versa. And that the code would be completely tailored to the host OS.

    If that is the case then I agree with you.

  9. Dai Jones

    “Sure, Firefox doesn’t integrate with OS X’s Services and other Cocoa-only things”

    That’s exactly why Apple doesn’t want people using these toolkits, surely. Not integrating with Cocoa features on MacOSX is a pain, but not the end of the world. In the more restricted context of the phone OS it’s vital that apps play nice with the operating system in terms of performance and battery life; and important for Apple that when they introduce new “tentpole” features apps are able to be quickly made compatible with them.

    It is indeed not about the look and feel of apps, that can be simulated in a ported flash app to some extent. It’s about how the app links with the OS, and a toolkit producing pure ARM code without reference to the latest versions of Apple’s APIs is going to cause problems.

  10. Greg Slepak Post author

    @Paul, yes that’s correct, glad we’re on the same page. :-)

  11. Parker Bennett

    Comparing the Mac platform to the iPhone platform is like comparing Apples to, well, severely memory- and storage-constrained Apples. I think Gruber did a good job highlighting this as the underlying reason why non-native code was going to be a problem for the iPhone, especially as they move forward with 4.0 and multitasking. Just because there are good examples on the Mac like Firefox and Ableton Live, these have no bearing on the iPhone platform. While I feel the frustration of Unity developers and Flash coders, I also know a lot of old Director Lingo programmers who learned to move on. Is it not possible for Unity to create a development platform specific to the iPhone?

  12. John C

    I know that Nokia has discussed porting the Qt C++ multi-platform development framework to the iPhone/iPad. Does the new Apple TOS preclude Nokia from porting to the iPhone/iPad? This would be a shame because Qt is a quality product that has supported the Mac (both Carbon and Cocoa) over the years. (As an example, Google Earth is written in Qt).

  13. Jason Baker

    Isn’t it already a violation of the of the EULA for a game to use Lua? I know that Apple forbids programs from interpreting or compiling a programming language.

    I seem to recall a game console emulator of some kind getting rejected because it contained a BASIC interpreter.

  14. Micah

    I’m writing a cross-platform game in C++ that will be released for iPhone (hopefully) and Android using a framework called Airplay SDK. Although I’m writing it in C++, I’m not actually using Apple’s tools for it (in fact, I’m even working in Windows for most of it).

    And not only that, both the iPhone version and the Android version use the exact same source code. Of course, that doesn’t stop me from tailoring parts of the game to iPhone-specific stuff and parts to Android specific stuff, by doing if(running on iphone) { do this; } else { do this; }.

    There are a lot of really crappy apps that have been written in Obj-C with Xcode, and there are a lot of good apps that have been made with Unity3D and other development tools. Forcing developers to use one tool over another has nothing to do with the quality of the apps, at all.

    Part of the reason I’m looking into ways to develop cross-platform apps in the first place is because of Apple’s attitude towards the iPhone keeps getting eviler and more closed.

  15. Thomas D

    Steve Jobs has a controlling personality. He wants control to protect the Apple brand name. He also wants control because he is paranoid of what would happen otherwise. Apple is and always has been one of the most secretive, closed, and arrogant high tech companies in the world with a knack for user experience and usability. They benefit from this with brand loyalty. On the other hand, they will eventually lose out as soon as another competitor offers a similar software, hardware, and ui experience. Closing up the iPhone is a mistake, but it will not be realized as a mistake until other platforms compete. In about 1 to 2 years, the mistake will be obvious, and Jobs arrogance will prevent him from changing the clause.

  16. Dustin Sparks

    @Parker Bennett Just to be clear, Unity DOES have a development platform specific to iPhone. It’s called Unity iPhone, and generates code that can be modified extensively using XCode with Obj-C and OpenGLES experience. In order to publish to iPhone, you actually have to compile your Unity projects with XCode.

  17. altrenda

    @James Tarpley ” Furthermore, software writers and developers should appreciate that the majority of Mac users (as well as iPhone, iPod, etc users) are attracted to the format not because of applications you might write, but because of the platform and devises that Apple has provided”
    Sorry, but this is B.S. Watch the many iPhone ads, what is featured? The hardware? Almost never. Apple promotes the apps, uses the vast quantity of apps to sell it’s hardware.The platform, as good as it might be, is just a vehicle to run apps, otherwise its just aluminum, glass, and plastic.
    There’s an App for that. Not, there’s a phone for that.

  18. Lyman

    I think a significant amount of the friction against the change could be removed if Apple just changed

    “Applications must be originally written in …”

    to

    “Applications must be innovatively written in …”

    To see what getting at on a Mac go to the dictionary app and look up the word “originally”. There are two connotations of that a word. The first is the identify the origin of something. The second is to be novel or innovative.

    That is what the core issue of the real debate should be about. Whether to follow a restrictive, narrow path to applications or a novel and innovative path.

    From the example cited later in 3.3.1 it seems likely that Apple wants to choose the first meaning. As Gruber’s article points out this is at the core issue about vendor lock in. (not quality user experience, vendor lock in. Developers much narrowly follow Apple’s path no matter what they choose to do. )

    Note that this restriction bans not only Flash but utilizing assembler for any critical section of code. It bans both faster and slower approaches the construction of and execution speed of apps. That is primarily because it is about restricting the origins of the apps rather than any quality goal. Almost all of the hand waving about quality lapses into subjective judgments on narrow subareas of user experience.

    If the application is developed using a slightly different language with some syntactic sugar that is more oriented to the problem domain than raw Obj-C/C/C++ are then what is the hang up if the syntactic different is pre-compiled into Obj-C/C and an application is built ? There is no difference.

    Second, this is even somewhat hypocritical on Apple’s part. Two examples.

    1. XCode tools UML code generation abilities. Apple itself builds tool to take elements of a program written in a representation that supports better long term maintainability and automatically generate code from that. There is zero reason to keep software development in the stone age where the sole valid representation of the development is text in some file. For substantive elements of many application text isn’t necessarily the best long term representation of the application that provides the clearest representation to the developer.
    [ In the Gold Rush , "throw away" AppStore perhaps that is a secondary issue. ]

    2. iTunes and Safari on Windows. If Apple is so dedicated to its core on user experience how come those aren’t rewritten from scratch, pure Windows user experiences ?

    Organizations that have very large code bases to port typically can’t afford to start over from scratch to built a very that is a a port. They will typically use some combination of tools or techniques to bring over the bulk of the application between platforms.

    For example, a Flash to Javascript/HTML5 translator could perhaps do 50-90% of the translation leaving just the remaining percentage to be manually translated.
    ActionScript 3 is a dialect of EMCAScript (http://en.wikipedia.org/wiki/ActionScrip_3). So is Javascript. Related in a similar what to how Obj-C is to C. What Apple has done here is ban anyone who wanted to do a port but try to reuse the maximum practical amount of code.

    Adobe was doing something different. I suspect they were compiling straight to binary so they’d still be banned with the change. However, there were other tools that were trying to do things the right way. Apple banned them to by focusing more so on being an obstructive than fostering innovation in doing things the “right” way.

    So when folks howl about Adobe being slow to 64-bit ( even after Apple canceled Carbon-64 after stating they would do it. This also follow 68K to PPC transition and Mac OS 9 to Mac OS X transition which all had associated migration costs.). The thought experiement should be if you were given a code base of 3-6 million lines of code and told to port from one API to a new incompatible one how would you do it.
    Would how long the code base been in existence have any impact on your decision ( 2 year old app versus a 8 year old app. ) ?

    Finally, Meta framework often fail because they are too broad. A framework for any and all applications will have problems. That is not necesarily true if you narrow the scope. If aim the framework at multiplatform word processing apps or multiplatform IM app then the constraints on GUI concepts can become tight enough that can compose in an abstract RAD environment and generate very close to native representations. Again Apple has thrown that out the window because tools can’t be utilized to compose applications.

    Apple doesn’t care because just want vendor lock-in. Squashing innovative approaches to composing apps isn’t their problem. The AppStore has too many apps. They really don’t need any more to make lots of money so they are taking the calculating step to squash an even higher rate of growth which happens to also negatively impact their competitors.

    P.S. The timeliness of porting programming frameworks isn’t a problem if the framework developers are clued in eariler in the process. Similar to how the Wall Street Journal got iPads when the rest of the vast developer base was stuck with a not quite so accurate simulator.

    In the iPhoneOS 4 demos the developers said most of the changes were localized and took hours/days to make the changes. It isn’t like Apple would have to release info under NDA months in advance. If the tentpole changes are present in the commonly generated code by the tool then the next build will easily pick them up.

    In short there really are very few technical issues here that block good, high quality apps here given that the tool makers are just as dedicated to app quality as the developers who use them are.

    This is primarily a power, money move on Apple’s part.

  19. Greg Slepak Post author

    @Jason Good point, which means they’d actually be violating two parts of the agreement: 3.3.1 and 3.3.2.

  20. Rupak Ganguly

    After I bought my first iPod, I had no doubts buying when the iPhone was released. Apple products have an impeccable sense for user experience. Everyone wants to own an iPhone and every developer like me would like to write apps for it. It is very disheartening to see Apple’s stance towards banning cross-platform toolkits to build iPhone apps. I was drawn to buying a Mac to build apps for iPhone because I could work with my familiar toolkit/language. iPhone SDK was the first sign that Apple wanted to care and welcome developers to write code for its so called closed platform and several cross-platform toolkits were announced and flourished. The TOS Section 3.3.1 announcement is just closing the doors on the developer community. It is not only a loss to the developer community but to the user community as well. I hope the situation is reviewed and rectified by Apple. It is a humble plea…

  21. Lyman

    Chuckle, Just happened to bump into this after seeing Flash HTML5 Canvas pop up on twitter as a trending topic.

    http://www.readwriteweb.com/archives/flash_now_importable_to_hmtl_canvas.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29

    Notice that this too is banned by 3.3.1 . Flash/Actionscript dialect is being translated by into HTML5/Javascript by the Adobe tools (not at run time but prior to deployment). It is being written but doesn’t originate in Apple specific Javascript.
    Sure Adobe is also pushing the Flash translation/glue adaptor (and are taking opportunity in associated video to so that performance is actually better), but that isn’t sole translation they are supporting.

    The developer has a set of choices on how to deploy the simulation in the video. There are different tradeoffs for each one. In some cases that translation may be applicable and in others not. The terms of a SDK contract is a rather curious place to resolve those tradeoffs.

  22. Steve

    Just my cross posted thoughts.

    Certainly terrible for Flash (cross compiler approach). I do think many people are reading into this way to much. This does not prevent game middle ware such as Unity. Unity creates a xCode project to be compiled by the apple tool chain. The scripts are compiled to ARM assembly and do not link against the Coca libraries as far as I am aware. They are only for controlling the game engine. I would imagine every major game studio does the same (no embedded scripting allowed).

    The 3.3.1 article in question states ‘originally written’. This does not imply nor does it explicitly state a human had to write the code. If that were the case then you could not use xCode or IB to write code for the iPhone. Translators and generators at the source code level are fine. The input to these tools is irrelevant. You are free to use whatever language you wish to compile to ARM assembly for use in your own code. You can not however link against the frameworks. You can use C# to write algorithms, compile using GCC/LLVM to object code and then link this object file in your final executable. No issues.

    What they are preventing is intermediaries. They are preventing tools/middleware from acting as an intermediary during the compilation process of languages other then the ones specified. This is the reason for the term ‘link’ and the clarification that follows this sentence.

    If anything apple need to specifically state the terms in language that is far from interpretive.

  23. Anon

    I think the biggest issue with Section 3.3.1 is that it prohibits the use of other tools. Specifically, look at the tool OpenPlug ECLIPS. It allows a developer to write in Flex/AS3 and it in turn translates that and generates a native Object-C app. You then have to compile that on a Mac with XCode. So, how is that bad? But according to 3.3.1 we can’t do that anymore. Its a horrible move by Apple.

    Lastly, what about:

    Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

    Does this mean we can no longer call Facebook, Twitter, or Google API’s? What about calling my own API in my cloud that allows me to get data back for my custom app?

    Apple has really messed up here.

  24. Mjk

    I just love a good fiction writing. Steve and his replies. :) Just cracks me up.
    (still not convinced that that is Steve in those replies … but you make a lot of good points)

    Although I am not a big apple fan, i am a developer. And for apple to cut me of tools such as mono for cross platform dev is completely absurd.

    Why should i rewrite all the libs that already exist and add thousands of lines of untested code if there is already tested and widely used libs for it.

    Simply don’t see any of devs who have extensive experience to switch to strictly iphone dev if it is easier to develop for symbian, Maemo, android and palm with cross platform tool (write once, …).

    Oh and btw: Nokia found the hard way that closing your platform is bad for business. Once a giant nobody could touch is now abandoning Symbian for Maemo on smart phones …
    As for google goes: If it wasn’t for the privacy issues it would be a model, how to be a company. It helps developers not only with opening code to its platforms, but also by publishing libs that help development. And as my vote goes it wins over apples “Mine … all mine’ attitude. Even if they have the prettiest of phones.

    (google fan :) )

  25. Per Arve

    Technologies like flash is used to make products like farmville that catches a lot of users. On a device with a lot of power, such inefficient products may be ok, but on the devices we are addressing here, it is not.

    I can hear when my wife is onto farmville because the fan of her computer is running high. How come such simple functionality uses so much power?

    Please, use my battery with care.

    I think much of the response seen above come from seasoned developers protecting their personal investments.

    Modern devices should not be burdened with old paradigms. New developers should not be led to follow older colleagues bad habits.

    On the same note, objective-c is of course not necessarily the final point of computer languages. The point worth attention is, how to promote battery saving and developer friendly coding practices.

    Address that and you will surely get Apples positive attention.

  26. Lawrence Rhodes

    Would it be possible for one of these banned development environments to change to a preprocessor and output Objective C source code? That would seem to be a way around the ban.

    For me, Firefox’s main shortcoming is that copying rich text from it doesn’t work well, where Safari is very good. I have a habit of saving snippets from websites and prefer their original formatting.

  27. Greg Slepak Post author

    “Would it be possible for one of these banned development environments to change to a preprocessor and output Objective C source code?”

    @Lawrence, that’s exactly what Unity3D does, and no, that’s not a way around 3.3.1, which explicitly forbids that because the game was “originally written” in a language other than C/C++/Objective-C. Plus, if this were OK, Adobe would be able to use this technique to get their stuff on the iPhone, which seems to be exactly the scenario 3.3.1 was designed to block.

    Regarding Firefox, I actually prefer how Firefox does copy/paste: http://cl.ly/Hws

Comments are closed.