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!

As seen in the San Francisco Apple Store window display.

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

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.

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!

We’re doing a really fun promotion all week: Stop by at any time during the expo and instantly win cool prizes. Prizes include iPod Shuffles and completely free copies of our (not usually free) software. So come and win a copy of DockStar, iGlasses, iPhoneDrive, CardRaider, or if you’re lucky, an iPod!

We’ll also be demoing our software, showing off our iMage cameras, giving a sneak peak at the very new, improved and the never-before seen Huckleberry 3.

We’ll also have various iPhones and iTouches available, showing off some cool new iPhone hacks we’re working on, and for anyone who wants to see a demo of our other iPhone projects.

This Mac app will work on any iPhone or iTouch (no hacking required).

Instructions:

1. Have a Mac.
2. Download: Caption Crunch.
3. Run the app.
4. Connect your iPhone or iTouch.
5. Enter a message.
6. Click “Set Message”.
7. Your iPhone will say “Restore in Progress” and may or may not reboot. Wait for it.

If it doesn’t work, just try again. You can always go back to showing the time using the other button.

Download: v1.0: Caption Crunch (340K).

Update: In response to a user request, we’ve built an alternate version that changes the carrier string (e.g. AT&T) instead of the time. Here’s the link: CaptionCrunchCarrierString.zip (344K).

DISCLAIMER: This is just for fun and completely at your own risk. It’s unlikely to cause any problems, but if it does, we won’t be able to help.

But so-called “native” applications are not for mainstream consumers. “There’s no easy way to get applications on the iPhone,” Aspeslagh said. “You have to make changes to your iPhone, and that really freaks people out. It’s a procedure that could turn your iPhone into a paperweight, if it’s not done correctly.”

Fun stuff. Let’s just hope it all has a happy ending.

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!