Cocoa and Objective-C: Up and Running (by me) is now available from O'Reilly.

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.
Design Element
The Reasons for Leopard-Only Apps
Posted Jan 02, 2007 — 64 comments below




 

Scot — Jan 02, 07 2989

Well said !!

Jesper — Jan 02, 07 2990

Well written. I agree on most points.

There's a case to be made for the same argument for those of us who only put out free apps in our free time, though. If you're not plunking down $25 on the initial software, you're in fact far less likely to want to spend $129 for 10.5, despite paying less on the whole. "This software isn't worth paying for, yet he expects me to spend $130 on upgrading my OS to a version that just came out? The *nerve*!"

This doesn't mean that the benefits are fewer or lesser for developers, but it puts you in an awkward spot where people are expecting, in some scenarios, significantly larger efforts for something they don't have to pay for than something they do have to pay for. It's an interesting situation.

(I also like the "(remember, new year)" reminder in the anti-spam part of the comment form.)

Scott Guelich — Jan 02, 07 2991

Apple has definitely made Leopard enticing for developers. Let's hope that next week they roll out new features which make it just as enticing for end users. (Just to be clear -- I'm not saying *I'm* not already eager for Leopard, but I know others who have thus far been unimpressed with it.)

The rumor sites are full of grist right now. If there is a new face-lift, or if those "secret" features that Jobs didn't want to reveal back in August turn out to be biggies, it'll make it much easier for developers who want to go 10.5 only.

Seth Willits — Jan 02, 07 2992

Core Animation isn't for fancy 3D effects, it just happens that it can be used to do them.

Chris Ryland — Jan 02, 07 2993

And there are those of us planning to write new apps for 10.5 that simply couldn't be done before, given the new capabilities. Should be interesting.

Patrick Meirmans — Jan 02, 07 2994

The point is well made, but I think in these issues you have to keep your target audience in mind. I am currently writing a scientific app that will mainly be used at universities, and I am actually still targeting both Panther and Tiger. I know from experience that university computers are updated very rarely (some are still using Classic), so I am trying to be as backward compatible as possible, without making it too hard for myself.

Manton Reece — Jan 02, 07 2996

I agree with Patrick. For an educational app I work on it was only this year (er, 2006, I mean) that we finally dropped support for 10.2!

Otherwise, you make some good points. Especially for small developers, embracing new Leopard APIs will allow for entirely new kinds of applications, and that's great. The one place I disagree is the importance of Objective-C 2.0 features, in particular garbage collection. I'd argue that those only make the developers life a little bit easier, and taken alone are not worth leaving Tiger. (I may be in the minority here, though. I didn't think Bindings was that important either.)

Rob — Jan 02, 07 2997

Now if ONLY Apple would provide a coupon with new MAChines for the OS upgrade !?!?!?!?

ssp — Jan 03, 07 2999

In principle I agree with your points, Scott. Saving time and investing in the future probably is where the money is.

The only thing that puzzles me about the upgrades are old machines of which there still should be plenty around. Already the switch to X.4 was quite taxing for early G4 models without a lot of memory or G3 models. And for X.5 I suspect it just won't be worth upgrading on those old machines, so these users (like my mum, say) probably just won't be there for the wonders of X.5 and they won't upgrade either as even an old Pismo works very well for e-mail and web surfing.

Of course that won't affect products like Delicious Library which has always performed poorly on such machines, but for applications with better performance it may make a difference.

The other question is where you are coming from. If you are starting a new application, it's probably much more compelling to use all the new features. If you already have a working code base, it may be trickier to decide whether it's worth to reduce the target audience just to include a new feature.

Whenever I look at the code I've written in the X.1 and X.2 days, I sigh at the time I wasted just handling variables, storage and so on.

the boy Ken — Jan 03, 07 3000

Memory management is not a differentiating feature

I think you mean "Memory management shouldn't be a differentiating feature" ;)

Jeroen Leenarts — Jan 03, 07 3003

Too bad you didn't mention the option of maintaining separate code-bases. Very often when you get to the download page of an app they offer an old pre-tiger version and a tiger version. While it is obvious that the pre-tiger version would lack features, atleast there is something available.

Especially when updating an existing app to use a newer version of OS X, why not offer a friendly licensing scheme that allows a buyer to use the old version for now and let him get the new version for free when he had the chance to upgrade.

