macOS Coding for compatibility with future OS X versions?

[itickings]

Since I started using OS X back in the Panther days, my impression is that whenever a new version of OS X is released there are tons of threads and complaints about applications not working in the new version of OS X. Some developers then release free updates, others require their customers to pay for an upgrade, and some won't provide fixes at all.

As a developer, I can relate to all three positions. The more interesting thing is why stuff break, and how to possibly reduce the risk of that happening to applications.

Now, since I've mostly developed software for embedded systems, servers, websites and Windows previously, I've only just begun scratching the surface of developing for OS X and hope that more seasoned developers will share their experiences on the topic.

If I develop an application now, what are your recommendations on how to increase the likelihood that for example 10.7 will run it as is? Or 10.6.x for that matter...

In your experience, what have the major pitfalls been historically? Are problems limited to things integrating tightly with the system? Is it use of undocumented or poorly documented APIs? Are completely unexpected, mundane things often at risk?

I realize there aren't any definite answers, and that 10.6 just got out, but any general suggestions or previous real-life experiences would be greatly appreciated. If the risk for problems can be reduced by following certain advice in addition to Apple's guidelines, I'd rather know it sooner than later in the development process.

 

[foidulus]

Since I started using OS X back in the Panther days, my impression is that whenever a new version of OS X is released there are tons of threads and complaints about applications not working in the new version of OS X. Some developers then release free updates, others require their customers to pay for an upgrade, and some won't provide fixes at all.

As a developer, I can relate to all three positions. The more interesting thing is why stuff break, and how to possibly reduce the risk of that happening to applications.

Now, since I've mostly developed software for embedded systems, servers, websites and Windows previously, I've only just begun scratching the surface of developing for OS X and hope that more seasoned developers will share their experiences on the topic.

If I develop an application now, what are your recommendations on how to increase the likelihood that for example 10.7 will run it as is? Or 10.6.x for that matter...

In your experience, what have the major pitfalls been historically? Are problems limited to things integrating tightly with the system? Is it use of undocumented or poorly documented APIs? Are completely unexpected, mundane things often at risk?

I realize there aren't any definite answers, and that 10.6 just got out, but any general suggestions or previous real-life experiences would be greatly appreciated. If the risk for problems can be reduced by following certain advice in addition to Apple's guidelines, I'd rather know it sooner than later in the development process.

As a general rule of thumb, the higher level the code you write, the less likely it will break with future updates, for example Apple strongly discourages monkeying with things at the Mach level unless you have to, because that is the most likely to change.

From Apple's article on daemons:http://devworld.apple.com/technotes/tn2005/tn2083.html

The Mach APIs represent the lowest level interface to the kernel. As such, they are the most likely to change as the system evolves. Apple has consistently recommended that third party developers avoid them. This applies to daemons and agents as it does to everything else.

That being said, Apple has an (unfortunate) history of being as secretive with many of its APIs as it is with its products. For instance QTJava has been deprecated, but Apple has yet to make an official announcement to the public, in fact they still advertise the API on their web site, however some WWDC attendees were brave enough to break their NDA to share that little nugget of knowledge. My company had a product that used QTJava heavily, and if I hadn't read that little nugget of knowledge, we wouldn't have been ready for Snow Leopard in any way shape or form. Furthermore, they have been known to make significant changes to APIs even in 10.x.y releases(such as QTKit). And who forget their decision to cancel 64-bit carbon GUIs at the last moment, that screwed a lot of people(even the big players such as Adobe were scrambling)

That being said, if you are developing a GUI app and keep everything in Cocoa without using any deprecated frameworks you should be fine. If you are coding a command line app, as long as you stick with standard C(or whatever higher level language you are using, python, perl, its all good) you should be fine.

 

[gnasher729]

Difficult. Don't use APIs that are deprecated and none that were deprecated in 10.4, that's common sense.

Don't have bugs in your code. Bugs often depend on unpredictable things which can change with a new OS. Quite possible that when some code doesn't work with a new OS version it is because the code was broken in the first place but it didn't matter with the old OS.

Don't do stupid things. For example, some code broke when 10.4.10 was released because some people did string compares with version numbers and believed 10.4.10 was less than 10.4.3.

Hope that Apple doesn't break things. Try to use APIs that look as if everyone would be using them, not eccentric things. If 100 programs use the same API as you do, then Apple will figure out if they break it. If you're the only one, they might not.

 

[Catfish_Man]

Try to figure out what Apple is using, then use that. It's less likely to change.

 

[Cinder6]

An obvious one is to not use private methods in the library classes.

 

[itickings]

Thank you all for your input, very appreciated.

Sticking to public, non-deprecated API:s and trying to minimize my own bugs is what I usually do best, and as I don't expect to do anything really close to the kernel or low level stuff for the coming projects, there is hopefully not much to worry about.

I realize that things may of course break anyway, anytime, even if all advice as well as Apple's guidelines are followed. One just have to hope Apple gets a bit better at publicly announcing changes and to give developers reasonable time to migrate/adjust...

 

[lloyddean]

Become a paid member of the "Mac Developer Program" section of Apples "Apple Developer Connection" support program.

The lowest level of paid membership is the ADC "Select" level membership at an annual costs $500. Paid members get access to early seeds of Apple software and documentation.

Access to upcoming software allows you an earlier opportunity to test your Macintosh software products against up coming software releases.

This includes early seeds of Xcode where API changes will show up in the header files.

Get in the habit of doing file comparisons between headers of the current release and up comming releases so as to note deprecations and additions. With this information be sure to READ the comments within headers used in the software you're developing. They are a good source of information and often make recommendations as to what to use in place of deprecated API's.