While Teamprise officially supports Mac OS X (PPC), it will come as a disappointment to the rest of the mac zealots out there that the Teamprise Client Suite is not officially supported in OS X for x86. If I were reading about a product release in April 2006, and it included OS X PPC support but no OS X Intel support, I'd start wondering. After all, it's April 2006! Apple's shipping three machines with Intel chips, and the developer box has been available for nearly a year! Apple says making Universal applications is trivial, you just check another box in XCode! So why no Intel support?
Well, it's not always as trivial as checking another box - and leaving Intel support out of 1.0 was actually a trivial decision.
Remember that the Teamprise Client Suite is composed of three applications:
Teamprise Plugin for Eclipse
A plugin for Eclipse and Eclipse-based IDEs which provides access to Microsoft Team Foundation Server version control and work item tracking. Being an Eclipse plugin, this code is written in Java using SWT for its UI.
A standalone application for cross-platform access to Microsoft Team Foundation Server. Explorer is an Rich Client Platform application - since all the code necessary to access TFS exists in the plugin, along with a whole bunch of dialogs and UI code, it would be silly to rewrite that. Thus, Explorer is a Java app using SWT for its UI.
Teamprise Command Line Client
An emulation of Microsoft's TFS Command Line Client. Again, it uses the base of Teamprise, and so is written in Java.
But wait, you say - Java should be even more portable! The Intel Macs have Java 1.5 already installed. They should just be able to run that bytecode!
Ah, again, it's not that easy. See, we're not exactly 100% pure Java. We have some native functions to do some various things we can't do in Java. We'd also need to port these native functions to Intel. But this should take just a few minutes, right? Pass the
-arch flags to
gcc and you'll get a Universal library, right?
Yep, but there's still more. As I mentioned, we use SWT for our UI. It's basically a wrapper for native system calls. Where once Java apps were strange looking and slow, SWT writes directly to Carbon on OS X. The result is a real native-feeling1 application, and you should never know it was written in Java. SWT is great if you want to target a lot of platforms without having to think too much about it. Unless, of course, one of those platforms is OS X on Intel.
See, when Eclipse 3.1 was released, there were no Intel Macs. Eclipse 3.2 will support them when it's released this year. Until then, there is no official version of SWT and RCP for Intel Macs. We could have, a few months ago, made a big plunge and dumped Eclipse 3.1 in favor of one of the milestones of Eclipse 3.2 and gotten support for Intel Macs, but we'd be building against a prerelease for the platform we rely upon. It was clearly too big a risk to make a jump that big, that late in the development cycle.
So what's to be done? What if you've got a shiny new MacBook Pro, you're running Eclipse 3.2M6, and you want to access a Team Foundation Server?
Well, it's not as dire as it may have sounded - first, all our native code is already Universal, so if you happen to have an Intel Mac, both the Command Line Client and the Plugin will run. (The Command Line Client has no dependencies on SWT or RCP, and the Plugin will use your version of Eclipse's SWT.) I've done simple testing on my iMac and I can verify that both the Command Line Client and Plugin run and pass simple tests. Please note, however, that this was a stopgap solution for Intel Mac users, and has not been thoroughly tested. It is not officially supported by Teamprise.
That just leaves Teamprise Explorer. And I'll tell you what - if you need Explorer for Intel Macs, send an email to email@example.com, and we'll build a copy just for you. (Again, not officially supported.)
Hey, it's still better than what you'll get out of Adobe.
To be fair, SWT feels very native, but still has a few UI quirks, particularly for the Mac. But that's another article. ↩