The promise of Cocotron is a big one. Wrote a Cocoa app? Just add a new Xcode target, hit compile and out shoots a Windows version. Your mountains of Objective-C code now cross compiles and is no longer stranded on the Mac. You put your feet up, having just shipped a Windows app without ever touching a PC. Your cat brings you a freshly brewed cup of coffee. Read on for our journey from app to exe.

The Goal

Back in August, we decided that we should have a Windows version of our FileMagnet Uploader, a Mac application which connects to the iPhone via Bonjour and moves files back and forth between the desktop and our FileMagnet iPhone app. If you’ve been in this situation before, you know how much fun a line-by-line Windows port can be. Not only do you have to spend weeks hunched over Visual Studio, re-writing your entire program in a different language, but when you’re done you now have two separate code bases to manage. When a friend recommended that we check out Cocotron as an alternative, we were quite skeptical but agreed to try it out.

The Proof

Skip forward two months. We are now shipping a Windows version of our FileMagnet Uploader, built completely with Xcode from the same source files as the Mac version. Visual Studio was never opened. But wait… 2 months?

The Details

Let’s back up a bit. What is Cocotron? I’ll quote from the website:

“The Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.’s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation.”

In addition to this, you get a modified version of the gcc toolchain, allowing all this to be done from your Mac. The project has an MIT License.

It’s important to point out that Cocotron is targeting more than just Windows. All of the platform specific code is nicely abstracted using a bridge pattern. The Foundation project is implemented for linux too.

Cross Platform?

Let’s back up even more…

Get a couple of Mac software engineers together around a table of Chinese food and eventually they’ll start to debate the best way to do a cross-platform app. Usually, the nicest results come from using a combination of a cross-compiling core and platform specific UI code (a la Safari, Skype, PhotoShop, etc.) Anyone who’s tried to use most cross-compiling UI libraries knows that eventually what you end up with is an app that’s ugly and unruly on both platforms. At least with Cocotron, you end up with a beautiful Mac app, and hey, Windows apps are kind of ugly anyway so there’s no loss there.

Cocotron’s potential usefulness extends beyond user interface. It also includes a reimplementation of the Foundation framework. Foundation provides the powerful data structures, string handling, threading, I/O, etc., which is what makes Cocoa great for rapidly and robustly coding an app’s core logic. It would be a shame to have to use C++ for an app’s core instead of Foundation just because you need it to be cross platform. I can imagine a cross platform app which combines an Objective-C core (using Cocotron’s port of Foundation) with separate Mac and Windows native UI implementations.

Back to Cocotron

Simply follow the instructions to install Cocotron. Now, eagerly add the new Windows target to your Xcode project. Now, hit compile. Now, wait while the errors pile up like fan-boys at the Apple Store on a release day.

What’s wrong? Whoops! It turns out that your app isn’t only Cocoa after all. Okay, I’ll wait here while you go and #ifdef out all of that Mac specific code. That’s right… go find all the Carbon and other Mac-only routines (any Frameworks you’re using outside of Cocoa, such as AddressBook, CoreData, IOKit, CoreAudio, etc.) You’ll have to figure out how to port that stuff later.

Once your app is compiling, you’ll quickly realize that some methods appear at first glance to exist, but are actually just stubbed out for future implementation. Ever want to implement a Cocoa class method? Here’s your chance!

The Reality

The majority of Cocotron is spot-on brilliant, but here are some examples of the kind of things that we did to get FileMagnet up and running on Windows:

• Added unicode path support to the NSFileManager class.
• Added support for displaying truncated strings.
• Added support for drawing unicode strings. (Not very pretty support.)
• Fixed some issues with the NSSocket implementation.
• Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.)
• Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples:
– [NSPropertyList dataFromPropertyList:] (for binary property lists)
– [NSImage TIFFRepresentation]
– [NSFileManager subpathsAtPath:]
– [NSWorkspace iconForFile:]
– [NSMutableString replaceOccurrencesOfString:withString:option:]
• Additionally, Ken posted a few issues/requests to the Cocotron Google Group, and the team responded amazingly fast; they even implemented some functionality that we needed.

Now that the app has shipped, we’ll be merging our additions and fixes back into the Cocotron project as soon as possible.

