1. beta
Intel® Atom™ Developer Program
Part of the Intel® Software Network
Originally published as a blog by Bob Duffy at :
http://appdeveloper.intel.com/en-us/blog/2010/04/26/tale-two-ports-picard-vs-kirk-review-mobile-app-porting-techniques
A Tale of Two Ports:
A Picard vs Kirk review of
mobile app porting techniques
“What will my application be like on the netbook?”
I had the pleasure last month to collaborate with two accomplished developers on their
methods for porting iPhone* games to AppUpSM for netbooks running Windows*. I was
very impressed by the creativity and ingenuity of these ports while at the same time it
appears they follow some common practices to ensure a quality experience on a
netbook. While very different these porting methods are both viable and I believe
represent the most likely scenarios for porting a mobile app to AppUpSM.
Mike Kasprzak from Sykhronics took what I would consider a more conventional port of
his game “Smiles” with a basic rewriting while leveraging standards and his own custom
libraries & assets. Read our Q&A with Mike for details on his port.
The other approach is explained by Chris Skaggs of Soma Games, which is a more rapid
porting approach of his game “G:Into the Rain.” Soma Games exported their code to a
cross-platform framework and C++ wrapper. Read our Q&A with Chris for details on
his port.
It struck me that these two approaches were very different yet both effective. One
bold and one deliberate, yet both finding a common formula for success. And because
everything can be explained through Star Trek characters, I see one one as Kirk and one
as Picard.
An app prepared for porting libraries and assets that he could leverage
in the port. Thus he was not burdened
The Smiles port is very interesting
by having to determine how to rewrite
because it lays out what I think is a key
or find a comparable solution to Apple*-
challenge and opportunity for app
specific libraries.
developers. Mike’s approach was to
rewrite his iPhone* app in C++ using Visual This situation is a likely scenario for game
Studio. Although that may sound painful, porting. Games have custom UI’s, custom
Mike:
Mike had written most of his code in C++ menus, and buttons, whereas productivity
I structure my project manually so I can
to start with, and he had the foresight to or information apps will more often rely
mix and match Xcode* projects, Visual
Studio* projects, and makefiles together establish his own core set of custom on platform specific libraries for menus,
in one common layout. It takes some libraries and assets to create his unique lists, buttons, and navigation. For games,
planning and homework to do this right, game experience. Also, Mike developed his this is either a curse or blessing
but it’s far better than copying files around game using a cross-platform open depending on how you look at it. In Mike’s
manually. My makefile setup is custom, and graphics API (OpenGL), allowing much of case, his choices led to an easier
automatically detects all files in my project. his work to be reusable in either platform. porting path, but in the end it required
But for both Xcode and Visual Studio, I more custom work up front. This is
manually build a project by dragging all my Mike’s relative ease in porting was mostly
something to consider if you hope to get
source files in (directories at a time). due to preparation and work he did
that application to multiple devices and
up-front to build and use cross-platform
platforms. Consider what your path might
language, APIs, and his own custom

