Mac Daddy World

We created FileMagnet together with our good friends at Magnetism Studios. When the App Store checks started to arrive, the confusing task of dividing up the proceeds went to Dave Keay. Sure, we could have just split the profits evenly and called it a day, but Dave endeavored to understand the ultra-confusing sales report.

If you haven’t seen an App Store sales report, then let me explain why it’s so confusing. Sales reports are divided up by currency zone. This is necessary for several reasons. Firstly, App Store products are priced differently in different currencies. For example, if you choose to price your app at $4.99 in the US, then it’s going to be priced €3.99 in the Eurozone. This isn’t an exact conversion based on exchange rate, but instead it’s rounded to the nearest “pretty price”. The second confusing thing is that while the foreign currencies amounts are reported, the actual payment to Magnetism is made in dollars, converted using whatever exchange rate the bank in question decided to use at the time the payment was made.

Dave built an elaborate Excel spreadsheet to run all of the numbers himself. When the dust settled, what he found was curious. Everything added up nicely except for the Yen column. After a few months of sales reports, he noticed that we were consistently missing 20% of our money from Japan!

It’s absolutely certain that if Dave hadn’t done all the legwork to manually verify the sales numbers, this 20% would have gone completely unnoticed. When you combine pricing differences and changing exchange rates, who’s going to miss a percentage of a percentage of a percentage?

I can haz more Yen?

Dave wrote to Apple to find out what the deal. This is what they told us:

“There is a 20% withholding tax in Japan until the Japanese tax authorities have accepted your tax exemption forms. This can take 90 days or longer. … They were required at the contract setup time in iTunes Connect. If you haven’t completed these and sent them in, you must or you should not have been paid.”

Japanese tax exemption forms? This is the first we’ve heard of those. I think Dave would have remembered filling out 12 pages of tax forms in Japanese! Clearly they weren’t required at the time we set up our account. We eventually found some fine print at the bottom of the tax forms webpage explaining the need for the forms.

“For developers residing outside of Japan who wish to sell applications in Japan, for Japanese tax treaty information, click here”.

Nothing is certain with Yen and Taxes

Our forms have long since been submitted. It says it takes about 90 days, so I’m not sure that we’re going to get the full amount yet. We should get the December payment in a few days, so we will see if we still get only 80% or the full 100%. I’m curious to see when we get the extra 20% amounts from the previous months.

Onaji Kama no Meshi o Kutta

We thought we’d blog about this because I’m sure there are other devs out there in the same situation. If you don’t remember filling out 12 pages of Japanese tax forms, you might want to go do so immediately.

Happy Tax Season from all of us at Ecamm and Magnetism!

The App store
Originally uploaded by EvilChick

As seen in the San Francisco Apple Store window display.

The Promise

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:

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:

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.

We’re just back from C4[2]. Fantastic speakers and loads of Mac nerdery made for an amazing weekend trip to Chicago. The most unexpected part of the weekend for us was winning the Sunday contest. Having won Iron Coder Live last year, we weren’t planning on entering again—that is, until we found out about the amazing prize package. If there’s anything you can never have enough of, it’s Macs… and software to load onto them. If you weren’t there to watch, the entry is a bit difficult to describe but here goes.

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

I haven’t even downloaded the SDK yet, but many of my questions can be answered from simply reading the documentation and license agreement.

1) How does File System access work?

From the FAQ:

How do I write information locally?
You can write to your application's local storage area.


From the Agreement:

An Application may write data on a device only to the Application's designated container area, except as otherwise specified by Apple.


So each application is sand-boxed. You cannot modify data from another application; for example, to edit the Notepad database, access iTunes media, etc.

2) What is Apple’s policy on using undocumented frameworks, classes or functions?

The SDK is great, but us developers have already reverse engineered the iPhone and know the iPhone OS inside and out. Can we still use routines we know about?

From the Agreement:

Applications may only use Published APIs in the manner prescribed by Apple and must not use or call any unpublished or private APIs.


You are only allowed to do what is specified in the SDK manual. Anything else is completely off limits. Imagine if they had this rule on the Mac, just how stable things would be

3) How picky will Apple be about UI design?

From the Agreement:
Applications must comply with the Human Interface Guidelines and other Documentation provided by Apple.


We are sorry to inform you that your app has been declined for inclusion in the App Store. Reason: Your app scored a 4.3 for Aesthetic Integrity. An Aesthetic Integrity score of 5 or higher is required. Please try again later.

4) What’s the problem with having to get your apps approved by Apple?

You have to play by their rules. Kind of takes some of the fun out of it.