I’ve had this conversation once before — back when I was at UserLand, around 2000 or so, we made the call to stop building Frontier as a fat binary. There weren’t many folks running 68k machines anymore, so we could build for PowerPC only.

You might wonder: why do that? If you’re already building for 68k and PowerPC, why not just continue?

Well, it meant we wouldn’t have to test on 68k machines anymore, for one thing. It’s hard for a small development team hard to support a CPU type they don’t use normally.

It also meant that full-build times would be faster — and, of course, the size of the app and the download would be smaller. (Not cut in half, because resources take up a certain amount of space, but smaller nonetheless.)

But the testing was the big thing. Even though, in the ideal case, another architecture is just a checkbox, you still have to test. And it’s time-consuming — it takes time that could be used to fix more bugs.

Today: PowerPC and Intel

I was looking at the Omni Software Update stats, and they’re showing Intel at 83.6% and PowerPC at 16.4%. (Choose Hardware from the popup menu on the left, then click CPU Type.)

Those numbers may not represent the Mac market as a whole — but I bet they’re reasonably representative of people who buy Mac software, which is the group Mac developers care about.

What this says is that it’s too soon to stop building fat binaries. We have to keep supporting PowerPC for now. But it also says that the time is approaching when we won’t have to anymore. (Could it be as soon as later this year?)

Possible special case: YourApp 1.0

The numbers also suggest to me another thing: if you’re building a new app, and that app is targeted to developers and power users — the kind of people who have newer systems — then you might not do PowerPC at all.

YourApp 1.0 would be an Intel-only release.

Of the power user and developer set, the percentage of PowerPC users is likely quite a bit smaller than the 16.4% reported in the Omni stats.

Consider also that you can avoid the time (which is coming) when suddenly you stop supporting PowerPC. If you start off Intel-only, you won’t have left any PowerPC customers in the cold. (Since you won’t have any PowerPC customers.)

I’m not telling you to do this. But if it were me working on a brand-new app, I’d think about it. (I’d also go Leopard-only, for sure.)

(Note to NetNewsWire users: don’t worry, I don’t have plans to take away PowerPC support. Eventually it will have to happen, but not soon.)

We’ve got air to burn. Using a box smaller than the actual page makes it easier to avoid the readability problem of wide columns of text.

And it’s almost as if we’re working around the bug of large displays, as if we’re saying, “No! Small display! Circa 2000! I will make it small!”

2. It avoids the dirty-white issue.

The page-in-a-page design minimizes the amount of #FFFFFF space on the page — which is good, because pure white can look a little dirty in that it shows every smudge and print on your display. Textures and darker colors don’t show as much.

3. White is whiter for the contrast.

The outside-the-page borders tend to be dark while the inside-the-page is white — and this makes the inside content area pop a bit.

4. It seems more physical.

Since gradients, textures, and shadows are often used, the page-in-a-page often feels more like a real thing. Which people love — that fool-the-eye thing is hugely appealing.

Claustrophobia

I tried using a page-in-a-page design here on this site for a while — and I felt claustrophobic and inhibited. Compressed. Particle Man.

It’s probably just me. I’m a weirdo. ;)

HULK SMASH

Okay, I confess to wanting to take a hammer to all these boxes. I want to crack them open.

Part of it is that it seems like we’re trying to hold back time, as if it’s the year 2000 forever, as if we can keep doing layout for 17" monitors, as if we don’t have the will to design for 30" displays and iPhones at the same time.

The engineer in me says that the page is already in the browser-window box — another box is just not needed, it’s waste.

And the designer in me would rather see an aesthetic that embraces the reality that it’s all lights and pixels on a flat screen. It’s not the real world or even the printed page. Why pretend it is? Isn’t there something to be gained by going with what-it-is rather than fighting it?

(I feel like those painters from the ’50s: “Don’t violate the integrity of the picture plane!” Ceci n’est pas une pipe. This is not a super-fancy pad of paper from the stationery store.)

This ain’t no disco

I wonder if it’s life during wartime, and economic and electoral uncertainty, that makes us want to have our say — but carefully, with our words politely bounded by rectangles.

If so, it goes against the grain of the web. The web is ongoing loss of control. It’s the revolution every day. (Workers of the web, yadda yadda! You have nothing to lose but your boxes!)

Like many of you, I’m sure, I’m thinking about the coming iPhone app gold rush. I’m thinking about App Store Day 1 (and month 1 and year 1).

To-dos and Tweets

One prediction — almost a gimme — is that we’ll see tons of to-do lists and Twitter clients. The best of the to-do list apps will sync using an online to-do list (Ta-da List, for example). And Twitter clients of course sync with Twitter.

I have questions about to-do lists: will we have about 10 good ones (and 100 bad ones)? Or will there be one that has some user interaction hook, some cool innovation, that makes it win the category? And, if so, how long before that hook is copied?

After all, iPhone apps are smaller than Mac apps — copying some cool user interaction is probably easier (in general) than it is for Mac apps.

And given the super-high level of interest in writing for iPhone, it may be a very competitive field — way more competitive than Mac developers are used to.

And then there’s The Cloud

The thing about to-do lists and Twitter clients is that they connect to a server or servers: they connect to the web, to the cloud.

Stand-alone apps on your iPhone are almost useless. You want things to sync.

Some of the Mac apps you use right now might sync to your iPhone locally, using some kind of networking, without having to go out to The Cloud. In this model, the iPhone app is kind of a satellite of a Mac app. (You can imagine your favorite Mac note-taking app with an iPhone version, with notes synced to your phone when your phone is in the same local network as your Mac.)

But my guess is that most new apps will sync with The Cloud. Which leads me to a few thoughts:

If you write a to-do list app that syncs with (again, just an example) Ta-da List, you might find that the Ta-da List folks are also building an iPhone app. They may not have bothered with a Mac app, but they know as well as we do that there’s an iPhone gold rush coming.

(I have zero inside knowledge, by the way. I picked Ta-da List precisely because I know almost nothing about it or its creators.)

Right now, Mac developers who write apps that connect to some cloud service usually get thanked by the cloud folks, who weren’t going to write a Mac app. But that could seriously change with the iPhone. (However, in some cases there will still be great opportunities for iPhone apps that work with a number of different but similar-in-purpose web apps. Imagine an app that works with Twitter, Jaiku, and Pownce.)

3. Web development sequence may change — APIs could come first.

The typical sequence for a web app: the browser-based HTML version comes first. Then APIs. Then client apps.

But, for anyone joining in the iPhone gold rush, the sequence might be: APIs and iPhone client developed simultaneously, then a browser-based HTML version, then, optionally, clients for Mac, Windows, and Linux.