The different versions will grow apart in features rapidly, and perhaps you'll stick to bugfixing the old version, but atleast you don't leave a user out in the cold. Especilly since before updating your codebase to the latest and greatest you already had a tested release available to the old world.

Michael Stroeck — Jan 03, 07 3004

I think you mean "Memory management shouldn't be a differentiating feature" ;)

LOL, you're probably right. It's not usually in the marketing copy, but not having something shout "EXC_BAD_ACCESS" every five minutes actually is a differentiating feature.

Andy Warwick — Jan 03, 07 3006

I think one of the key issues for me is that Apple do such a great job of ensuring that new versions of the new OS still run at acceptable rates on old hardware, often even better than the previous version.

That means--for me at least--upgrading the OS is a no-brainer, as I don't have to upgrade the hardware at all, and it's *still* like getting a new machine. I'm there in pretty much week one every time, though often I'll wait until the first point release before installing.

I'm all for developers and software taking advantage of new OS features, as that's what makes the Mac experience so good, and get pretty annoyed when they don't for a long period of time.

I think it would be a very different landscape if a new OS = new hardware, where I could see a point in staying in an old system and using old versions of software, but as long as my box runs the latest and greatest, bring it on.

Preston — Jan 03, 07 3008

These public declarations of Leopard requirements by Mac programmers is interesting, because when Tiger came out, the majority of apps retained 10.3 compatibility, and only new apps required Tiger. Leopard is such a developer-friendly release, and it's easy to see why programmers are excited to use it.

John C. Randolph — Jan 03, 07 3009

A crash that happens 45% of the time? Luxury! ;-)

Seriously, I recall one threading bug that tended to hit about 1 out of 100 of an app's users, and the users affected would only see it maybe once every two weeks or so. The timing window for the crash to occur was probably less than a milisecond, and the crash would only happen on mulit-processor machines. When Joar Wingfors sent me a test case that would reliably hit the crasher within a few minutes, we were able to finally close a bug that we'd had for years in OS X.

GC wouldn't have solved that particular problem (it was a locking issue), but memory management bugs in multi-threaded code have cost a lot of developers a lot of time and money over the years.

-jcr

Jesper — Jan 03, 07 3010

Jeroen: In my experience, most "for older OS versions" alternatives are simply old versions that are kept around precisely because they are useful for people with older OS versions. It's a good extra mile to go for your users, but what happens when bugs are found and need to be fixed in the old version?

In my opinion, maintaining two codebases should be done only when you have a very strong desire to both appease the group of users that have the old OS version and use the newer capabilities to build a better application, and have the resources (time, developers if you're a company) to be able to turn on a dime to fix a bug *for any of the two versions*. Actually maintaining two codebases in order to be able to write less, better code in one of them sounds really, really inefficient. I see how there can be motivators, but it's not a position I personally would put myself in.

David — Jan 03, 07 3013

New tech is all very well, and of course geeks will always be attracted to it, but let's remember that a new feature isn't of much use if your customers can't (or won't) actually use it...

If your customers are early adopters (i.e. geeks) or you target the Mac bloggersphere for marketing or kudos purposes (a market which is unrepresentative of the Mac market as a whole) then ok, fine, Leopard is a no-brainer.

BUT, if you have an established customer base, representing a fair spread of the Mac user base, then as a business person (i.e. not a geek) you'd have to seriously question doing Leopard-only development at this stage. Anyone with such a customer base here can tell you that their customers aren't all going to switch to Leopard immediately, any more than they all rushed out and bought Tiger over night.

As for Delicious Library, anyone who believes that Wil has all the answers in this department should contact me about some swamps I need to sell. Unlike the vast majority of developers around here, Wil has an established product and customer base and revenue base that allows him to make such a jump. Remember that Wil will no doubt continue to sell both versions of his products. That may make him a canny businessmen but such a tactic is hardly logical for all developers.

Bret — Jan 03, 07 3014

