I owe you an explanation of why version 0.30+ of IMLocation now requires Mac OS X 10.5 Leopard. Originally IMLocation ran on both Leopard and Mac OS X 10.4 Tiger, so why the change?
As I write this, the Omni Group’s data shows 54.7% of people still using Tiger. The number is decreasing, but it’s still a majority. Alienating a majority of potential users is not something I do lightly.
Practical Reasons
Automator
At the highest level, IMLocation does stuff so you don’t have to. It all started as a small project in college to get my computer to update my iChat status when I changed classes. That means IMLocation is fundamentally an automation tool.
In Tiger, Apple introduced, “Automator, your own personal robotic assistant that will take care of whatever task you give it.” But, partly out of shortsightedness, and partly because there wasn’t (yet) support for editing Automator “workflows” graphically, I rolled my own “ActionsEditor“.
Then Leopard introduced powerful new widgets that let third-party applications construct Automator workflows in the same way Automator.app does.
It just didn’t’ make sense anymore for me to maintain my own Automator knock-off, when I could use the real thing. And, the real thing requires Mac OS X 10.5.
Another benefit of using Automator, now people can use special actions that IMLocation can do (e.g. disabling built-in speakers) in their own workflows.
Support and Quality Assurance
Writing code that runs on two operating systems obviously means more work, and that’s a reason for dropping Tiger support. But a bigger problem I had was quality assurance.
Since I don’t have dedicated testers, I have a lot of trouble doing enough testing of things I don’t use day-to-day. It’s not something I’m satisfied with, but it’s something I have to accept, given my resources.
I only have one computer and it runs Leopard. I don’t think I can do the necessary quality assurance to be confidant that things work on Tiger, because I don’t spend enough time in it.
Only needing to test one operating system means, I can ship with fewer bugs.
New and Improved
Leopard also introduced several technologies, like Objective-C 2.0, that are a big help to programmers, but can only run on 10.5. My hope is that by using them, I can deliver a more useful and stable product faster.
Personal Reasons
Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!
—The Red Queen
Technology has a shelf-life, and a learning curve. To stay on top of things I need to move.
Time to Learn
A new programming technology is usually bundled with a whole new way to do software engineering. For example, you need to know what Object Oriented Programming is to get the most out of C++, and even if you grok C++, you have to understand what “message passing” implies to get the most out of Objective-C. Just writing code the same way you always did in a new language won’t cut it, you need to experiment, and try new things. But that takes time.
Writing code that only runs on Leopard gives me the time to actually practice programming with newer technology. There’s no substitute for writing code.
Garbage Collection
It took me a long time to finally understand memory management in Objective-C; it was one of the biggest stumbling blocks to writing good Objective-C code. And then Leopard introduced garbage collection (GC), which is a whole new way of (not) doing memory management.
GC promises to make writing code much easier. But in my experience, when you have an issue with memory in a GC-ed system, it’s much more … esoteric … to understand and fix. It’s a poster-child for “there’s no substitute for experience”.
the iElephant in the Room
To write code for the iPhone, you really should understand Objective-C 2.0 — the iPhone’s frameworks use it heavily.
Transitions IMLocation to Objective-C 2.0 is much better practice for iPhone programming then writing Objective-C 1.0 code that is compatible with Tiger.
IMLocation development log 