Jobs makes a valid point: intermediate layers hinder the progress of the platform.

April 11th, 2010 in Uncategorized Comments

In his response to the Section 3.3.1 changes, Steve Jobs makes a very valid point that has been largely glossed over by the Apple vs Adobe narrative that is playing out on the web right now:

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.

There are two arguments here:

  1. Intermediate layers produce sub-standard apps.
  2. Intermediate layers hinder the progess of the platform.

Most people seem to be rebutting the first argument without addressing the latter. I do think their rebuttal is valid: developing an app in Objective-C doesn’t provide any guarantee of quality, and app quality should be vetted during the approval process regardless of the language used. So the first argument does not hold water, but what about the second?

I think Job’s second argument is valid: intermediate layers hinder the progess of the platform.

Imagine a scenario where Apple releases a bunch of new features in their iPhone SDK. Developers using the native platform have access to the new APIs immediately, and can begin incorporating those features into their applications.

Developers on an intermediary platform have to wait for the intermediary platform vendor to implement the new features and expose it in their APIs. The best case scenario is that the intermediary platform vendor figures out how to implement the new features in a timely fashion, allowing their developers to take advantage of them quickly.

Vendors with slow release cycles (I’m looking at you Adobe) end up creating an additional delay before developers on their platform can take advantage of the latest and greatest features from Apple. This is no good if Apple wants to be on the cutting edge.

And of course, the worst case scenario is that the intermediary platform vendors never get around to implementing the new features, preventing all of the developers on their platform using those features.

I can definitely see how that hinders the progress of Apple’s platform, and why they would want to take steps to prevent that from happening.

Exhibit A: Block Objects

It’s no coincidence that these SDK license changes came with the announcement of iPhone 4.0’s multitasking features.

The multitasking API relies on block objects, a language feature added to Objective-C 2.1, which first shipped with Snow Leopard. Note that the introduction to blocks specifically states (emphasis mine):

Blocks are available in GCC and Clang as shipped with the Mac OS X v10.6 Xcode developer tools. The blocks runtime is open source and can be found in LLVM’s compiler-rt subproject repository. Blocks have also been presented to the C standards working group as N1370: Apple’s Extensions to C (which also includes Garbage Collection). As Objective-C and C++ are both derived from C, blocks are designed to work with all three languages (as well as Objective-C++). (The syntax reflects this goal).

You should read this document to learn what block objects are and how you can use them from C, C++, or Objective-C to make your program more efficient and more maintainable.

Essentially, the new features Apple shipped in iPhone OS 4.0 rely on core improvements to C, C++, and Objective-C, the three languages that Apple now wants you to build your apps in. How shocking!

Forget the crazy “sky is falling” pronouncements of how Apple wants to control how you think. Forget the reactionary claims of Apple slapping developers in the face, or how Steve Jobs has just gone mad.

Perhaps there is a much more straightforward, practical reason for their actions. Perhaps they simply want you to work in those languages so you can take advantage of the improvements they are making to them, and the new features they are shipping?

Imagine another scenario where Apple adds some fancy new iPhone OS feature that relies on a new programming language construct they’ve added to C, C++, and Objective-C. Now we’re no longer talking about intermediary platform vendors simply having to expose some new APIs. They might have to fundamentally alter their programming language in order to support those new features before their developers can take advantage of them. How much longer will that take? In some cases, will it even be possible?

The predominate narrative on the web right now is of Apple attacking Adobe over Flash CS5 in an attempt to protect their hold on their platform, with developers getting caught in the middle. But I think there is a much more practical reason for their actions: they are evolving (and will continue to evolve) the programming languages on their platform to support the new features they want to build, and waiting for intermediary platform vendors to eventually implement those features will hinder the progress of the platform as a whole.

That’s a lot less sensationalistic, don’t you think?