One of my projects is a scientific app that would not be readily possible on the desktop without Leopard - the address space requirements are too big for 32-bit oses, and doing my own VM scheme without hardware help would be a major pain in the neck (and inefficient too - it doesn't lend itself to being chopped up into large blocks). The server/ui-app model doesn't work well for it either. Fortunately, I can set this thing up with Leopard on a Mac Pro, with 4 raptor hd's in it in a raid 0...

akatsuki — Jan 03, 07 3015

I have no problem with the new APIs. I always just thought it would be nice if you tried to run the software on too old of a system, it would just automatically download the older version and provide a warning that this version was unsupported.

Matt — Jan 03, 07 3017

Looking back at the last year or so working with Tiger, I don't think memory management was my biggest bugaboo, not even with threads. The hard stuff nearly always comes down either to figure out how to make the framework do its thing, or how to hack it to do what all the other apps do, but Cocoa doesn't do out of the box. The big one was outline views / tree controllers -- completely half-baked in Tiger, requiring a major hack into Apple internals, which will need to be revised for Leopard. Core Data, a wonderful feature with very little documentation ;-) And all those little things, like table views where adding a new object should cause that object to be selected and its text put into edit mode, and then selecting the object again when return is hit... The AppKit still needs lots of work to factor into the core classes lots of behavior that 95% of apps need and users expect, and that "just works" in all those Apple apps.

Rob — Jan 03, 07 3019

Guys, there's a very easy way to see what's happening out there... Omnigroup publish the stats for the info they collect from their software updater:

http://update.omnigroup.com/

delta — Jan 03, 07 3020

I'm not quite sure if some of the assumptions are true.
- Users who don't upgrade their OS are less likely to upgrade apps

I'm very sure this is wrong. There are a lot of reason to stay at 10.3.9 OS X Server as example. People with networks don't switch as long as they have better apps at PPC, MS-Office for example and Photoshop.
We don't speak for OS X behind 10.3.
There are complex or less complex applications. Textmate is a less one - not a bad one. But is still an editor not a CMS or an IDE. If there is an old 1.5.X and a new one no one get hurt.
Photoshop or Office - iWork it we'll hurt a huge base of customers, that I don't believe that they can abandon the PPC Universal class for say a year or two.

Garbage collector was implemented in Oberon about 14 years ago. Can anyone explain why Objective C shouldn't have it for say at least 4 years.

It comes probably to the question - does Objective C 2.0 run on PPC ?

Jesper — Jan 03, 07 3021

delta: Everything Apple is doing that's not *only* technically possible on Intel - like Boot Camp - is Universal, working on Intel chips and PowerPC. So yes, Objective-C 2.0 runs on PowerPC, as well as garbage collection. (In 10.5, you have three choices: Objective-C 1.0, Objective-C 2.0 or Objective-C 2.0 with GC. And the Ruby and Python bridges, naturally, which are garbage collected natively.)

David — Jan 03, 07 3022

Rob, the omni group develop a certain type of "technical" app (outliners, dev tools, technical and processing diagramming, etc.) It should come as no surprise that a company that specializes in the creation of technically-oriented apps should mainly attract technically-orientated customers, who will naturally tend to be up-t0-date with their software and whom actively seek out the latest and greatest.

Thus, I wouldn't think that those stats are representative of the greater Mac marketplace, where the level of tech savvy is much lower than seems to be generally appreciated by many Mac programmers.

It's important to remember that the vast majority of Mac users do not even know what a Disk Image is. (And who can blame them? It's not a disk, nor is it an image. How come Preview or Photoshop won't open the silly things?)

Programmers, being programmers, tend to view things from the technical aspect, and tend to justify their decisions accordingly. Thus, if it's easier for the programmer to design and write their code, then that must be better for the customer, right? (Even if the customer has to buy a brand new OS!)

Shaun Wexler — Jan 03, 07 3023

One reason NOT to use Leopard API's are in fact due to the automatic garbage collection, which temporarily suspends the process during its operations, thus making ObjC 2 a poor choice for high-performance / realtime applications, not to mention the additional overhead of the @property lookups, etc.

Bret — Jan 03, 07 3024

Shaun - I'm pretty sure that's not right.

