The Reasons for Leopard-Only Apps

TUAW talks about the growing swell of upcoming apps which will use Leopard APIs, and therefore, will require Leopard to run. I'm sure some users are wondering why developers are doing this, and some developers are wondering if they should do the same.

Many early adopter end-users are planning to upgrade to Leopard regardless, but some might want to wait for various reasons. From the casual observer's perspective, the obvious thing to do is support older versions of Mac OS X in order to have access to a larger market. In a sense, that's true. But there's more to the story.

The best analogy I can think of right now is a concert. Picture yourself going to see Flying Meat or Delicious Monster perform live (weird how those actually work as band names). They choose a venue that's a bit father away and costs a bit more to get into, but once you're there, you see it was worth it to provide a better experience. It's not that they don't care, it's that they want FlyGesture and Library to be the best they can possibly be, even if it means narrowing the scope a bit. That's the Mac software ethic in a nutshell.

What Leopard Offers to Developers

By using Leopard APIs and language improvements, not only can an app be faster and more stable, but it can actually do things that wouldn't be possible otherwise. Part of this is because the newer APIs offer new capabilities, but some of it is the fact that the energy saved on implementing the basics can be re-channeled into other areas. Here are two specific examples:

Language Improvements: Using properties, Objective-C 2.0 can substantially reduce the amount of code a developer needs to write, and can essentially eliminate the most time-consuming and frustrating task of programming: memory management. It's not just frustrating for the developer to think about, but it's frustrating for users because bugs in memory management cause crashes. Garbage collection will, at least, minimize the amount of memory-related code that has to be written and later fixed.

Garbage collection should also make writing threaded apps easier, since you don't have to worry about whether the object you're passing to another thread will stay around long enough for the receiver to use it. Tracking down over-released objects in multiple threads is one of the most difficult things imaginable because it's inconsistent. It may only crash 45% of the time.

Simplified Drawing Code: Core Animation is not just for fancy 3D effects. It's just as useful for 2D drawing. It simplifies drawing code (some cases, drastically simplifies it), and can provide huge performance benefits. If nothing else, Core Animation rendering runs in its own thread, so the UI can stay responsive while the main thread is churning away on something else.

And that's just the stuff we're allowed to talk about.

With garbage collection, properties, increased performance and a streamlined drawing model, developers will be much happier writing their apps, users will be happier with the results, and the app will head further down the path of the sacred goal of Cocoa: focusing efforts on the parts of the application that make it unique. Memory management is not a differentiating feature.

A Better 2.0

Once you pass the "gate" of Leopard — which will likely happen at point anyway — you give the developers the ability to deliver much more polished software. In other words, the differences between the 1.x and 2.x versions of the apps will be much more significant.

Forgoing Leopard APIs until some arbitrary point in the future can actually hold the app back from its full potential. Wincent Colaiuta talked about this recently in a discussion about his Synergy app:

But I've still tended to keep things at the level of the "lowest common denominator", and when Tiger came out I still tried to use only APIs that were available on Panther as well.[...]

Avoiding the newer APIs is literally holding these products back. Time to make the jump forwards. The update to Synergy Advance that I am currently working on makes use of Tiger-only APIs and I've bumped the version requirement up from 10.3.9 to 10.4. In 2007 I plan to switch to pretty much Leopard-only development.

In the right hands, newer APIs can make a world of difference. Delicious Library 2 will be a Leopard-only, and I doubt they took this lightly. With perhaps the largest and most satisfied user base of any independent Mac developer, Delicious Monster has a captive audience that would probably trip over themselves to pay for an upgrade.

So if Delicious Monster is willing to forgo sales from the people that are still using Tiger on the day Leopard comes out, there's probably a pretty good reason.

A Change in Perspective

Wincent Colaiuta's story is pretty typical of what I've heard over the last few years. A number of developers would target the current or previous version of Mac OS X rather than the cutting edge because they either believed that their app would be ready too soon or users would be slow to upgrade.

In most cases, they were wrong on both counts. Many found that the schedule to release their app before Tiger slipped well into the upgrade cycle. On top of that, Tiger has sold very well. The simple fact is that Mac users are using Macs by choice, not by accident. It's not surprising that they're more interested in what Apple's newest offerings are.

In particular, if somebody successfully tracks down and purchases a piece of Mac software that wasn't made by the "big five," it's even more likely that they're in the early adopter category. This is a major advantage for smaller developers because they can quickly deploy APIs that larger vendors have to wait on.

The other consideration here is that most people will eventually upgrade. In fact, it will often take more time for a developer to revamp an application for new APIs than it will for the upgrade cycle to complete. Forward-thinking really pays off here.

Net Gain

Back to the original point. By supporting earlier versions of Mac OS X, a developer can theoretically have access to more users. Assuming a developer values a large number of users, the equation looks something like this:

+ Supporting more Mac OS X versions means more potential customers
- Boilerplate code takes time away from other tasks
- Manual memory management causes hassles for developers and users
- Forgoing newer APIs means a less impressive upgrade
- Forgoing newer APIs can also mean lost performance opportunities
- Users who don't upgrade their OS are less likely to upgrade apps

I want to explain this last point. I'm not saying people who don't upgrade are bad citizens. I'm saying if a developer is driven to make the best app possible and feels Leopard APIs would help that goal along, they should be encouraged by fact that people who buy Mac OS X upgrades are much more likely to buy an newer version of an app. They're also much more likely to appreciate the improvements.

Once all of this is taken into account, the question is do the developer and users come out overall ahead by supporting earlier versions of Mac OS X or not? Some are absolutely are better off supporting Tiger and even Panther, but the developer should consider if they're chasing a customer that isn't likely to buy their app. In fact, an impressive Leopard app may attract more users then a Tiger-only app ever would.

In the case of TextMate, most customers are high-end users and early adopters, and the application stands to make performance gains by using newer APIs. In this situation, Leopard-specific development makes a lot of sense.

Leopard-only apps have one more significant advantage: they widen the gap between Mac OS X and other platforms. As far as I can tell, the complete lineup of frameworks in Leopard is unmatched across the industry. The more that apps showcase these frameworks, the more apparent the value of the Mac will be to both users and developers, which benefits all of us.

Comments Temporarily Disabled

I had to temporarily disable comments due to spam. I'll re-enable them soon.