The primary shortcoming of the Cocotron project may be the lack of a flagship product to drive the effort. It became apparent once we started the port, that the creators weren’t actively using it to create a shipping application. For comparison, take the Cappuccino project. They’re drinking their own Cocoa by using their new framework to make the awesome 280 Slides presentation tool. Cocotron desperately needs something in this vein to flush out bugs and unearth crucial but missing functionality.

I’m a PC

It’s true that we do build our app from Xcode, but we still needed to have Windows around for actually running, debugging and testing the app. However, in this day and age you don’t need to hop to a different machine. We simply used VMware Fusion.

One unexpected bonus was the ability to do source-level debugging of our Cocotron app. The website provides detailed step-by-step instructions for installing Insight-GDB. Once it’s all set up, just one click has you stepping through your Objective-C code on the Windows system. You can even step into the Cocotron framework’s source. (Don’t you wish you could do that with Cocoa?)

Also, I should point out that Windows users expect an installer, so you still do have to sit down on Windows and figure out how Windows installers and code signing work. Finally, don’t forget to struggle through Vista compatibility. Our app didn’t exactly work like a dream the first time we tried Vista. In fact, it didn’t even install.

Cocotron Evolution

Today we asked Cocotron co-creator Chris Lloyd about what the team has in store for us:

“Cocotron development going forward will continue to focus on the needs of developers who use the project. This will revolve around completion of the existing frameworks and the addition of more frameworks. Some of the larger pieces under active development are a complete high quality Quartz 2D (CoreGraphics) rasterizer, AppKit support on Linux via X11 and a Windows cross-debugger which works with Xcode. There has been interest and some work on CoreData so hopefully we can expand on that component too. The more people use it, report bugs and submit patches the better it will become.”

It’s amazing what this team has been able to accomplish, and it sounds like they’ll continue to crank out new goodness.

In Conclusion

Good stuff, but be prepared to roll up your sleeves and join in the fun! But as Geordi La Forge would say, you don’t have to take our word for it. Try it out yourself! Our next Cocotron adventure will be a breeze now that we’ve fought through the jungle and know just what to expect. Expect it to work, but don’t expect it to be super fun.

In the spirit of the contest, we procrastinated until late Thursday afternoon and hatched a plan in a Starbucks-fueled brainstorm. (The employees at Starbucks are thoroughly convinced that we have no job.)

We had some Core Location-related ideas, but they would have involved lots of running around Chicago with iPhones, and since Wolf had given explicit permission to deviate from the theme “if the hack was cool enough”, we decided not to go the Core Location route. Once we came up with the stupidest idea on the planet, we headed out to buy Radio Shack’s last four remaining infrared LEDs and some tiny calculator batteries.

Six hours later, we had our hack ready: Using the WiiRemote.framework and some Apple sample code, we created a Mac app which could track infrared light sources using a Bluetooth link to a Wii Remote to draw colorful lines on the Mac screen. We also added an HTTP server using Cultured Code’s Simple HTTP Server Cocoa project. We then created an iPhone application to send HTTP requests to the Mac via Wifi. These requests controlled what kind of “artwork” would be generated by the Mac application. (Line color, thickness, etc.) As a finishing touch, we taped the infrared LEDs and batteries to the front of the iPhone. This allowed for a “digital whiteboard” effect. By pressing button on the iPhone’s cool UI and waving it around in a drawing motion, we were able to paint designs in the Mac program.

Friday was something of a blur and no work happened on the hack. I think I signed up for Twitter at some point. Tweet.

Saturday afternoon, we decided that we needed a “clincher” feature. A new mode was added to the application (using a UITabBarController of course) which allowed for the positioning and stamping of image files. We also added iPhone X-axis accelerometer data to the mix to allow for rotating of the stamped images by simply twisting the iPhone.

The next 24 hours was spent trying to decide what images we would use. We finally decided on Ken and Glen heads, tinfoil hats, nose glasses and fake moustaches, inspired by Josh and Dave’s Mr. Shuffle app, and the “paranoia” theme.

After spending Sunday morning in Photoshop lassoing fake moustaches, the live demo was a complete disaster. We positioned the Wii remote too far away from the Mac for the Bluetooth link to function, and our iPhones randomly jumped from out of our ad-hoc network to the conference network midway through the demo. Much awkwardness was twittered.