Based on published sources (http://developer.apple.com/leopard/overview/tools.html) I was under the impression that the system frameworks are implemented without garbage collection; with retain, release, and autorelease turning into no-ops when garbage collection is turned on.

As for property lookups, that should have about the same overhead as a standard accessor method (er... you are using accessors, aren't you?).

Now, if you need to go straight to the metal for max performance, then go down to pure C, or even assembler, and dodge the Obj-C runtime entirely...

David Young — Jan 04, 07 3025

Wow. So far, no one has mentioned that developers of Leopard-only apps will only have to QA on one version of the operating system.

Passing a strict (ie, good) QA cycle means thorough testing on all supported platforms. For every platform you add, that's another row or column in the QA matrix. Consider (Intel, PowerPC) * (10.4, 10.5). That's already four supported "platforms".

Dropping Tiger support makes financial sense because a) statistics (both from Omni and those I've observed myself) prove that 90% of the Mac user base upgrades to the latest within a reasonable time frame and b) supporting Tiger adds +100% to your testing load. At some point in time, you'll be spending an extra +100% in testing to gain %10 of the market, which is a crappy investment of your engineering time.

It's really more than 100% effort to support legacy OS versions because in addition to testing, engineering will have to spend time coming up with a plan to support both, implementing new features in just one or both codebases, conditionalizing features, etc., etc...

And if your engineering and QA departments are the same person, well, then, someone clearly doesn't have the time to support the legacy OS. :)

Sune — Jan 04, 07 3026

ur such a nonce

bowerbird — Jan 04, 07 3027

i look forward to developers who will require leopard.

it'll give me a chance to rip off their functionality and
sell _their_ programs to people with older systems,
who will have no other choice but to buy my clone...

like picking up money someone else left on a table.

-bowerbird

Bryan — Jan 04, 07 3028

I agree with this post and thank you for writing it. I am not a developer so I don't fully understand the new API's but I do see from Steve Job's demo of Core Animation how it can save devs a lot of time and I certainly am for the idea of boilerplate stuff being pre-made or very easy to code such as memory management so the developers can focus more on what makes their programs unique. The more Apple enables that the closer I become to being a dev myself and I'm fortunate enough to be able to buy Leopard so I really look forward to this new level of more reliable software.

Martin Pilkington — Jan 04, 07 3029

Shaun - You have to remember that Garbage Collection is opt-in. You can choose to use the Leopard frameworks with manual memory management or you can turn GC on in your app and it will ignore all your retain, release, autorelease methods.

As for going to leopard, I plan on going to Leopard only with version 2.0 of my app. However, I only released 1.0 in november and have several versions lined up between now and then. The problem of course is that building up my target base is far more important at the moment than using Leopard technologies. You should really only go Leopard only if you have a new application under development or a major upgrade to an already popular app. If you have just released a 1.0 then you should try and wait until a 2.0 to make it Leopard only.

Also changing to Leopard only with a 1.x update would just piss off customers, who have likely bought your app on the understanding that all 1.x updates would be free. You are effectively making them pay an upgrade fee to get features of your app they thought would be free.

Dan Price — Jan 04, 07 3030

It's a bit early to start introducing 10.5-only apps when 10.5 hasn't even been released. I've not yet released my app yet but I still have to support 10.3.9 because that's the OS my beta testers have. Their are a lot of people out there still using Panther and we can't abandon them just yet.

I don't agree with Mr Young's statement about '90% of the Mac user base upgrading to the latest OS within a reasonable time frame'. 90% of his users perhaps. There are plently of people out there still using Jaguar and even OS9! Most users I know are still on 10.3 with PPC macs.

I agree that 10.5 is looking super-cool, but my obligations to my partners means everything I produce must work on 10.3.9+.

Vanish — Jan 04, 07 3032

David, It is incorrect to state that Omni provides only technically-oriented apps. An outliner is far from technical and much more firmly rooted in the administrative space. Likewise, while it would be nice to assume most Graffle users making flowcharts, the reality is it's the Mac's only real Visio comparator and I have seen it used far more as a staff heirarchy and rapid charting tool in conjunction with Keynote and PowerPoint.

And those are just the business uses. My son and daughter, both in college, use OmniOutliner for homework assignments. Claiming Omni's audience is strictly technical in nature is far from correct.

Scott Stevenson — Jan 04, 07 3033 Scotty the Leopard

@Shaun Wexler: not to mention the additional overhead of the @property lookups, etc
Properties are generated by compiler. There's no overhead that I'm aware of.

somaking — Jan 04, 07 3035

I bet part of Apple's strategy for selling new OS versions is upgrading the APIs each release. Developers eventually get forced into using the new ones (like when they started using NSIndexedSet for NSTableView multiple selection management).

With Leopard I think the new features are largely developer candy. However the latest set of APIs are the most advanced in the industry for many applications. Its a good strategy for selling hardware, which is Apple's core business.

Betty Normal — Jan 04, 07 3036

Answer this one... Is it better to send $129 on a new Os. Or $999 on the latest MS$ Os (new compooter required!). Mac remain useable longer $129 is a small price to pay for a faster new compooter!

Betty.

Betty Normal — Jan 04, 07 3037

that should read spend not send! ;-)

Scott Stevenson — Jan 04, 07 3038 Scotty the Leopard

With Leopard I think the new features are largely developer candy
Possibly, but we don't know all of what's going to be in Leopard yet.

Steve Madsen — Jan 04, 07 3039

Theoretically, is it possible for Apple to ship an update to 10.4 that enables GC? Sounds like the other Objective-C 2.0 changes are mostly syntactic sugar, handled at compile time.

If GC could be backported to the Obj-C runtime on 10.4, developers could still take advantage of it while not completely abandoning customers slow to move to 10.5. That would be awfully nice.

Scott Stevenson — Jan 04, 07 3040 Scotty the Leopard

Theoretically, is it possible for Apple to ship an update to 10.4 that enables GC?
I don't think there's any motivation to do that, really. And it would probably be a lot of work.

Jesper — Jan 04, 07 3041

Steve: The Obj-C2 runtime is deeply reworked in places - it's certainly more than just syntactical sugar. I'm sure the GC could be back-ported to 10.4, but that makes another Obj-C environment for Apple to maintain (Obj-C, Obj-C+GC, Obj-C2, Obj-C2+GC) unless they also backport Obj-C2. Porting removes a small bit of leverage that they can use to tease developers to upgrade to 10.5.

I'd like it every bit as much as you would, but I'm not holding my breath.

Sengan Baring-Gould — Jan 04, 07 3042

I think OmniGroup's statistics are slightly slanted because OmniGraffle ships on new Intel Macs. More than 30% of my users use PPCs (more like half).

David — Jan 04, 07 3043

1. Vanish, nowhere did I say that the Omni Group make "strictly" technical apps. That just happens to be their focus, as a quick look at their product lineup will show. Clearly, obviously, their applications are geared towards a somewhat different user than, say, a typical iLife application.

2. David Young writes:

Dropping Tiger support makes financial sense because a) statistics (both from Omni and those I've observed myself) prove that 90% of the Mac user base upgrades to the latest within a reasonable time frame and b) supporting Tiger adds +100% to your testing load. At some point in time, you'll be spending an extra +100% in testing to gain %10 of the market, which is a crappy investment of your engineering time.

You must have access to statistics that are very different from mine. I disagree entirely that the 90% of the Mac user base upgrades quickly to a new OS. Certainly the bloggers and contributers hereabouts will do so, but the broad base of Mac users? No way.

Anyway, it's up for each developer to do the math himself. If you're developing a brand new product, or are able to to build a new version of an existing product and sell both, then then Leopard is probably a no-brainer.

A final caution: developers shouldn't get carried away about Brand New Feature X. Something like Core Animation may well be neat, but putting it to use in a shippable application is still a major task, requiring all the usual design, testing, re-design, etc. You may get instant functionality, but you don't get an instant product, let alone a good one. Similarly, switching over from one animation/rendering technology in an existing product is a far trickier task than designing with that tech from the ground-up.

Sausage — Jan 04, 07 3044

RE: Picture yourself going to see Flying Meat or Delicious Monster perform live (weird how those actually work as band names)

Actually there was a band named Delicious Monster, a great UK indie band from the early '90's.

From http://www.rachelmayfield.com/biog.html:

Rachel Mayfield began her singing and writing career in the 1990’s, fronting indie/rock band ‘Delicious Monster’. The band released five EP’s and one album to critical acclaim in the alternative music press, and made 'Single of the Week' in both NME and Melody Maker. They were named ‘Best Band in the World’ by Caitlin Moran of The Times newspaper, and voted favourites of Suede and the Boo Radleys, going on to tour extensively with these and other alternative rock bands of the era, including Dodgy, The Cranberries and Belly.

They had two top ten indie hits after being championed by John Peel and Mark Radcliffe of BBC Radio One, and featured regularly on MTV. The band then suddenly split.

Dan Price — Jan 04, 07 3045

Am I the only one here who hasn't used the 10.5 preview? :P

Tom — Jan 05, 07 3048

David,

Vanish, nowhere did I say that the Omni Group make "strictly" technical apps. That just happens to be their focus, as a quick look at their product lineup will show. Clearly, obviously, their applications are geared towards a somewhat different user than, say, a typical iLife application.

"Technical" doesn't mean everything but media. I don't think making diagrams is strongly correlated with getting jazzed about OS upgrades, even when the diagrams are "technical". OmniWeb is geekier than Safari, I guess, but it's no Firefox. Apple has bundled Outliner (along with iLife) for years. Graffle and Plan are at least as much business as technical. Dazzle? DiskSweeper? Dictionary? The only thing that really screams "developers" is ObjectMeter. Their next app, Focus, is an organizer. On the whole, I'd say their main focus is the iWork set.

Tom — Jan 05, 07 3049

An interesting datum: 70% of Omni's update checks come from systems purchased within the last year--that is, Intel systems. This is obviously skewed because of the Switch, and it presumably includes trial users as well as paying customers. Also, most companies don't have a bundle deal with Apple, but Outliner can only check for updates if its run. Food for thought.

Michael Stroeck — Jan 05, 07 3050

With Leopard I think the new features are largely developer candy.

That's impossible to say, since some amazing parts are said to be kept supah-sikrit(tm)... However, unless you're in the Early Start Kit program, believe me, you haven't seen half of the cool developer-centerd stuff in Leopard. Apart from that, there is no such thing as "only good for developers", any improvement for developers inevitably is an improvement for end-users.

Paul N — Jan 05, 07 3055

It remains to be seen if Leopard will offer substantial improvements for the end user, enough to warrant the $129 price. The ADC seeds certainly don't show it... And I don't know if many users will want to shell out that much money for the OS, if its prime utility turned out to be "TextMate and Delicious Library upgrade enabler".
(For example, Time Machine requires a second HD -- how many Mac users have that? Maybe 3%? The vast majority have just the one slow disk that their non-upgradeable iMac or PowerBook shipped with.)

Yes, I know about the Inkredibl Sikrit Leopard Feechures to be shown next week... I guess we'll just see how that turns out.

I hate to say, my feeling is that the vast majority of developers out there just aren't very impressed with Leopard's improvements, and would contend the notion that Apple's frameworks are "unmatched across the industry". GC? That's so 1997. Obj-C properties and foreach syntax? Ok, these are useful improvements, but very modest compared to Microsoft's language/runtime improvements in .NET 3.0. Core Animation? Well, it's not unlike Microsoft Avalon/WPF... Except that Avalon is both shipping in Vista and backported to XP as part of .NET 3.0.

That's a significant point, IMO. Microsoft is making a strong push with their impressive new language support and APIs, and they've made every effort to make them available even on 5-year old PCs (with the major exception of DirectX 10, which is Vista-only).

Apple, OTOH, basically hopes that their developers want to be on the cutting edge so much that it may cloud their business sense. Looks like it's working. Overall the Mac dev community's attitude seems to be turning towards "if you can't afford the New Stuff all the time, you shouldn't be on the Mac anyway"... I recall the Mac community used to be much less consumerist before Apple rediscovered its massive hubris through iPod/iTunes. Maybe it's just nostalgia.

Scott Stevenson — Jan 05, 07 3060 Scotty the Leopard

I don't think I could disagree more in terms of the improvements for developers. On the other hand, I have the benefit of having been to WWDC, so maybe this is just a case of most people haven't seen what's included yet. I'd be really surprised if everyone you know is still so jaded in a few months. It could also just be a difference in opinion.

I'm not sure I understand your point about backporting APIs. I can see why Microsoft did it, but I don't think Apple should do it just because Microsoft did. The two companies have some overlapping markets, but ultimately very different priorities and different sorts of revenue streams.

if you can't afford the New Stuff all the time, you shouldn't be on the Mac anyway
I don't think that's a fair characterization. Given infinite time and resources, developers would like to support everyone. Instead, they do the best they can and make some tough choices. Some choose to aim for the short term, others aim for the long term. There's no one right option. In fact, the ability to apply more focus to a specific kind of user gives independent developers a edge over larger companies like Adobe with much bigger checkbooks.

Apple, OTOH, basically hopes that their developers want to be on the cutting edge so much that it may cloud their business sense
In my opinion, business sense is more than just "support the most configurations of hardware and software." The pure business outlook is really "do what's going to sell the most copies." What Adobe or Microsoft has to do to make that happen is much different than what Macromates or Panic has to do.

I recall the Mac community used to be much less consumerist before Apple rediscovered its massive hubris through iPod/iTunes
My impression is that Apple has always been consumer product company, and I don't see how hurbis enters into it. Or did I misunderstand your point?

David — Jan 05, 07 3062

Scott writes thusly:

The pure business outlook is really "do what's going to sell the most copies." What Adobe or Microsoft has to do to make that happen is much different than what Macromates or Panic has to do.

Yup, which makes it even more important that we do our homework and determine the business realities of any such Leopard-only dev, instead of just adopting the latest and greatest tech because it makes our garbage collection easier.

The premature adoption of any tech can cost heaps, especially when you are ahead of the actual sales curve of that tech. It's all very well being on the cutting edge, but every now and then you bleed. Any OpenDoc, QuickDraw GX or OpenTalk developers/survivors around here still?

Chuck — Jan 05, 07 3063

Overall the Mac dev community's attitude seems to be turning towards "if you can't afford the New Stuff all the time, you shouldn't be on the Mac anyway"... I recall the Mac community used to be much less consumerist before Apple rediscovered its massive hubris through iPod/iTunes. Maybe it's just nostalgia.

Eh, we're talking about company that arrogantly rejected disk drives and forced people to start using USB peripherals way before anybody else jumped on that bandwagon.

The premature adoption of any tech can cost heaps, especially when you are ahead of the actual sales curve of that tech. It's all very well being on the cutting edge, but every now and then you bleed. Any OpenDoc, QuickDraw GX or OpenTalk developers/survivors around here still?

Those are technologies that died due to lack of developer support — precisely the fate you seem to be advocating for Leopard here. It's not as though a ton of people rushed out and made OpenDoc apps, but the users refused to get the technology.

Anyway, I don't think backwards compatibility should necessarily be thrown out, but it seems to me that people who are going to buy shareware and keep it up to date are not the sort of people who will generally balk at $100 for a major OS upgrade every few years.

Manton Reece — Jan 05, 07 3065

Okay, I'll admit to actually purchasing OpenDoc and PowerTalk software, although clearly I was in the minority. But to say that those technologies died because of lack of developer support is a little misleading. The fact is that stuff was very complicated to implement. The AOCE book weighed 50 pounds and OpenDoc required a completely new way of thinking about the UI and storage.

Core Animation is a walk in the park by comparison, and it will receive widespread developer support as a result.

David — Jan 05, 07 3066

Those are technologies that died due to lack of developer support

???

Heh heh, that's hilarious. And do you have any explanation as to why these technologies weren't supported enough? Could it be to do with the... technologies themselves perhaps?

Anyways, from a business POV, this argument really seems to boils down to two things:

1) Will Leopard make life so much easier for the developer that he will profit from increased productivity (from tools improvements, gc, only having to tend to one build, etc.)?

