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.