Comments

  • Frank
    Since the SDK terms explicit list the allowed languages as Objective-C, C and C++, that means that Objective-C++ is now no longer permitted. Is this either just a technical mistake because someone in legal can't distinguish between Objective-C and Objective-C++, or is there really a reason to not permit it ?

    Since C++ is still permitted, disallowing Objective-C++ means that you would need a C api for all your C++ code. That's a tedious but doable task, except once you get to complex libraries with a lot of RAII going on, plus dealing with exceptions.
  • If they "want you to work in those languages so you can take advantage of the improvements they are making to them", forcing your hand isn't the way to get the result they want. Make better tools than the alternatives and developers will be more than happy to use them. Forcing developers to use your tools implies a lack of confidence in the actual merits of your tools.

    Apple's shooting themselves in the foot with this policy. Developers on other platforms will have access to better tools, and so will be able to build superior apps faster.
  • It's not so much about the tools as the skillsets. Flash developers want to use their existing skillsets to write iPhone apps - the tools Adobe provides are almost certainly going to be inferior to their native Xcode counterparts, both in terms of performance as well as native look and feel.

    For writing iPhone apps, there is no doubt that Xcode/Objective-C is a better tool than Flash CS5/ActionScript. After all, the platform was designed with those tools in mind. The entire point is that Flash programmers don't *want* to learn those tools.
  • While the motivation may have been Flash, the section 3.3.1 changes are much broader than that. Essentially any tool that generates code is forbidden. Want to code in a functional language instead of Objective-C/C/C++? Want to use a domain specific language like a parser generator or a template engine? Want to use a macro pre-processor to reduce boilerplate code? Want to use an existing library that wasn't written in one of the blessed languages? Too bad. All of those options are forbidden by section 3.3.1.

    If Flash programmers don't want to use those tools then disapprove their apps for being low quality, not on the basis of an arbitrary rule that hurts a very large number of developers.

    I have a more complete writeup on this on my blog: http://www.xenomachina.com/2010/04/iquality.html
  • Sorry, this article is nonsense.

    Say Apple adds a new API. For example, let's say a deferred task API (so-called "multitasking"). Not every Flash game, Unity game or even MonoTouch business application is going to use or care about the API. Not the existing applications, and not most of the new ones either. (The same applies to ObjC applications.)

    But there will be a couple of folks who do want to use the new API. First of all - they're absolutely not going to see that their framework doesn't support it and give up! They want to be first to market - they're going to be demanding support from their framework almost instantly. If they don't get that, what do they do?

    Well first of all - obviously they could still use ObjC! Duh! But better yet - many of these frameworks you can just write the "new API bit" in ObjC and the rest in your language of choice. With MonoTouch the story is even better - just add bindings for the new API yourself in C#!

    (Admittedly I doubt you can link ObjC code with Flash in any easy way. But the sort of developer who wants to use Flash won't care about new APIs anyway - they just want to see their interactive animation. And don't tell me this is a problem for the platform - there are thousands of "Flash-grade", not-using-fancy-APIs applications on the store already!)

    The "Block Objects" you mention are simply a new API. The only way your argument holds water is if Apple forced ALL developers to modify and recompile their code (obviously not going to happen).

    Remember that all these frameworks compile down to the same ARM code, calling the same public APIs, that approved C/C++/ObjC applications do!
  • The entire point is that blocks are not just a new API, they rely on syntactical changes to the programming language. What happens when ActionScript or programming language X lacks the corresponding syntax? Then we have to wait for Adobe to add support for the new syntax to their language (unlikely) or figure out some weird hack to represent the syntax in their language (something commonly done with bindings). Either way, this takes much longer than updating some bindings to support new APIs, and just delays developers from being able to use the new features.

    The fact that everything compiles down to ARM in the end is irrelevant - we're talking about the features and syntax available in C/C/Objective-C vs other languages. Apple officially supports the former and can make modifications to them to suit their needs, whereas there is no guarantee that the latter can keep up with the changes.
  • My entire point is that Block Objects are just a new API. Admittedly they are more esoteric than the usual "here are some functions" APIs (so the built-in binding features in MonoTouch might not work) but they are an API none the less.

    There's nothing magical about a new API that it suddenly "breaks" frameworks like these - unless Apple are insane enough to also break all existing ObjC code as well.

    Framework-using developers are well aware of the risk that they will be cut-off (usually temporarily) from new features (or have to drop into ObjC occasionally). It's the trade-off they make for the ability to develop using less resources.

    Apple is trying to ban that trade-off. You're trying to sell it to me as if there will be some must-have-immediately yet highly-incompatible feature in the future, and that Apple is so sure that the trade-off isn't worth it they have banned it. I think that this is far-fetched.
  • Chuck
    It's still a bad reason. Apple could simply require that any languages used be compatible with Objective-C — then, even if the language is so hopelessly behind that incorporating new features is impossible, we can just write Objective-C code to take advantage of the new features while still enjoying whatever benefits we get from our language of choice. Heck, this is already the position C is in: You can't write a full Cocoa Touch app in just C, but it's fine because C is 100% compatible with Objective-C.

    Some people are far more productive in languages like Scheme, Javascript or Lua than in C. Losing this is a big blow to them. And what do we get in return? Supposedly: the assurance that if they want to take advantage of new APIs, they can. In reality: We get nothing, because they already could write Objective-C and incorporate it into their apps if they wanted to.

    Also, many of these languages *could* include these features. Apple's "blocks" were blatantly stolen from Ruby, which ripped them off from Lisp. But now Ruby and Lisp are banned because they couldn't incorporate blocks? This does not compute.
  • tbutler67
    I actually think the rebuttals to the first part of Jobs' statement are missing a point, in that they aren't reciprocal. Yes, (being written in Obj-C) is (not a guarantee of app quality). This does not prove, or even imply, that (not being written in Obj-C) is also (not a guarantee of app quality). If all cross-packaged Flash apps show certain characteristics, then it is a defensible conclusion that cross-packaging Flash apps is guaranteed to produce those characteristics, even if some native Obj-C apps also show these characteristics.
  • David
    First of all, intermediate apps are not substandard. Look at the Unity games on the iPhone. Or Monotouch. http://www.taoeffect.com/blog/2010/04/steve-jobs-response-a-brief-followup/

    Go play one of the Unity games that have hit number 1 and tell me it's not quality.

    Secondly, I think the author of this post has it backwards. Let's say I'm writing a cool game in Lua on top of a nice 2d physics engine. Apple adds some new math functions that make things super fast. I get a new version of the engine and recompile. Awesome. I'm up to date and rocking fast.
  • Rick
    I think you have this exactly backwards. Monotouch has been implementing things with a lag of one or two days. It's far easier to keep your app up to date on Monotouch. Likewise with Unity. Do you really think tons of people updating their apps by hand will be faster than doing a recompile with Unity after they implement the new feature?

    Long live Zombieville, my fav Unity game.
  • After MonoTouch implements the newly released APIs, the developers of MonoTouch apps then still have to go in and update their apps to support the new APIs. It's not a matter of recompiling your app - the developers still have to update their apps to take advantage of the new APIs (and each app might use them slightly differently).

    And the pace of the updates depends entirely on the platform and team. Sure MonoTouch may be fast now, but the iPhone OS 4.0 SDK has 1500 API changes to go through. Will other platforms (like Adobe) be able to respond as quickly?
  • james katt
    Blocks allows sections of code which can be monitored and scheduled by the operating system to run independently, in parallel with others. The app, itself, doesn't have to monitor and manage multitasking of its threads. This is a huge advantage, particularly with code that can run on CPU cores and code that can run on the GPU.

    The operating system determines how to most efficiently run the blocks of code - independently of the app, itself. The app, itself, then does not have to handle multitasking of its threads. It leaves that to the operating system. The operating system can decide which cpus handles the code. For example, it can allocate the code to the main CPU or the GPU. The app doesn't need to know how many CPU cores or GPU cores the device has. The app's developer doesn't have to worry about multitasking threads and allocating the threads to various CPU cores. This is because the operating system is the one that takes care of this automatically as long as the independent chunks of code are indicated by blocks.
  • Thanks for your reply, that is very informative. I can see how intermediary layers might have trouble fully supporting this kind of behavior.
  • james katt
    Steve Job's first point is also valid in light of the second point.

    Intermediary Platform Vendors cannot keep up with the improvements that Apple is making, over time, to the iPhone platform. This is particularly true if new iPhone features rely on changes to the programming language itself (for C, C++, and Objective-C).

    When these Intermediary Platform Vendors do not keep up with Apple's own programming tools, then the applications created from them ARE SUBSTANDARD. These applications do not take advantage of the features inherent in the iPhone platform, which are not present in other platforms. These applications are based on the LOWEST COMMON DENOMINATOR among the platforms. This alone makes them substandard in regard to quality. An example of that is how Amazon's Kindle app is a fantastic example of a native iPhone app. Yet how Amazon's Mac OS X Kindle app is a crap app, having used a 3rd party intermediary platform (QT) for its creation. It does not act like an Apple app. It clearly was ported without consideration of the strengths of the Mac OS X user interface.
blog comments powered by Disqus