2) Will Leopard provide for enough new useful, marketable features that will justify the costs of doing Leopard-only development at this point in time?

Michael Stroeck — Jan 06, 07 3068

(For example, Time Machine requires a second HD -- how many Mac users have that? Maybe 3%? The vast majority have just the one slow disk that their non-upgradeable iMac or PowerBook shipped with.)

Your analysis of Time Machine is Not Even Wrong (tm). Time Machine will be to external hard-drives what the original iMac was to USB devices. End of story.

Histrionic — Jan 06, 07 3071

I think I should mention that security policies in some organizations now require that you must be able to get updates for your software. This has some implications about what larger groups of Mac users—such as within enterprises—may be running for their OS.

With Mac OS X, there is no clear evidence—yet no documentation one way or another from Apple—that there will be updates to 10.3 or 10.2 after 10.5 is released. The evidence so far is that Apple will only provide software updates for 10.4 and 10.5 when 10.5 is released. We no longer see security updates for 10.2 now that 10.4 is out, and we only see updates for the current and immediately preceding major release.

Beyond that, I do think if Leopard provides developer candy, it provides the candy equally for Apple and external developers.

Uli Kusterer — Jan 06, 07 3073

@Michael Stroeck: It's kinda silly to do a backup that will break along with your Mac when you drop it. External hard disks are a much better solution there.

