The Absurdity of Apple’s New iPhone Restrictions

These are the new clauses:

  • Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine

I’m tempted to say that the clause is absurd and to talk about metaprogramming with C++ templates or JavaScript prototypes, but the fact is that it’s perfectly cromulent. The common-sense reading of this is straightforward: no code generation.

The constraint, however, is utterly illogical. Good programmers don’t write all their code: they write code that generates the boring stuff. This is probably the type of thing that was used in “The Elements” — automatic generation of the .xib files, asset directories and resources, and generation of  Objective C animation code (the video explicitly says that animations were generated). Forbidding Domain-Specific Languages (and the parser generators that help build them) flies in the face of the very people you want to attract to your platform.

C, C++, and Objective-C were all developed more than 20 years ago and all, on the iPhone, require explicit memory management — the most error-prone detail in software development. You know how you tell when an app for the iPhone was written in MonoTouch? It doesn’t leak memory.

You can play the semantic game of “Well, since a C program is not ‘originally written’ until it’s been compiled, if we use a higher-level language to generate C and compile that then we are within the letter of the clause.” But try getting that past your company’s lawyer when you’re trying to get the go-ahead for a business-critical application.

Apple may feel that they are in such a strong position in the market that they can dictate that outsiders use the same techniques to write software that are used internally at Apple. But that’s not how programming works: it is a continually evolving melange of abstractions, techniques, and tools. It has to be allowed to vary at the individual, team, and industry level if it is to progress. I’ve worked on C and C++ at the level of standards compliance suites, I’ve done my fair share of JavaScript, and I can stumble along in Objective C. But personally, when it comes to the iPhone, my language choice is C#: it’s significantly higher-level than C or C++, it’s a little more terse and cleaner than Objective C, it has certain language features that are undoubtedly ahead of Objective C (LINQ), and it provides a better type system. That is just one person’s opinion and Apple can certainly afford to ignore me, but if they think can ignore the last two decades of advancement in the programming marketplace, they’re over-confident.

Those with a sense of historic irony might observe that Objective C for many years existed only as a code-generating preprocessor and that a similarly restrictive clause could easily have killed its development and prevented NeXT from creating the software development toolchain that Apple is using today.

  • Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited

This clause makes more logical sense. Mobile development is still a resource-constrained environment. While memory, storage, and processing speed are beyond the dreams of yesterday’s hobbyists, processor use drains the battery and that is a very big deal indeed. Desktop developers today are generally free to live in whatever abstract model they choose: you want to live in a world where everything is an object, a mathematical function, or an S-Expression? Go for it! There’s enough power under the hood to make your program “fast enough.”

Not in mobile development. For instance, reading the color of a single pixel on the iPhone is kind of a big deal: you have to allocate a new data buffer, draw into it,and then read the raw bytes at the calculated offset. In Erica Sadun’s iPhone Developers Cookbook, she dedicates about 50 lines of Objective C code to demonstrate the technique. In MonoTouch, I did it in 45 lines of C# code. Of course, once you’ve written the function you can call it forever-more with a single line, but you probably will remember that your function has implications in terms of memory and computation resources. Unless you’re a very bad programmer, you probably would ensure that you don’t create and destroy that buffer every time you want to read or set a pixel.

On the other hand, a Flash developer has the functions pre-written for them: BitmapData.getPixel() and BitmapData.setPixel(). And they probably don’t think about those functions having significant overhead — part of the reason people use Flash is because it’s abstracted away just such things. So how can a cross-compiler for Flash deal with the line myBitmapData.getPixel()? There are three choices:

  1. Treat it as a single programmatic intention — allocate the buffer, read the data, and deallocate the buffer.
  2. Treat it as two intentions — (a) “allocate a buffer for further use” and (b) “read the pixel.” Keep the buffer around for further use.
  3. Divine the programmer’s intent — if they really only intend to do this once then treat it atomically, if they are going to be doing a lot of pixel manipulation, keep the buffer around

