Apportable Welcomes Peter Alau to Lead Business Development

Apportable is thrilled to welcome Peter Alau, former V.P. of Business Development at Digital Extremes, to the Apportable family.  Peter is a veteran of the electronic entertainment industry and has worked for Sony Computer Entertainment America, Maxis, Electronic Arts, Linden Lab, Sony Online, and GameSpy/IGN.  

On why he chose Apportable, Peter explains, “Apportable impressed me immediately. They are filled with brilliant engineers who not only grok the problem, but have exceptionally smart ways of solving them. What’s more, they do it very quickly - a requirement in the mobile world.”

Alau comes to Apportable to help us achieve our vision of creating the premier cross-platform tool set for mobile developers. As Peter explains, “Apportable wants to be the advocate and arsenal for the developer. Developers have been saying that the swelling renaissance in game design is currently hindered by platform tool limitations, so we are trying to level the field for all platforms and give developers freedom to build excellent games and other apps without worrying about OS issues.”

Alau will be running Business Development and evangelizing Apportable’s software and services. “It’s an infectious place to be, and I’m thrilled to be part of the team,” says Peter.

How Apportable turned the Android version of Spaceward Ho! from “Never, Ever” to “You Bet!”

Written by Christopher Cotton



Just a little while ago, if you had asked whether Spaceward Ho! would ever come out for Android, we said, "Not likely at all, pretty much never". Apportable changed all that and made the impossible a real product.

Spaceward Ho! is one of the original 4x (explore, expand, exploit, and exterminate) strategy games with the first release back in 1990 on the Mac. It has gone through many iterations over the years. You might have played one of the versions in the past. It had been a very influential game in the 4x genre with many fans. The core game play starts out with you owning a single planet in a galaxy amongst other enemy players. The goal is to conquer the galaxy by building your technology and ships to exterminate everyone else.