@David: OpenDoc supposedly died because it relegated applications to being parts of Apple's OS. So, most users wouldn't even have known that the thing they just used was Word. It makes marketing very hard if you can tell nobody in a few clear terms what your application is.

QDGX never really got a chance to be adopted because it didn't really provide many differentiating features, made it *harder* for devs to use it and then Rhapsody came around. Apple learned from that, which is why they're not giving us QuickDraw 64-bit (though AFAIK it exists... probably necessary for QuickTime and iTunes), and they didn't extend Quickdraw but rather invented CoreGraphics and are now shoving that down Carbon programmers' collective throats.

And the whole System 7.1 Pro Fiasco didn't really help much either.

Michael Stroeck — Jan 06, 07 3074

@Uli Kusterer: Which was kind of my point? I don't exactly know what you mean...

David Lyles — Jan 06, 07 3077

In fact, an impressive Leopard app may attract more users then a Tiger-only app ever would.

Minor typo here: should be than, not then.

turing — Jan 07, 07 3080

I see many developers talking about new applications that "just wouldn't be possible" without Leopard.

Could someone pose an example?

Every modern digitial computer is Turing-complete. Leopard isn't going to change that. From Wikipedia:

Turing completeness is significant in that every plausible design for a computing device so far advanced can be emulated by a universal Turing machine. Thus, a machine that can act as a universal Turing machine can, in principle, perform any calculation that any other computer is capable of (that is, if it is programmable). Note, however, that this says nothing about the effort required to write a program for the machine, the time it may take for the machine to perform the calculation, or any abilities unrelated to computation (such as communication or randomness) which the machine may possess.

