Does a newly produced mac application need to support 10.4, and can I both support 10.4 and prepare for 64bit?

Question

My company is in the process of rewriting our software from scratch, and I'm the one who is going to be doing most of the work in rewriting the Mac client (The core of our software is Windows based, and the Mac client communicates with it through a webservice).

This isn't a real heavy app, mainly does some background work tracking stuff and a UI component for the user to enter information.

I'm trying to decide how hard I should argue for dropping support for 10.4 and going with pure 10.5+/Obj-C 2.0 code.

My main motivations for this are:

• It would be easier to code, I could use all the features of Obj-C 2.0 such as synthesized properties and fast enumeration.

• It would give me access to several classes, and methods in existing classes, that don't exist in 10.4 (Just in mocking up a UI I've come across NSPathControl and NSTreeNode, both of which I would otherwise be very happy to use.

• Preparing for the conversion to 64 bit coming in Snow Leopard. It seems like most of the techniques for preparing for the move to 64 bit (NSInteger, etc) are only available in 10.5+, and it would not be possible to use these if writing for 10.4.

The downside would of course be that we'd no longer be supporting an operating system that was only a year out of date.

My boss is himself supportive of this move, but of course has our customers to consider and doesn't want to cause any more issues for them than are justified. The director of support would like to support 10.4. I suspect the other execs will be marginally against it at first, just due to the not being able to support some customers thing. Everybody would be open to persuasion by a good argument from either side.

I'm trying to talk to some of the support people and get an idea of how many of our customers are actually still using 10.4, but I don't have that data yet.

Some kind of hybrid solution might be possible, such as rewriting parts of the old client to use the new webservice, or writing the client in 10.5 and backporting it to 10.4 if enough people made a fuss, but quite frankly those sound like they're likely to be even more trouble than giving up the 10.5 features and writing the code in 10.4 to begin with.

So I guess my questions are as follows:

1. Given the information above, do you think making a case for the adoption of 10.5+ only is the right thing to do? Do you have any suggestions as to how this might be presented positively to the rest of the company?

2. I don't know as much about the coming 64 bit transition as I'd like. Does anybody have any good references on what will be different, and do you think that supporting only 10.5+ would make this transition easier for us?

Answer 1

If it were I doing the update, I would target 10.5, especially since 10.6 is just around the corner and 10.5 did come out with a lot of great, new things (especially Objective-c 2.0). However, I think you really need to answer this question based on what you think your target customer group will be using. If they are slow to adopt new technology, it may be that you have to support 10.4 or risk losing a portion of your customer base.

On the other hand, you can actually target 10.4 and write using the 10.5 SDK. That way you can take advantage of all the preparations for 64-bit added to the SDK. You just have to ensure that you don't use any classes or features of the frameworks that didn't exist in 10.4. You can also do weak linking to the 10.5 frameworks and programatically decide whether you can use a new feature or not (while this is a bit of extra work up front, you can easily phase 10.4 support out of your code in the future and take full advantage of 10.5 improvements for users that actually are running 10.5).

There are a lot of blogs and write-ups about doing the cross-platform stuff out on the web. The other thing to keep in mind is that if you do target 10.4 make sure you have a 10.4 machine available to do a lot of testing (especially if you compile from the 10.5 SDK to take advantage of the 64-bit ready features). Also check the docks for any feature you may want to use from the 10.5 SDK. Many features were actually available in 10.4 but undocumented and the new documentation usually states which features you can safely use when deploying to 10.4

Answer 2

I never wrote production code in Objective-C and its hard to keep up, but as far as i am aware NSInteger and friends are in 10.4, it's just that Cocoa isn't 64 bit in 10.4 whereas in 10.5 most of it is (so no more need for seperate 64bit worker process under a 32bit UI).

I don't know what your product is, or who your customers are, but from my experience, Mac users are early adopters (relatively speaking) I've never used an OS X version longer than two weeks before the next upgrade was out, and in my circle I am a late adopter. Ofcourse I'm not just a business Mac user and that may well make a big difference.

What makes 64bits a requirement in your code? There's not much of a reason to not compile a universal binary holding as many architectures as you wish you could have one binary run on G4, G5, IA32 and IA64 no problem, and have it be native on all of them. If you're just doing 64bits because you can there's no reason (that I can imagine) not to keep supporting 32bits, but if you want stuff like CoreAnimation you don't have much choice.

I don't think it's wrong to demand 10.5 for new development, but it wouldn't make much business sense to force a whole new OS on customers just to keep using your existing product. So if you can, stay compatible, maybe backport your new features/patches for a time. There is a good reason for forking in version control and this might be it.

edit-

Since I posted this I learned that I was wrong and NSInteger did not exist before 10.5. I think I assumed too much having used similar types (like NSDecimal) earlier.

Answer 3

Do you need 64-bit? Unless your application is very CPU-intensive, it won't make any difference.

Tiger can run 64-bit applications, but without GUI. If you need 64-bit, you can create 64-bit CLI executable that does heavy lifting and provide 32-bit font-end for it (using NSTask and NSPipe).

You can also have separate .nib files for Leopard and Tiger:

-(id)init
{
  BOOL tiger = floor(NSAppKitVersionNumber) <= NSAppKitVersionNumber10_4; 
  NSString nibname = (tiger ? @"WindowTiger" : @"WindowLeopard");
  if (self = [super initWithWindowNibName:nibname]) 
  …

Answer 4

You really need to find out what your customers are using, and the support person is probably best positioned to know, or the product manager. That said there's nothing wrong with making the technical arguments clear now even if 90%+ of your user base were pre-Leopard; that way the issues will be known (and hopefully understood) so you'll have more support as the environment does change.