Trillian for iPhone — Tech Briefing.
While we prepare to send out beta acceptance notes in the next week or so for the iPhone version of Trillian, we thought we’d share some notes about the technology behind Trillian for iPhone, as well as the bearing said technology has on the Mac OS X port, since we’ve been so silent on that for so long.
Those who are curious about the Mysterious Inner Workings of such things can read this post, while others may feel free to skip over; we won’t be revealing the Secrets of Life, the Universe and Everything or some secret handshake needed to get into the iPhone beta. 
Some Initial Notes
Those of you who have developed plugins for Trillian before over on Win32 are familiar with the concept of commands and events; commands are issued from an end-point (a medium plugin, for instance) to the core, and events are sent from the core to appropriate end-points. A medium, like AIM, might send a messageReceive command to the core, and the core might then send a message_receive event on to the UI. Similarly, the UI might generate a messageSend command to the core, which would then pass a message_send event on to the appropriate medium. When we talk about Trillian’s ‘core’ being able to be compiled and run on Mac OS X and on Linux, this is what we mean.
CocoaCore
The soul of the iPhone port of Trillian is something new called CocoaCore. CocoaCore is an abstraction of the Trillian core into Objective-C, allowing it to fit in with Cocoa or CocoaTouch (the primary toolkits upon which most Mac OS X and iPhone software is built). CocoaCore abstracts a Trillian session as a set of Objective-C classes, such as TrillianContact or TrillianConversation; CocoaCore handles all the events and commands, allowing the final program to interact with Trillian through methods and delegates as if it were a native Cocoa framework.
CocoaCore also makes use of the Astra network’s ‘asset’ technology to keep things in sync between multiple platforms. This is how the iPhone and desktop versions of Trillian can stay in sync, with assets like the user avatar or the contact list having their changes properly propagated to all connected and active clients.
And since CocoaCore supports multiple controllers the same framework can be used for both the iPhone port, which is powered by our Octopus server technology, and the native Mac OS X port which just has standard plugins. Yes, once CocoaCore was written for the iPhone, it made sense to redo the Mac OS X port atop CocoaCore instead. This means that though they have their own directories for UI code, Trillian for OS X and Trillian for iPhone actually compile out of the same source tree; fixes for one benefit the other. (This is why the OS X port went radio-silent, incidentally; we wanted to keep the native iPhone port somewhat quiet.)
The Octopus
The other part of the iPhone port’s ’secret sauce’ is the Octopus server technology. Octopus is a highly optimized, specialized variant of the Trillian core running on a server farm; you pass commands and receive events over the network instead of between the main executable and the core library. Octopus is also the technology behind the (currently offline) Trillian for Web client.
Because it runs on a remote server, the Octopus is ideal for mobile devices. Even if you run out of batteries, or pass into a tunnel with no signal, when you return your messages are waiting for you. And thankfully, Octopus is VERY good at healing itself from network problems, something we put to the test by having Scott and Rachel each take iPhones and walk in and out of wireless hotspots repeatedly. Mmm, free WiFi at Starbucks!
The Octopus is a fairly powerful technology, too, as only the flow control and security portion is particularly complex. An Octopus library could be easily implemented in PHP or Ajax, for instance, allowing web mashups of IM technology. The possibilities are endless, even if the Octopus is not a terribly user-visible technology in the same way as CocoaCore.
(As an interesting side note, the Octopus portion of CocoaCore can also compile on Mac OS X, allowing the same sort of robust network issue recovery as the iPhone. There’s some thought that offering Octopus as an option might be useful for Mac OS X users who are on a 3G wireless network card and experience periodic network drops or other issues.)
The Joys of Reuse
In the end, the iPhone port gave us the opportunity to create an entire new toolset for ourselves (CocoaCore) and to flesh out and vastly improve an existing one (Octopus). Both technologies are the sort that we can reuse, and our other clients — the web client backed by Octopus, and the Mac OS X port built on CocoaCore — will benefit very directly from all the work put in to the iPhone port.
There’s other possibilities for these technologies that we haven’t even really fully examined yet, but obviously we need to keep our focus on one or two projects at a time!
June 29th, 2009 at 2:12 pm
This is exciting news an all, but Astra (for Windows) has been in development for a LONG time now. While the beta is looking good, it still has a decent amount of show-stopping issues that need to be addressed before the final release. It seems like you guys may be spreading yourselves a bit thin. How about focusing on hammering out the remaining Astra issues and getting that released before taking on the iPhone app? Obviously your entire core group of supporters would benefit from the final Windows version of Astra, whereas not all of us have iPhones. Don’t get me wrong, I’m a big supporter of you guys (just re-upped my Trillian subscription), however I’m more excited about a stable, bug-free desktop version at this point. Thanks for listening.
June 29th, 2009 at 3:35 pm
Boo that. I’m on the edge of my seat waiting for the iPhone app. There are a number of sub-par chat clients out there right now that offer push notification but I don’t want to purchase any of them because I’m waiting for what I think will be the best one. I am more willing to pay for the iPhone port than I am for the desktop app even though I was a 3.0 Pro user. Sounds to me like Flyer00 doesn’t own an iPhone and therefore doesn’t appreciate what a valuable tool it will be.
I also disagree with the “numerous show stopping bugs” statement. It’s an incredible stable and feature rich beta for me.
Less features more ports!
June 29th, 2009 at 3:37 pm
Oh, and I’m seriously bummed I missed the beta invite list
Can I bribe someone to add me to it?
June 29th, 2009 at 3:43 pm
I agree, it seems to close to the final astra release. Can you at least make a final release date for it and focus on actually releasing it rather than lose some focus toward the iphone.
June 29th, 2009 at 4:18 pm
This is great news guys. I can’t wait to get my hands on the OSX & iPhone versions of Trillian Astra. Even if I’m not chosen, please continue to keep up the great work that you all are doing at CS. All you hard work and dedication to this project is much appreciated. Looking forward to assist you all in making this product the best of it’s class. Peace out.
June 29th, 2009 at 4:34 pm
@tpaine Actually yes, I do have an iPhone and use BeeJive IM which does offer push notifications. It works quite well actually. However after the initial novelty wore off and I actually tried to use it as my central IM app, I realized that while it is pretty sweet, the keyboard and battery life make it more challenging when doing heavy IMing and I find myself feeling more comfortable with the desktop app. Like I said, I’m a fan of Trillian. I have been a Pro user since the beginning. I’d just like to see Astra polished off and released before shifting focus to the iPhone app. I know it is very stable, but there are some bugs (the remote desktop bug comes to mind) that shouldn’t be in a final release.
June 29th, 2009 at 5:44 pm
@flyer00 While I hear your argument that the Win32 version of Astra needs to be completed in a timely fasion, I would be equally willing to hear an argument to the tune of waiting untill a complete “Astra Package” is complete. While it is unlikely, there is a chance that the octopus backend may change in a fasion that would require new clients, and that is best handled in a beta stage than after a final release. Also, marketing will be easier if ALL the features are available at launch.
Furthermore, not all of us run Windows. I am running almost exclusivly Linux, although I do have a mac for the purpose of talking to my iPhone. Therefore, I would argue that a mac and an iphone release are more important for some, especially if it leads to other ports like a Linux port, to some than the windows port.
Just my 2 cents…
June 29th, 2009 at 9:32 pm
Great news to hear! Been using Adium since I bought my Macbook Pro… will be nice to finally get back my favorite features on Trillian. Just need into that Beta program for that.
June 30th, 2009 at 1:35 pm
@Flyer00 — Though everyone here has had input into the client design, at the moment, all the CocoaCore work has only one client developer working on those projects until the Win32 stuff is fully polished and out the door. Win32 is definitely still the priority, and where the majority of effort and focus is.
July 1st, 2009 at 6:40 am
This is beautiful, but there are a lot of Mac users who would like to download astra ( me too
when astra for Mac (beta I guess) will became available for us?
July 1st, 2009 at 2:50 pm
Where does PUSH figure into the iPhone client.
Unless the iPhone IM client uses push, it become nearly useless since you are logged out the moment you switch to another app.
July 1st, 2009 at 4:12 pm
rbiro, they just added the ability for apps to run in the background to the iPhone… so that is a non issue.
July 1st, 2009 at 5:09 pm
@rbiro — If you look at the original announcement of the iPhone native application, you’ll see that it talks about push support. The Octopus servers are also an Apple Push Notification provider, which allows you to suspend the app and still receive notifications.
July 1st, 2009 at 5:40 pm
I’d really love to use Trillian on the iPhone. One feature that many people are looking is display of first and last names for the screenname found in the iphone/mac address book (similar to iChat, but strangely not found in any other application as far as I know). I’ve seen this request as well in other aim client boards too. In any event, the progress looks terrific. Look forward to seeing it in the app store!
July 3rd, 2009 at 4:24 am
I really can’t wait! I am so excited for the Mac and iPhone version.
I really I hope I get chosen as one of the beta testers.
July 5th, 2009 at 10:59 pm
Will there be a version of Trillian for Android? This is an up and coming very strong platform with a well-documented SDK and plus, who doesn’t like open source? Meebo has an excellent Android client but if Trillian was there, I’d def use that instead.
July 6th, 2009 at 10:41 am
Hey Guys – Tried to be a Beta tester but didn’t make it so when is the target release date for the Iphone client?? Can’t wait to get my hands on it?
Thx and AWESOME products guys!!
August 16th, 2009 at 7:40 am
I’m just hoping and praying that the Mac version of Trillian (when it eventually starts building steam again) will have some native options for Mac-like interfaces.
Don’t get me wrong. The Windows interface is beautiful. But I’m a long-time Mac user who has been using iChat and Adium for a very long time.
My Message To Developers: You have an amazing framework now to put Trillian on the Mac! Try to make it an app that looks and feels like it belongs there. Please?
September 28th, 2009 at 8:30 pm
Today’s date is September 28th. In typical Cerrulian style, drop a hint and go away for months. For those expecting Trillian for Mac, don’t hold your breath. This is a native Windows house.
September 28th, 2009 at 9:05 pm
Actually, if you check a more recent blog entry, you will see that we did indeed provide further information; the iPhone app was submitted to Apple on August 14th. Beyond that, we’re at the mercy of the app store reviewers. While a month and a half of review time at the App Store is frustrating, there’s little we can do; they’ve neither rejected us or given a list of any problems, just a ‘your app is under review, we apologize for the delay’ email.
September 28th, 2009 at 9:06 pm
As for the Mac version, I’ve been providing information and progress updates on the forum, where there’s an active thread about the OS X port.
September 29th, 2009 at 8:46 pm
Trying to locate any purely active thread for the Mac version is an exercise in futility. We, Mac users don’t automatically own iPhones. So any comment about the App store is meaningless to us. Every link to Astra Mac leads back to the iPhone, most postings on which date back 2 years. Perhaps you can relieve our frustration by providing a link to the thread you mentioned that contains recent postings for the Mac.
October 18th, 2009 at 1:56 am
Trillian Astra for Mac is just a huge lie. Cerulean has been telling its working on it for the last 2 or more years. In that time, the iPhone came up, PowerPC was deprecated and 64bit made its appeareance as standard. The Mac world will constantly change, and the developers are trying (are they?) to make a finished ultimate product. They will not. Its my guess, Trillian Astra will never see the light of day on the Mac side, and if it does, it will be to see the dark of night in a couple of days.
November 12th, 2009 at 1:04 pm
I have a tendency to agree with Ronal Poi that Trillian for Mac has been vaporware, but if Trillian for iPhone is a reality, it would indeed be a very simple matter to recompile it for Mac OS X. Trivial in fact. Thus either Trillian for iPhone is also vaporware, or there are other, perhaps political reason for Cerulean to be holding back a Mac OS X client. Perhaps that has been the case all along. Anyone want to posit a guess on this?
November 12th, 2009 at 2:25 pm
Honestly, no, it’s not so simple. The iPhone uses a library called UIKit, while Mac OS X uses a library called AppKit. While they are similar in many ways, there are also vast differences; a UITableViewCell on the iPhone does not simply compile out-of-box as a usable class on Mac OS X.
Similarly, the Mac OS X version loads dynamic libraries (or ‘dylibs’) which contain the medium code; this allows plugins, and allows your computer to connect directly to the various messaging networks. Apps on the iPhone are completely and expressly forbidden from loading any dylibs other than system libraries (libxml, libsqlite, etc.), and even if they could, connecting directly to the networks is not practical from a phone; you need an entire proxying system (which we call Octopus).
We /did/ reuse the iPhone build’s core — things like session management, contactlist data storage and so on — for the desktop app, now that the iPhone app is done (and still stuck in Apple’s review limbo); I’m working away on the OS X app as we speak. But there are sufficient enough differences that even though they compile out of the same source tree, one is not simply a ‘compile right into desktop app.’
The delay reasons are simple enough: there’s only a handful of us. The Mac OS X port requires two developers: Scott for the backend and medium libraries, me for the UI. When we had to really push to get 4.0 for Windows finished, Scott had to re-focus his attention back on Windows. The iPhone build, however, I could do almost all of that solo since we already /had/ the Octopus proxying system for the webapp, and then much of the iPhone build’s logic (conversation event handling, etc.) could be reused for Mac OS X.
That’s the simple reality of the scheduling; moving from OS X to the iPhone build made sense from a development time management standpoint. In retrospect, perhaps we shouldn’t have bothered, because now the app’s been sitting in limbo for 3 months. (And several of the beta-testers have either replaced a dead iPhone in that time or upgraded to a 3GS, and so want new UDIDs in the testing provision so they can at least keep using the beta… but the slots for registered devices on our iPhone Developer Program account are pretty much full, and you can’t delete them, only wipe the entire list once a year… augh! Ahem. Anyway.)
I’ve been trying to keep folks informed on the Mac OS X build’s progress, and sharing some of the design thoughts, in the thread on the forum: http://forums.ceruleanstudios.com/showthread.php?t=96434&page=3