How did this original Mac game end up on iOS and finally Android? We ( are a small team of two friends (Christopher Cotton and Steve Orens) who have been working on games and software as a hobby for over 20 years. We have professionally written native iOS apps in Objective C and Android apps in Java, and for many other mobile operating systems over the years. We first started with Spaceward Ho! when we talked with our friend Peter Commons who wrote the original. He thought the game would be great on the new PalmOS devices. We loved the Palm and decided right away to do it. After many months of hard work, we released our first version. We continued releasing new versions, and even supported the Hi-Res for Palm. Of course, Hi-Res for Palm only meant the game could finally use the original Mac graphics. Fast forward many years, the iPhone came out and then the iPad. We wanted to release Spaceward Ho! for this new and awesome platform. Since the original game engine was in C and C++ it made sense to code the game in Objective C and Cocos2d. We did the iPad release first because it would be a real challenge getting the game interface to fit on a small screen. The initial release took over a year and over a thousand hours of effort. Many fans were finally happy that Spaceward Ho! was again playable on a current device. We then focused on the iPhone version, and that release also took many more months of coding. With lots of trial and error, we were finally able to get a passable interface to a complex game.


With all the work previous versions took, it seemed a daunting and impossible task to do a Java version for Android. We had the skills and had shipped other native Android apps. But, creating the Android version would require using the NDK for the C/C++ engine and then rewriting the user interface in Java. My mind was going crazy contemplating the effort to repeat the work we had already done in Objective-C. We are a small team and managing a second platform in another language to support Android was not realistic. We did not have the time, the energy or the resources.

Enter Apportable. The idea of Apportable is you can compile your existing iOS code base to run on Android. No more maintaining two separate native apps. With their support for Cocos2d, it meant we could just add features or fix bugs in the Objective-C source and they would be available in the Android application. We were instantly sold on the concept and ready to take the plunge.

Process of Converting the Game

We worked with Apportable using their private beta version of the SDK. Since that time, their releases have improved considerably, making it even easier to use. Our source was already stored at Github and it was simple to add a new branch for Apportable. We added push hooks to auto start compiling a new build whenever the Apportable branch received a commit. Our first task was to compile the application and produce the Android APK. Apportable supported many but not all of the possible classes in Apple's SDK. Initially there were errors because classes were missing or were not being used properly. For example, one of the earlier compile time failures was Apportable had not yet added Game Center support. We added special preprocessor directive blocks around the unsupported code to allow the game to compile without Game Center.

Another error was in the specific way events were handled for UIWindow. It turns out the debug class we use for doing game screen videos was not fully supported. Instead of trying to rewrite it, we just commented the code out using special #ifdef macros for Android. We also had issues with some of our sound file names. The sound file name was called “@#$%™!” (yes, really!) but those characters were not yet supported by the Apportable build system. Apportable has a way for specific build options to be included in the Android only version. A set of build params coded in JSON gets added to the project and you can update any specific needs there.


After all these changes, the game compiled and produced an APK that ran! Holy Moley! I installed it on my Nexus 7 and it worked. IT WORKED! I could not believe it. I could start a new game and drag around the galaxy and select a planet. And then, CRASH! Even though the game crashed after every other action it was amazing to see it initially running with so little effort. Instead of 8 months or more of coding, it was just a few hours. We were more excited than ever to complete the Android version. We worked with Apportable to find and address the compiler issues in their SDK that our game exposed. Turns out some of our code was causing the compiler to spit out bad references to the instance variables of our classes. Apportable's incredible team was able to identify and fix the issues very quickly. iOS also had much more explicit and forced memory initializations. We had to guarantee that our allocations were initialized to zero before using them, since the Android version would not do that for us. For all the platform issues which blocked us, the Apportable team provided stellar support and technical insight and assistance. It allowed us continue making smooth progress.

Now we had the game running and you could play a game! Next up, the screen size. In iOS there are only a few screen sizes that need to be supported. You can easily support the few layouts with fixed code. Unfortunately, with Android there are a bazillion different screen sizes and we could no longer use the same code to support all of them. If it makes sense for your game, Apportable has an option to scale your interface as an iPhone/iPad screen. It scales the size of the game screen to match the current Android screen size.  When the aspect ratio does not match exactly, Apportable uses black letterboxing or clips the screen. We wanted Spaceward Ho! to take full advantage of the larger screen resolutions without any limitations. We turned on the native resolutions.  The Welcome screen and the New Game looked like the following screen shots.  You can see the Android version followed by the iOS version, which is what they were supposed to resemble.


We used fixed positions to draw elements on the screen in iOS. In Android, it meant that with a larger screen size, many of the controls were in weird or strange locations. Our code would contain references such as, “Draw this control at 30 pixels from the left and 50 pixels from the bottom.” Unfortunately, with Android screens coming in a variety of sizes, aspect ratios, and resolutions different from iOS, our result was horrible. In order to support the Android screens, we rewrote how dialog interface items were arranged. Instead of using a fixed size, the size was calculated knowing that all 10 lines need to be on the screen. The space was divided evenly amongst the controls. Why did we not do this initially? Good question. Our original intent was to support just the iPad and then the iPhone. We didn't have many screen sizes to work with. It was significantly easier to produce a great looking New Game screen with fixed positions than to create a general purpose layout mechanism. However, we wrote a simple layout mechanism which we used in both the iOS and Android code. It helped to make the iOS screens more uniform and they looked better. If we were starting a new game, we would definitely try to use a more general purpose positioning system to save us this particular headache.

Once we corrected the layout of our screens, next was to support the Android back button. Android users expect the back button on every phone or tablet to have an effect. Since iOS has nothing similar, we didn't have any functionality in the code. It makes sense for the back button to take you to a previous screen or to cancel a dialog. If you are building a set of ships and you want to cancel, you should be able to hit the back button. As a matter of fact, any dialog should be closed when a user presses the back button. If there were not a dialog, you would expect the back button in the main game to take you to the welcome screen. Most users would even expect to be able to quit the app from the welcome screen. This required us to add Android specific code which isn't used in the current iOS app. The Apportable SDK made it  easy to write the extra code to detect the press of the back button and then close the windows and dialogs, and even ask if the user wanted to quit the game.

Once we added in these features, it was time to release the game into the wild. The features were ready, the game was tested, and we were excited.


From start to finish, it was was less time than we had ever expected it could be. The total effort was only a few weeks. Apportable and their support was awesome! Launching the app on Google Play too very little effort as well. Coming from the iOS world, we were used to waiting for submissions to be released for 7-10 days. There was also the added hassle of being rejected and having to go through another round of waiting for 7-10 days. With Google Play, push the button and you are live! The initial sales of Android were great and we were very happy to now have Spaceward Ho! available on a new platform.


If you are considering bring your app to Android the best part will be the influx from all of the new people, blogs and review sites. Many iOS users have Android friends and the reverse is also true. Many Android purchasers have told their friends who own both devices about the game. From all the review sites now covering the Android release, we found that even our iOS sales increased. Now the Android and iOS daily sales are about the same, which means we doubled the revenue for our game.

One of the unintended benefits: celebrity endorsements! We found out via a tweet from Wil Wheaton that he loved the original game of Spaceward Ho! and found it in the Android market. How cool is it to find out one of your favorite actor/gamers loves the game you wrote? It definitely would never have happened without the Android version. We even decided to update the game to add a special Sparks McGee hat in honor of Wil's support.



With a single code base instead of separate languages, we can find and fix bugs or even add new features easily. For example, we updated the graphics in both Android and iOS without much problem. Looking back we are so glad we took the plunge. If ever given the chance to do it all over again, we would. If you were ever thinking about Android, but were worried about the time and resources. Stop worrying! Go get Apportable and be done with it. You will be happy you did.

You can get Spaceward Ho! for Google Play, Amazon, and iOS.

Apportable Raises $2.4M seed round led by Google Ventures

Today we are thrilled to announce that we’ve closed $2.4 million in seed funding from Google Ventures, Morado Ventures,, and other angel investors.

What is Apportable?

The Apportable SDK cross-compiles Objective-C applications to Android, without extensive changes to the original codebase.  Unlike other cross-platform solutions, developers can use Apportable to build for multiple platforms without leaving the comfort of Xcode and iOS.  Using the same code on both platforms means better performance and fewer bugs, allowing developers to iterate on their app faster.

So how does it work?

Instead of translating the app to Java, Apportable cross-compiles the Objective-C code to machine code that runs directly on the Android device’s processor (no VMs were harmed in the execution of our code).  A platform library bundled with the app implements popular iOS APIs, so the app thinks its running in iOS.

Does Apportable convert source code to Java? Does Apportable emit Dalvik bytecode?

Absolutely not. All source is compiled to run on bare metal.  We compile source to ARM shared libraries, which is the way iOS apps are compiled.

My application is very complicated and has intense performance requirements.  Will it work with Apportable?

Our platform has been used with some very complex code bases. If you want to see some examples of apps that are powered by Apportable, check out Biophilia, Osmos, and more.

What APIs are available when using Apportable?

We support many APIs, more than could be listed here (usually it is just best to just try running the SDK on your app), but some of the common things we support include Objective-C 2.0, C++11, libdispatch, blocks, Objective-C literal syntax, ARC, Foundation, OpenGL, UIKit, StoreKit, GameKit... the list goes on and on.

How does Apportable’s UIKit work?

The current UIKit implementation uses Android’s views to render content, however we have a hardware accelerated QuartzCore backed version coming out soon.

Can I use Java?

Yes. This is purely optional, but you can call Android APIs and use custom Java classes in your Objective-C source code if you want, using our BridgeKit API (or pure JNI).

Where can I get the SDK?; the starter SDK is a free download.