All three choices have problems:  if you choose 1, but the program does do lots of manipulation, you destroy performance. If you choose 2, you consume memory at a potentially prodigious rate (and even so, you have to write a garbage collector). If you choose 3, you’re going to have to wait until researchers develop the “do what I mean” compiler switch, which is still a research project.

That’s Apple’s legitimate concern with “intermediary translation or compatibility layers”: the efficiency and restrictiveness of such layers. MonoTouch is quite efficient, maybe some others won’t be. One thing that MonoTouch does (garbage collection), it does well — perhaps some other implementations won’t. MonoTouch makes it very easy to “drop down” to unsafe code or to link in new CocoaTouch APIs, that clearly won’t be the case with some others.

So what if Apple kept the clause forbidding translation and compatibility but dropped the first one? So that I  write my flow-of-control using whatever language I choose, but I don’t write my own “translation or compatibility layer”? That seems reasonable until you realize that there’s no difference between a translation layer and a 3rd-party library call. Functions are translation layers: the difference is solely one of intent and extent. And even as far as “extent” goes,  C++ template metaprogramming, Boost, and smart pointers have lots of consequences that absolutely reach throughout the application. What if I wanted to use a port of libgc? Legal or not?

In one day, Apple has damaged projects as diverse and good for the iPhone as MonoTouch, Unity3D, and Appcelerator. They’ve sowed Fear, Uncertainty, and Doubt about projects like RunRev and Flash Packager for iPhone. And they’ve done it with 2 lines of technical absurdity. One hopes that they can come to an understanding with 3rd parties that helps ensure the performance and consistency of applications written for CocoaTouch without draconian restrictions against fundamental programming techniques.

If not, one hopes they go fuck themselves.