In the end, we somehow managed to take first place. Thanks for your votes, and thanks to all of the companies who donated software and t-shirts!

Here’s the source (875k) for our hack including Mac and iPhone projects. You’ll need Xcode 3.1, iPhone SDK and the WiiRemote.framework if you would like to build it. You’ll also need infrared LEDs… and tape…

Known issues: HTTP did not prove to be the best way to send rapid-fire requests from the iPhone to the Mac. The iPhone’s HTTP request system seems to freeze up if we send requests too quickly. Also, the IP address of the Mac server is hardcoded into the iPhone app for extra credit laziness.

One more thing: This code was mashed together in a few hours, and just barely. It contains some nasty bits and should not be used as an example of proper or efficient Cocoa programming!

So will anyone actually try this themselves? Let us know if you do!

Actual Program Output

Use your iPhone’s camera as a wireless Mac webcam! Stream video over Wi-Fi to any Mac video application such as iChat, Photo Booth or Skype.

Some History:

After the C4 Iron Coder contest where we made the video conferencing iPhone app, we put down our iPhones and got back to writing Mac software for the rest of year. Nobody knew, and we still don’t know, what the future of these iPhone apps would and will hold.

Last week I had a strange urge to get back on the iPhone again and solve some problems that had left us stumped this summer. More specifically, I wanted to get streaming video from the camera. (If you remember our video demo at C4, the frame rate was quite low. This was because, under the strict time limit of the conferece, we weren’t able to grab from the camera any faster than a frame or two per second.)

Meet iPhoneCam:

Click to download a recording of an iChat video conference where I demo it to Glen.

I figured it out: Now we can stream at up to 30 fps. My proof-of-concept is an iPhone app which streams video over Wi-Fi to a video driver component on the Mac. This way, you can use the iPhone’s camera stream in any Mac video program like iChat, Photo Booth or Skype.

Using iChatUSBCam (so that iChat can see non-iSight video sources), I did a video conference with Glen to show him how it looks. He recorded it with Conference Recorder so that we could share it on the blog. You can download a demo video here.

But I haven’t gotten to the clever bit yet.

The Clever Bit:

The iPhone app and the Mac component find each other using Bonjour (zeroconf). There’s absolutely no configuration necessary. If there’s an iPhone-based camera available, the Mac finds it and uses it automatically. Glen had the idea to see if Bonjour could be used, and we noticed that IDMResearch had already provided a nice wrapper around CFNetService.

FAA: (Frequently Answered Answers)

A: No, it only streams video.

A: No, it’s only for Mac users.

A: iPhoneCam is not yet available to download. We’ll have something for folks to try soon. Stop by our booth at MacWorld Expo and maybe we can give you a live demo!

Amazingly, we’ve had only a few bug reports and they are very minor problems. With software, major updates are usually followed by a point release udpate in less than 48 hours. (I’m looking at you iTunes.) Not so with iGlasses 2. However, iGlasses 2.0.1 will be coming at some point to fix those minor issues.

Probably the worst bug is that iGlasses 2 causes a crash for 10.3.9 users when they run the Bruji apps (DVDPedia, BookPedia, etc.) We always feel terrible when our plugins cause pain to other developers. We do try to test every situation and we do run a beta progam but somehow we missed this one. The cause of the crash is interesting:

Watch out for duplicate class names

It’s a rare problem, but you can run into duplicate Objective-C class names when the dynamic linker is loading bundles at run-time. It turns out that iGlasses and __Pedia both used the excellent and free AppleRemote library by Martin Kahr. It’s an Obj-C class wrapper around the Apple Remote, which makes it really simple to use a remote in your app. Since neither Bruji nor iGlasses changed the name of the class, the dynamic linker gets an error when trying to load iGlasses.

Now, typically, this won’t cause a crash. The linker will print an error message and then continue, using only one of the two available classes. (This would cause immediate problems if the two classes were actually different internally.) Even though these two classes were probably identical, in this case 10.3.9 doesn’t deal with it so well. This is what we found in the system.log (absolute pathnames and other nonsense removed for readability):

Bookpedia: objc: Both Pediabase and iGlasses have implementations of class AppleRemote.
Bookpedia: objc: Using implementation from iGlasses.
Bookpedia: objc: thread is already initializing this class!
crashdump: Started writing crash report to: Bookpedia.crash.log