So, it might be *very difficult* or require a great deal of time to do on Tiger or Panther what you could do on Leopard, but it isn't impossible.

Scott Stevenson — Jan 07, 07 3083 Scotty the Leopard

So, it might be *very difficult* or require a great deal of time to do on Tiger or Panther what you could do on Leopard, but it isn't impossible
If it takes an unrealistic amount of time to implement something, I don't see how that's different than impossible. I'd like you to memorize and recount Pi to the three millionth digit. It is thoeoretically possible, but given the amount of time involved, it really isn't.

In other words, possible means "possible given the resources available to you personally." Leopard APIs give you the ability to implement something that would otherwise not end up in your application.

Could someone pose an example?
Learning OpenGL and writing your own implicit property-based, threaded drawing API is not practical for many people. Instead, you can use Core Animation.

Tom at Omni — Jan 14, 07 3232

I'd like to chime in on the side of those who caution against assuming that the stats at update.omnigroup.com are representative and refer you to the text on that page that reads "Remember, this is not a poll of the Mac OS X community at large, just a subset of our customer base."

I happen to feel, with no data to back it up, that our users tend to be more proactive about going out and getting the latest and greatest software rather than to simply take what's in front of them, and merely being bundled really doesn't put Outliner in front of users as much as you might expect.

Hence, our users probably update their OS relatively proactively. To assume your users will do likewise and to therefore require Leopard would be a self-fulfilling prophecy.

