What Native Code Really Means

I was working with Sree on a project about 12 years ago, and he insisted on using Win98 for development.

All of us kept asking, "Why won't you use NT4.0? It doesn't crash or lock up. You're rebooting 3 times per day." It made no sense.

Sree said, "80% of my customers have Win98. That's why."

Right now, people seem outraged that the new iPhone SDK bans use of the non-C-like languages or huge compatibility/portability frameworks: http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler

And yes, it means more work for developers. But I'm cheering them on, and there are two reasons.

Reason #1: Speed

First, I tried some of the Maps apps on the iPad. You haven't used a computer until you've dragged a photo or a map around at full screen on this kind of device.

Maps draws at 60FPS all the time, no joke. It changes your life. It is immersive and responsive and real.

If you launch Safari on iPad and drag a map around in Google Maps, it's 3FPS, all the time. Like 20x slower. I don't really care why, and they've worked pretty hard to make Safari fast, but it's not even close to the native code.

Flash maps mostly run a bunch slower than Google Maps does. And across the board, interpreted stuff is slower than native. If you consider RAM and CPU together, it is hard to find an app with "portability" glue or an interpreted language that can run in <3x the speed of native code. And 3x really matters.

So Apple's got this amazing device, but mostly because they thought about all this and made the software sing. It is fast, it is a balanced machine with a GPU and CPU that work together to draw UIs really fast.

Even Google's nexus one can't seem to scroll a list or redraw a map at more than 15fps. And they wrote all the code (yeah, lots of it in Java). It is jerky and awkward in comparison to an iPhone 3gs. And that's all one team, not some engineer at another company doing the third-tier port of a portability framework in a hurry.

But now, Apple will be supporting multi-tasking and supporting background apps.

And honestly, they deserve to set the rules. You very simply shouldn't be writing a background app in Python that is 20x slower than the native one. You shouldn't be draining the battery to make a UI that has 1/5 the framerate of the native code. If using the GPU is better, use the GPU.

I love it that they're saying, do it the right way.

Reason #2: Get the UI right

So back to Sree using Win98 when everyone thought he was crazy. In 1998, WinNT 4.0 looked pretty much exactly like Win98. You used the same screen, the same mouse, and even the visual styling was pixel-identical. But the internals weren't the same. You made threads and Win98 was more jerky than NT. Memory wasn't cleared for you. DirectX was totally different.

Now people really believe they can make apps that port "effortlessly" from the desktop to a device with 10% the CPU power, 1/5 the screen resolution (multiple resolutions really), and they say with a straight face that this will be a good user experience?

That is simply not true. When you're designing for a mobile device, you should be thinking of every pixel, or how the slight differences in the screen size matter, of how the native controls work, of what the consistent way is to do animation (UI elements behave differently on different phones).

Buttons on Android are different sizes than iPhone. Tip of the iceberg.

You should be using win98, because your users are.

And of course, Apple is in a great position. People will bend over backwards to port code to their platform. They have no reason to make it easier, especially when that makes the user experience suck more. They can lop off the bottom 50 percentile of apps and it hurts them not one bit.

Really, forcing people who don't want to use their native, fast tools to use AJAX and HTML5 isn't such a bad punishment. It's a sure way to make portable apps, and it advances the idea of open and functional standards. It's a fine second tier.

There has been a trend for many years: the guys who write "scalable" apps for servers are happy to say they can buy 10x the machines, and this is usually cheaper than taking more time to get to market or using more engineers to do a task. They are smug about this, and it always drives people who care about using resources efficiently just a little bit nuts.

But most client developers have never been this way. Game engine guys don't think this way, and neither do native client app developers.

This is an incredibly exciting time, and this move will make some new possibilities based on people writing code that changes the world, that is massively better than what's been done before. It won't be the same old stuff, smaller.

Saving a few developer hours is not an excuse for making battery life awful and making apps that run at 5FPS, and forcing people to actually write an app for the platform they're deploying to is totally what I'd want on my platform.

Bravo Apple.


  1. I think you're missing an important detail: they're banning the idea of writing an app in one language/environment and translating that to C/C++/Objective-C. So the end app is a native one; there's no interpreter. There may be some abstraction penalty for that translation step, but it's not clear to me that it's anywhere near as substantial as the Java/Flash runtime one.

    To me, this is a pretty chilling notion: they're specifying how you can *create* your native app in the first place, essentially to better lock-in developers to their platform, IMHO.


  2. Most dynamic languages can be compiled like this, though, some of them without a lot of static optimization.

    Maybe I need to learn about some of the non-Flash frameworks that have rich programming languages but aren't Flash.

    I know about a Mono/C# one, and Adobe's effort of course.

    I actually think users should be able to turn on Flash in the foreground in the browser with strict rules about CPU/battery usage. But for background apps? Never.

  3. Anonymous4:18 AM

    Mike, you exaggerate. The games I "choose" (!!) to write in Unity3D or Flash and run on the iPhone do *not* run at 5 fps. Nor is it desired or appropriate that they run in the background. Apple wants us to be artisans but my toolbox should not be limited to a hammer and chisel.

  4. Anonymous11:56 AM

    But this also blocks other, new _high-performance_ programming languages. No MacRuby (http://www.macruby.org - and yes, in spite of the name, it is absolutely as fast as ObjC). No Haskell/Go/ooc/god-knows-what. And, in a few years, when these devices have 4 cores and powerful SIMD, no CodePlay compiler or equivalent.

    All this in a period of enormous proliferation of new and alternative programming languages and models.

    This is bad because it's about much more than the Flash compiler and Mono.

  5. Corey - I think it's not a bad idea to make higher level tools for a particular platform. But abstract tools that emulate other systems almost always add overhead.

    And I think it's harder in some ways to police "if you use this framework you can't run in the background, etc."

    I have been underwhelmed with the bad abstractions people make...I even have a soft spot for Flash, but it really is buggy and awful on Apple's platforms...of course, this may very well be Apple's fault (we always underestimate how hard MSFT has worked to make other people's stuff work.)

  6. jrk - I agree at a high level, and I agree when you write a specialized tool to author *really well* for a particular platform, this is quite a good thing.

    I think my objection is much more about abstractions that are not in any way optimal for the platforms they end up running on.

    Also, for the most part, I hate Apple's tools, but they're pretty good for that platform, and it keeps their velocity high.