Yikes! The lesson? NEVER use simple class names! Always use some unique company or library prefix, even for classes you’re borrowing!

The easiest thing to do in this case is to just use a macro in your prefix file like this:

#define AppleRemote ECAppleRemote

Required:
1) A jail-broken iPhone, ideally activated.
2) A Wifi connection
3) Knowledge about how to install 3rd-party native iPhone applications.
4) A friend with (1)-(3) above.

Recommended:
5) A periscope mirror that reflects your iPhone camera image 180°.

It should also be mentioned that we cannot provide any technical help with getting this running. If you think you’ve found a bug, we’d love to hear about it.

Privacy Disclaimer:
This application uses a central server to move images between two iPhones, using your iPhone’s phone number as your unique ID. (It’s your “screen name” if you like.) Therefore, if you’re not comfortable broadcasting your phone number and your camera images through our server, this may not be the app for you. (No, we’re not going to call you, distribute your phone number, or spy on you.) Also, there’s no authentication or any way to keep anyone who knows your number from viewing your images.

Oh yeah, here’s the link: squide_app.zip (38K)

Have fun!

Update: Our demo won first place for Iron Coder Live this afternoon! Thanks for your votes everyone!

Update 2: We’ve added a link to source code at the bottom of the post. We also made a quick video demo in Starbucks today.

This was a great excuse to buy another iPhone, install the iPhone toolchain and waste some time! Before we knew it, the iCal told us it was Thursday and we were putting the finishing touches on iPhone video conferencing.

Camera? Oh really?

Obviously we had to do something with the iPhone’s camera. Doing crazy things with cameras is a full time job for us! Our contest entry captures video from the iPhone’s camera, compresses it, and sends it to a web server, where it’s relayed to another iPhone, and vice-versa, resulting in a nice two-way video conference. Need audio too? That’s not our department but simply make a phone call to the other person’s iPhone and put them on speaker phone. Then fire up our program and you’re in business. (Yes, the iPhone makes phone calls apparently.)

Wait for the Clever Bit

Now you’re probably thinking, how do you do a video conference when the iPhone’s camera is pointed in the wrong direction? The iPhone, like every other smartphone that I’ve seen, has a camera mounted on the back of the device, causing most people to dismiss the possibility of video conferencing right out of the gate.

Phuckleberry

For those of you familiar with the Ecamm product line, you may remember that we sell the Huckleberry mirror, a periscope for your MacBook or MacBook Pro. While the Huckleberry II for MacBook Pro doesn’t quite fit properly on an iPhone, that’s nothing some wire cutters and imagination couldn’t fix. Here are some pictures of our homemade iPhone-Huckleberry-stand running a two-way video conference over wifi. As you can see, the camera image is reflected off two acrylic mirrors and re-oriented in software.

(The orientation changes automatically of course.)

Darn

Ok, whoops, we meant to create something useless and fun. Surprisingly, this actually works very well, and might be considered downright useful in some scenarios. I hope that doesn’t disqualify us from the hack contest…

The iPhone Toolchain

The first step after jailbreaking our iPhones (which sounds dangerous but is actually pretty benign), was downloading and building the iPhone toolchain. The toolchain is clearly the result of hundreds of hours of work by a devoted group of iPhone dev devotees. What have they built? In a Nutshell, devs can now write native iPhone apps in the same integrated development environment we use to write Mac apps, in the same programming lanaguage, using almost the same set of APIs. It’s pretty overwhelming to think of the possibilites this opens up. It’s like a tiny little Mac/phone just like we were all promised! Thanks to the folks at iPhone Dev Wiki, and the binutils project, and these two pages for getting us up and running within hours.

Source Code

We’ve decided to post the source code for our contest entry here on the blog. Please keep in mind, this is most likely not going to be useful to you for anything other than illustrating the mechanisms that we used to accomplish our hack. The current app does not support more than two users, and will not just compile and magically work, as you will also need a server and a relay script to send the imagery between iPhones. (We used Perl for that.)

Download here: squidge_source.zip (84K)

Sample App

Next on our list, we’ll be creating an app that will actually let ambitious iPhone users try out the proof of concept. This primarily involves adding a user interface. Check back for this.