26 thoughts on “The Absurdity of Apple’s New iPhone Restrictions

  1. Pingback: Apple made it less fun (for me) at Papervision 3D Tutorials

  2. Very well said! I didn’t even know (though should have assumed) that Obj-C was just a preprocessor. I guess that explains all the @s.

    Oh, and the ending was magical. :-)

  3. Loved your article, especially the finale :-) I don’t develop for iPad, iPhone or Apple but was considering it. Steve Jobs behavior these days has finally made my mind up for me though. It is precisely this kind of behavior that ilk bring Apple down…again.
    Cheers and thanks for the read

    BondiGeek

  4. Well said. If performance *is* their main concern, there are better ways to tackle the issue than a license agreement. Work with the developers and middleware vendors. I think most will be more than happy to get some guidance about performance issues. License agreements are a very poor way to address performance issues, especially since lawyers don’t know jack about the topic. But I really suspect these new clauses have very little to do with addressing performance…

  5. Very well put, from the first line to the last (lol).

    I also think that if we’re going to ban inefficient code that’s the product of a poor cross-platform porting framework and results in an awful app, Apple should have the decency to ban their own Windows port of iTunes.

  6. Nicely said.

    One quibble:

    Apple may feel that they are in such a strong position in the market that they can dictate that outsiders use the same techniques to write software that are used internally at Apple.

    Apple doesn’t even allow that. Compare these two apps:

    http://gist.github.com/357782

  7. I like C# and even avoid Apple products. But I think that C++ is much better. Microsoft started to work against C++ long time ago (like not supporting C++/CLI for Pocket PC development). I’m actually happy that Apple somehow supports C++.

    I’ve always hated all these Java, then Flash and now Silverlight plugins for Web. Original idea of Web was that lightweight HTML is flexibly rendered on nearly any screen without any plugins (and without pixel layout and without fixed-size fonts). Still many websites are Flash only and are very hard to read because of that. I’m again very happy that Apple’s iPhone limits Flash ugliness on the Web.

  8. @Vyacheslav Lanovets:

    This issue has nothing to do with Flash plugins on the web and this won’t help limiting it’s usage. I see, you have something good to say about Apple and that is fine, but your Flash-plugin/website rant has nothing to do with Apple’s decision to restrict App development… ->see article.

  9. Code generation is clearly within the guidelines. IF your generator creates Objective-C, C, C++, or JavaScript code. It is naive to think that since a code generator isn’t written in Objective-C, C, C++, or JavaScript that by extension the code it generates is not “Originally written in Objective-C, C, C++, or JavaScript”. The code generator creates code for an application; it is not THE application. I’m sure you know this, that is why I think your article is a bunch of FUD.

    Further, Apple doesn’t care what tools are used to build an app as long as before it is compiled the code was Objective-C, C, C++, or JavaScript.

    What Apple does not want (as you stated later in the article) is compatibility layers that interface C# (for example) to the Obj-C runtime. Compatibility layers are simply extra overhead that costs to much to run on a now multi-tasking mobile phone environment. I agree that it sucks, but it is reality.

    Even though Apple shouldn’t be making these decisions for each and every developer, it is often wise to use the tool for a job that was specifically created to complete the job. It will make your life and your product a lot better.

    larry: No, you’re wrong to say that “code generation is clearly within the guidelines.” The common-sense lay reading that an application must be “originally written in…” is not “originally written in something else, but then transformed mechanically into…” Especially because you and I both know that there’s absolutely no difference between generating C/C++ and generating assembly language. If the clause means anything, it means what it says, and the plainest reading of what it says is “no code generation.”

  10. Maybe we’re talking about different kinds of code generation. I’m thinking that by code generation you mean using a program that generates Obj-C classes, for example, using templates and maybe pulling in data into the templates. Like in your example with The Elements app. I imagine they may have created an Obj-C class and XIB and some other resources using a scripting language. They didn’t write any logic for the application in any other language than Obj-C, but they used another program to create the Obj-C. Then they compile the Obj-C and have an application. To me that application was originally written in Obj-C. It was compiled in Xcode, and if Apple had a problem you could show them your Xcode project with all the logic and resources for the app in plain old Obj-C.

    Here is how I see it: If you Obj-C source code for your app (or C or C++), your app was “originally written in Objective-C, C, C++.” end of story. If all you have is a bunch of C# and a cross compiler your toast.

    I digress.

  11. Nice article. In a funny kind of way I feel a sense of relief at this latest ridiculous
    declaration from Apple. I wanted so much to develop for the Apple platform that I
    purchased a book on Cocoa programming with a view to progressing to iPhone development.
    I started to read the Objective C tutorial but the stench of the 1980s was so
    overwhelmingly strong that, try as I might, I couldn’t complete the chapter. No one
    voluntarily writes code like that these days do they?

    So my next thought was to investigate ways of using F# or C# to sidestep the
    inevitable insanity that would have resulted from Spaghetti-C Objective-C but
    now Steve Jobs has put a stop to all of that. I now feel like a great weight has
    been lifted from my shoulders and I look forward to the freedom I’m going to
    have with the Android and the forthcoming Microsoft Windows 7 mobile platforms.

    Perhaps I won’t upgrade my iPhone when they announce the new models
    this year but instead look further afield. After all, Apple are still fretting about
    multitasking when Microsoft are applying themselves to addressing the problems
    of multithreading in F# – and let’s face it Microsoft will be the good guys soon.

  12. Angry boy. Developers like this one come across as egotistical and righteous, and most of these posts don’t even credit what Apple has done to forge a new marketplace and give them a development opportunity they could have only dreamed of 2 years ago. Well it’s not your playground, never was so pipe down, evolve and stick to the rules or get lost. Publicly biting the hand that feeds you with “f**k you” is incredulous.

    It’s clear from the pattern of angry posts that the pissed ones are either A) Flash supporters or B) Have invested heavily into the intermediate layers either for benefit of themselves or others and are now in a precarious position of being unsure of how to support and upgrade their work. I sympathise with being in this position, I’ve been there before and it’s just a reality of commercial software development. But it was your choice to take this path, your calculated risk and this time you lucked out. That’s life, it happens sometimes.

    So what next? We’re generally smart people around here, right? There’s nothing stopping you writing template scripts to make your Objective-C code. The macro processing language is there. Intelligent abstraction and encapsulation didn’t disappear overnight – most projects I write result in an ever larger library of useful objects that each hide 50 or 500 lines of code behind a couple of Objective-C calls and are greatly empowering.

    Apple needs some level of control to preserve the user experience. By making these moves they are continuing to protect the user experience and they are assured to keep a huge lead over rivals for a long time yet. The average user experience of apps on competing platforms is going to suffer if they allow all manner of intermediary layers and interpreters.

    I think Apple just grew their future market place significantly. Sure there was a short term cost – there’s always fallout. Will it prove to be worth it? I would put money on YES.

    Larry: I’m going to approve this, even though it’s clear you don’t know my work. I don’t particularly give a damn about Flash and it’s not that I’ve invested a great deal of personal time in MonoTouch as much as the fact that I’ve advised people to move towards it for enterprise development (since there are so many more C# programmers than Objective C programmers and, until now, it seemed low-risk). So I am absolutely pissed at Apple for the change, but not because restricting languages hurts me. I’m more than competent in C and C++ and I learned OOP with Smalltalk, so Objective C is hardly intimidating. Heck, if they limit development to assembly language, I win even more.

  13. It would be an interesting poll to see how much industry experience those who favor everything Apple does have compared to those who think Apple is making long term economically disastrous decisions.

  14. Adobe gave the Mac-world its software market foundation & ecology – Postscript for Apple LaserWriters & Desktop Publishing, Premier, Illustrator, PhotoShop, DreamWeaver, Flash, Flex, Coldfusion, CSx, etc.. Talk about biting the hand that feeds you.. In some cultures that is called a ‘namak haram’ – someone who has eaten your salt (had food with you at your invitation) but that’s an ‘User Experience’ Apple knows little of..

  15. Pingback: The Dark Side Of Steve Jobs | Defamer Australia

  16. Hi — As a decidedly non technical person – I may not have followed every detail of your post — but your message was clear. This is a play by Apple to control every access point “Judy Consumer” will have to what they see, what they play and how they interact online.

    People used to worry about the government being “big brother” — no more. Now the likes of Apple or Google are the ones to worry about. Our tech knights in shining armor turned out to be made of clay (just like the rest of us)

    *sigh*

    Judy Shapiro

  17. Pingback: The Dark Side of Steve Jobs

  18. Pingback: Dang it Steve! | Jennadea.com

  19. Pingback: Math software, dynamic languages, and the iPad | Blog | Bob Sutor

  20. The problem with hate is people do stupid stuff and become emotional. Apple HATES Adobe. From what I can tell it all revolves around when they were trying to get OS X out the door. Adobe would not help them port anything to the Intel CPU so Apple was forced to spend 3 years developing Rosetta and a way to VM PowerPC code on the Intel platform.

    This clause was specifically put in to destroy the huge efforts Adobe had made to get on the iPhone platform. Watch the iPhone 4.0 keynote and see how Jobs pushes HTML 5. Somebody at Adobe needs to send Jobs some flowers and chocolates to make up. ;-)

    Now that Apple is in power they very well remember when Adobe flicked their nose at them. The bad thing is it hurts everyone involved with the platform.

    Good article and too bad for everyone that Adobe and Apple can’t get along.

  21. It’s not absurd. Insteda it is one of the reasons that the platform works good.
    Don’t let crap come inside.
    Thanks

    larry: I’ve heard this argument, but “crap” boils down to two things: a bad user experience or a resource-wasting application (diminishes battery life, consumes too much storage, etc.). But “crap/not crap” user interfaces don’t have anything to do with Objective C, any more than “crap/not crap” music depends upon whether it was composed with a guitar or a piano. The resource-wasting argument I’m much more sympathetic with: I think it’s reasonable that the iPhone bans VMs and interpreters. But again, the blanket restriction either means nothing or it means “no code generation,” which is a ban on a huge area of good programming practices.

Comments are closed.