Thursday, April 8, 2010

Steve Jobs just ruined the iPhone for Clojure

Recently Apple released new terms of service with their  iPhone OS.  By now most of you have seen the following section.  I've copied this from Daring Fireball
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).
I'm pissed off.  I believe the hype, and there's a lot of HCI experiments I'd like to do with the iPhone & iPad.  There's a ton of opportunities & ideas, waiting to be discovered.  Being able to do these experiments in Clojure would be some much fun, that it's worth the $500 investment.

If I'm reading the TOS, we can't have a version of Clojure on this platform.  Any ideas I have - no, we have - now can't be shared with the world.

This is NOT thinking differently Apple.

22 comments:

  1. "This is NOT thinking differently Apple."

    It's not? Can you give another example of a similarly idiotic restriction imposed by some other company?

    ReplyDelete
  2. I'm hoping the wepad, android based, will give a good experience while allowing jvm/dalvik bytecode work. If not.... yeah yuck

    ReplyDelete
  3. Yes. This is a really dirty move on Apples part. I feel sorry for the people who have already invested in alternative programming for the iPhone. Ordinary guys who've quit their day jobs to pursue a career writing iPhone apps who've now had their work rendered useless. Screw you Apple.

    ReplyDelete
  4. When clojure-in-clojure is there, I guess some smart guys (no I did not say chouser, did I ?) will jump in very quickly and port it to javascript (ClojureScript).

    I guess that "compiled" ClojureScript will be in fact javascript source code.

    I also see that Javascript code is accepted for the iPhone.

    So maybe there's still some hope to write ClojureScript one day, while delivering to Apple the result of the compilation to javascript as "the application" ?
    (maybe I'm way too naïve, though ...)

    ReplyDelete
  5. Would it be acceptable per the new agreement to have all the Clojure code as one or more libraries for a small glue application which would be written in Obj-C and link against the iPhone/iPad APIs?

    ReplyDelete
  6. Laurent: The approach you describe would not work under the terms as it violates the "originally wrtitten in" part.

    This has to be the most idiotic move by Apple so far.

    ReplyDelete
  7. MAC: yes, you may be right. I personnally wanted to understand this as: do not bother us with an additional "translation step" in our own build process.

    But that may already be the case, indeed.

    I can imagine that they do code review while validating the application, and that they are bothered by tons of generated code which may be hard to peer-review.

    Something like that.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete
  9. This also kills those Scheme games written in Gambit-C, which compiles to C....

    ReplyDelete
  10. What is preventing you from using Clojure for "HCI experiments"? This restriction only applies to released applications.

    ReplyDelete
  11. Pardon my ignorance, but does this new TOS apply for pre-4.0 OS, or just 4.0 onwards?

    ReplyDelete
  12. @AK

    Yes, I can whip up a prototype on my own w/o the App store. However, I consider public acceptance & all the social problems to be part of HCI. Yes, the mouse was invented in the 60s. However, it wasn't until everyone was using them that the human problem was really solved.

    HTTP has been around forever, but Facebook changed the web like few other things because it is used by everyone.

    HCI can't be studied on an island.

    ReplyDelete
  13. Android to the rescue. Damn the Apple Gestapo. I can't believe this is the same company behind webkit.

    ReplyDelete
  14. The iPhone is not a RAD platform, it's a pocket-sized battery-powered device. You seem to have no appreciation for the restrictions these come with.

    Clojure and others spend the phone's RAM, CPU and battery on abstractions that only serve you, not the owner of the phone.

    I know it feels like a slap in the face, but that's what it costs when you get into the world of embedded devices. You cannot slosh resources around the way you can on desktop computers, and you need to get used to it.

    ReplyDelete
  15. C. Lawrence Wenham has added the first touch of anti-petulance salve to the dog-pile (to mix and mangle a few metaphors).

    Apple sells the iPad as a portable device with very specific performance goals including long battery life. They cannot guarantee this if every two-bit code-pumping cowboy trots in with his/her own language, runtime, etc.

    As much as I love dynamic languages and the flexibility (both of thought and of execution) they afford, they come with a price tag. A really huge price tag if you're doing embedded development.

    ReplyDelete
  16. I think that the whole power usage argument is flawed. Apple is allowing one interpreted language in particular, Javascript, to run in its Webkit engine. Javascript is as dynamic as any language currently in use. That would mean web applications would destroy battery life. I would hazard most bytecode compiled languages like Clojure, if configured to output Objective C source code, should run as efficiently or more so.

    Also, the C that most scheme compilers produce is usually very very efficient, probably more so than the relatively heavy objective C runtime.

    ReplyDelete
  17. i am proud of having resisted apple
    for so long ... will continue to do
    so.

    ReplyDelete
  18. I'm sad to see so many of my fellow Clojurian's be so reactionary here. Yes it would be nice to directly program the iOS using Clojure. But, Apple is first and foremost about user experience. On a constrained device that means compromises in terms of runtime, etc.

    Now let's get creative. Instead of "screw Apple" etc. Why not think outside of the box. Apple does not review source code, they review your submitted binary.

    Why not work on Clojure based DSLs that generate Objective-C source code? This would be completely valid within the terms of the license agreement. This is the kind of fun that I'm going to have.

    Happily develop for my iPad and iPhone... in Clojure. My Clojure code generator will develop in Objective-C. Well at least this is what I'm going to be shooting for..

    - PublicFarley

    ReplyDelete
  19. Update:

    "Four sections of the iOS Developer Program License Agreement were changed compared to the previous version released on April 8th:

    Section 3.3.1 old version:

    3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

    Section 3.3.1 new version:

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

    All the stuff about which languages you can and can’t use is gone. Huzzah!"

    This quote from:
    http://www.zdnet.com/blog/burnette/apple-lets-in-java-and-flash-should-android-be-worried/2091

    ReplyDelete
  20. Yeah Tom, they changed but how can developers be confident that Apple won't screw them up again?

    ReplyDelete
  21. Daniel, there are a ton of MonoTouch and Unity3D based applications in the store already. They never stopped publishing them even when it was in the guide.

    ReplyDelete