2. White Paper Title Placeholder Here
beta
Intel® Atom™ Developer Program
Part of the Intel® Software Network
be away from platform-specific libraries hardware differences. Neither app could
or doing some up front work to build your work as a straight port. Both developers
own, as Mike did. If you haven’t already opted to make adjustments in their
figured it out, I’m comparing to Jean-Luc original apps to make their game
Picard and how he prepares for a mission. experience best suited to a netbook.
His success was due to early and
Mike’s approach took a similar path to
deliberate planning, making each next
his overall porting approach. The answer
step easier because of each informed
was in his original work. Even though the
decision and action.
iPhone screen is much smaller than an
Or just change the rules netbook, Mike chose to create his artwork
Chris had a unique situation. He did not much larger than the iPhone required.
have time to do a conventional port and His thinking was that he could easily cut
recode the whole application. He also was his images in half, but scaling up images
not in the situation Mike had set up, which would cause them to be fuzzy and lose
made porting relatively simple. So Chris the sharp crisp look he created for his
took the Captain Kirk approach. He didn’t game. Thus, not knowing what hardware
cheat, he just changed the rules. Out of his game may end up on, he decided to
time to recode, Chris found he could scale his graphics 4 times larger than the
export Objective-C to Adobe Flex iPhone. Again, Mike future-proofed and
relatively easily and it retained all of his platform-proofed his app from the get-go.
library calls. So rewriting wasn’t
Chris, on the other hand adjusted his
necessary. Once Chris was able to create
artwork and created new graphics for the
an SWF from Flex, he had a file that would
netbook. This also provided an
run on Windows* or any other platform
opportunity to do something’s he felt
with Adobe Flash Player*.
restricted with on the iPhone. In a way the
However, this left Chris another problem Netbook was a new canvas to work from
to solve. AppUp™ Center, the store he was and Soma Games found simple ways to
targeting, only allowed for C or C++ code improve on things for the Netbook.
to be submitted through its SDK. Again
The other common issue was what to do
Chris just changed the rules. By having
without an accelerometer. It’s one thing
a working app for a netbook but not the
to scale graphics but how do you deal
right code for submission and validation
with a feature that is not supported at
into the store, Chris simply deployed a C++
all? Mike and Chris seemed to have similar
wrapper around his Flex application.
Chris: ...we found that Objective-C was very approaches here. They both looked at the
easy to port to a Flex application. Once we I assume a similar method could work for strengths of the Netbook and determined
had a .SWF file it was a fairly simple matter Silverlight or some other comparable how they could integrate those strengths
to create a C++ wrapper that provided solution, as long as the tools are available. to accommodate some of their
the authentication layer for the AppUpSM
Thus, if time is a gating factor either in accelerometer features. The keyboard
Center.
getting your app ported or time it would on netbooks proved to be an interesting
take to recode end-to-end, you could look solution for both of them and they found
If we’d had more time we might have built
at what tools are available to they were able to code in features beyond
the game from the ground up in C++ for
automatically port your app to another what they even intended in the original
performance reasons but in hindsight the
typical netbook has plenty of horsepower application framework. versions.
to run our Flash game with room to spare No getting around the hardware And this is where Mike figured he needed
so it hasn’t been an issue regardless. As different as these approaches are— to do more work. Even though he set his
Mike’s pre-planning, use of standards, and screen images to scale well for a netbook,
custom libraries versus Chris exporting to things like rotating the screen vs rotating
Flex with a C++ wrapper—both ports did the game board were different between
have similar challenges that were solved the devices. On the netbook, he needed
in similar ways. Both had to deal with the to rotate the game space to maintain
2 2

3. White Paper Title Placeholder Here
beta
Intel® Atom™ Developer Program
Part of the Intel® Software Network
the game play, but he would not need to 3. If time and cost of recoding is an issue,
rotate the text or buttons since a netbook is there a quick path to porting that will
would remain in one position. So he retain a quality experience?
adjusted the ratio of his game space to be
a. Is there a quick conversion or
square rather than a rectangle, thus
emulation path to cross platform
working better for his netbook game
frameworks like Adobe Flex,
design.
Silverlight, or Java?
A common approach in the end
b. Is there a wrapper approach you can
In summary, although Mike’s and Chris’s
exploit?
initial styles of porting are very different
(one Picard, one Kirk) I find their overall In the end, the two ports are good
approach to porting an app is pretty examples of common approaches. Like
similar. They both looked at how they these famous fictional captains, it’s hard
could most effectively make use of their to pick a favorite. You have to admire
existing work while also determining how the ingenuity, creativity, and Kirk-like
they could tweak and even improve their approach from Soma Games to get their
app for a quality netbook experience. In app ported under time constraints. I see
the end, they both had to go a bit deeper Chris’s approach as a common method
and adjust the apps to exploit the for developers, and I can say I’m seeing
features of the device. more of this type of solution in our forum
(And I’ll spare the sappy comparison of discussions. At the same time, Mike’s
Picard and Kirk having different styles Picard-style approach is a great example
yet both weighing each alien encounter of being a “next generation” developer
by special circumstances thus eventually to code using cross-platform standards
and continually circumventing Starfleet’s with an eye toward deploying on multiple
Prime Directive). devices.
Summary of best practices The world of computing devices is ever
growing these days. In the end, both
1. Plan your original app beyond one
examples show that straight porting is not
platform
a good option. A good port will require you
a. Leverage cross-platform dev to open your code and graphics to exploit
standards like OpenGL and C++ the features of the the hardware.
b. Define your own libraries and assets, At the time of this post Star Trek, and it’s
especially if you think this app will characters James Kirk & Jean-Luc Picard are
have life beyond its first version and the property of CBS Studios.
first platform
2. Optimize your app per platform
a. Leverage hardware strengths of
each device when converting
between disparate hardware options
b. Scale and optimize graphics for each
device
1. When possible, design your original
art to scale
2. Find ways to improve features and
the experience as you scale
3