On the other hand, increasing your work load by supporting a legacy you don't have to, while at the same time sacrificing features that could perhaps be easily supported on Leopard really isn't fair to yourself or your most deserving users.

Peter da Silva — Jun 12, 07 4324

(1) I don't upgrade every version of the OS, or every version of every app. Even on Mac, upgrading the OS takes time, and there's a risk of regression... if I'm getting a Mac because it "just works", because it saves time, why take that time?

(2) On the other hand, upgrading applications is less of a risk. If it saves time, I'll do that. On the other hand, I'll also consider switching apps then... if an app developer makes things hard for me (like requiring an OS upgrade) that's going to make it cost-effective for me to upgrade.

(2a) This is where bowerbird picks up a sale. :)

(3) What keeps you from using new APIs when they're available, and falling back to the older APIs when they're not. Either conditional compiled or dynamicaly selected at runtime via shared libraries. Obviously you can't do that for garbage collection, so if you're taking that effort on right now this doesn't apply, but every OS upgrade isn't going to have that impact on your app.

(3a) The "10.3" version of the app can simply be the same version built with a different set of #defines.

(4) Factor the application for portability, you can get a faster and more reliable application. Run multiple processes not just threads and you avoid getting blocked by process-blocking system calls - the resulting app can be more responsive.

(4a) And you can even separate the heavy lifting from the GUI and run your app distributed... amazingly easily.

kl — Oct 30, 07 4904

Since Leopard is now in the wild, can we get this text updated with post-NDA information?




 

Comments Temporarily Disabled

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




Technorati Profile
Copyright © Scott Stevenson 2004-2008