Today, Apple released the iPhone SDK. And, as we expected, we’re already being asked whether we intend to write a version of Adium for the iPhone.
The short answer is “yes, but…”.
Developing for the iPhone is similar in many respects to development for Mac OS X. Some of the same frameworks, such as Core Audio, are present. But a lot of them aren’t. For example:
- QuickTime (which we use to play sounds) is missing entirely. There’s a new Core Audio API to play sounds, but it’s Leopard-only, and we don’t know whether it’s available on the iPhone.
- The Application Kit (on which our interface is built) is replaced with UIKit.
- The iPhone probably does not have Apple Events nor Open Scripting Architecture. In other words, no AppleScript.
- Animation works a bit differently, and is dramatically different from how animation currently works in Adium on Mac OS X.
The hardware poses challenges as well. The iPhone has less memory than Adium tends to use, and has a significantly slower processor (and only one of them). Also, maintaining a network connection over WiFi uses a significant amount of battery, which could pose a problem for long-term use.
So porting Adium to the iPhone will certainly be a lot of work. Large portions, if not almost everything, will need to be completely rewritten or scrapped. Other parts will survive, but undergo extensive changes. This is a lot of work.
Currently, Adium’s base system requirement is Tiger (Mac OS X 10.4). Some of the iPhone’s features, such as Core Animation, were introduced in Leopard (10.5). Therefore, it’s likely that we won’t start work on Adium for iPhone until sometime after Adium for Mac requires Leopard.
Also, keep in mind that we’ll want to release that version of Adium for Mac and have it proven by users (that means you) before we go applying that knowledge to Adium for the iPhone. You wouldn’t want us to port an unstable version, would you? ☺
So, in summary: We want to do it, but it will be a lot of work. We want to put it off for a little bit so that it can be done with less effort and won’t interfere with other development priorities. We don’t know how long we’ll put it off and we don’t know how long it will take once we start.