It supports drag and drop to and from the iPhone. It also supports transfer of entire folders. This makes it easy to move large directories back and forth between your Mac and your iPhone. Since the iPhone uses USB 2.0, the transfer speed is very fast. Now you can put those spare gigabytes to good use. Backup your important files! Your hard disk could fail at any moment! Do it now!

Here’s a screenshot:

Reinventing the Wheel

You can see we used an NSBrowser for the file browser. If you’ve ever tried to use one of these you’d know that they’re not very useful out of the box. Drag and drop has to be implemented manually, and the updating of cell data is very flaky, requiring many work-arounds. Also, they don’t do many of the things that you’d come to expect from the Finder’s column view mode.

All said and done, the interface came out pretty good. I just wish Apple would update NSBrowser to support more of the things found in the Finder column view. Obviously the Finder isn’t implemented using NSBrowser (it’s not even Cocoa for that matter), but it would be nice to have things like elipsification, marquee selecting, and drag and drop in there without having to reinvent the wheel.

We welcome any feedback about iPhoneDrive. Leave a comment here or use the feedback form on the main Ecamm website.

Apple has had iTunes on Windows for years, but iTunes is a Carbon app, and doesn’t contain any Cocoa, AppKit, or Objective-C. (A quick analysis with otool will show this.)
I’m not saying that getting iTunes ported to the PC was easy, but it’s not exciting because we don’t write Carbon apps anymore.

Now enter Safari for Windows… Safari is written from the ground up in Cocoa. A quick analysis of Safari will show you that it contains over 200 Obj-C classes and about 4000 Obj-C methods. Its controllers (logic) and views (the UI) are built entirely in Objective-C using AppKit.

Why is this an important fact?

I’m a huge fan of Cocoa and coding using AppKit: I find it makes coding fast and efficient. The only downside? Without a huge nasty porting effort, your code is permanently stuck on the Mac. All of your NSMutableDictionary, all of your NSWorkspace, all of your NSLock, all of your NS-anything. Today, it’s just not leaving your Mac. It’s stuck.

I’d really like to port CardRaider to Windows, but it makes such heavy use of Objective-C and AppKit, that it just seems like a nasty task.

Now enter Safari on Windows. Cursory examinations of the Safari 3 Windows binaries shows no evidence of an Objective-C runtime or any AppKit.dll. So let’s assume for a moment that they didn’t just port the Cocoa and AppKit libraries…
So did Apple really rewrite all 200 Obj-C classes in Safari in C++ or C# and change them to not use Cocoa? Are they somehow going to maintain two codebases, one written entirely in Obj-C based on AppKit, and one in another language and based some other library? Maybe they did… they seem to have done that with WebKit and WebCore….

Or, more likely, do they have some kind of secret button (some kind of tool, script, or compiler modification) that takes Safari’s 200 .m files and makes Windows code.

I’m not trying to trivialize their porting effort, because I’m sure it wasn’t an easy task. I’m just looking at the implications of maintaining two mostly identical versions of Safari 3, one written in Objective-C using Cocoa, and the other not allowed to use those things.

Did they really port this manually? I don’t think so.
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c Module
202
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c method_name
4097
otool -tV /Applications/Safari.app/Contents/MacOS/Safari | grep -c _objc_msgSend
20319

I hope for their sakes that it’s somehow automated, and if it is…

Apple: Share the technology!
Give developers the secret button to easily make their Cocoa apps into Windows apps!

Can you think of anything that could do more to encourage Mac development than allowing that code to also be useful for Windows?

But maybe they really did port it line by line, class by class.
If you look at the Windows branch of WebKit/WebCore, all the .m files have become .cpp files and the AppKit calls have become CoreFoundation calls. And it shows no sign of having been automated.
And a lot of the code has clearly been manually ported to Windows code. For example looking at a randomly selected class/routine:

The once graceful:
-[WebIconDatabase iconForURL:withSize:cache:]

has become:
HRESULT WebIconDatabase::iconForURL(BSTR url, LPSIZE size, BOOL cache, OLE_HANDLE* bitmap)


with the underlying NSWorkspace, NSImage, NSMutableDictionary, etc. calls now turned into dirty Windows CreateDIBSection code.