Amadeus Consulting Discusses Cross Platform App Development: iPhone, Android, BlackBerry and Windows Phone 7

As a mobile app development company, we help companies and entrepreneurs create a wide variety of Smartphone apps. One question we are often asked is about cross platform development, or porting an app from one platform to another platform.

The term "porting" refers to the portability of software from one platform to another, or how easy it is to adapt a program to work on a different platform. Software is considered portable when the cost of porting it to a new platform is lower than the cost of developing it from scratch. The lower the cost of porting the software in relation to its implementation costs, the more portable it is.

Apps are generally not considered to be very portable. But there are many aspects of cross platform development which can help save time and money on a multi-platform application.

Saving Money on Cross Platform Development

Unfortunately the four major platforms - iPhone™, BlackBerry®, Android™ and Windows® Phone 7 - all use unique programming languages that are largely incompatible with the other platforms. There are a few rare exceptions, but mostly, apps are not very portable.

In addition to true portability, there are many things that you can do to help reduce the cost of launching an app on a new platform.

The Three Layers of Smartphone App Development

In a basic sense, apps are built in three layers: the Data layer, the User Interface, and the "Business" layer which handles the logic and control code. Each of the major platforms manages these layers differently, which means that during cross platform development, each layer must be considered on its own terms.

1) The Data Layer

Data can either be stored natively on the device, or in a web-based external database. For example, an email application relies mainly on a web-based server to deliver and manage emails, whereas a photo editing app mostly relies on local storage (storage on the device).

The benefit to web-based storage is that it tends to be fairly well optimized for all devices and, if planned for correctly, is fairly compatible across all platforms. Of course, to really save time and money it is imperative that you plan ahead for multi-platform access, but this is the most compatible solution.

Of course there are times and situations where a web-based solution is not optimal for a particular app. This may be because of the requirement to have a reliable data connection, or the fact that a web service might simply be "too big" of a solution for a simple app, or a variety of other reasons in which local data storage might make more sense.

Using a local data layer may present additional challenges as each platform and device handles data storage and SD card access a little bit differently. But overall, the local data layer of an app is fairly consistent across each platform.

2) The User Interface Layer

Covering every other layer is the user interface. This is how the user sees and interacts with the app. Our CEO has written extensively on user interface design and development and its implications for mobile computing, which is worth reading for more information on mobile interface design. The largest issue from a development standard is that each platform (and often each device on a platform) has its own distinct user interface requirements.

In broad terms, it is easy to say that the Native UI control on an iPhone is distinctly different from the control on any Android phone. This is because the iPhone and Android are trying to be distinct from one another (just look at the number of "hardware" buttons on the Android - 8 - , versus the iPhone's 4 buttons.) This makes for obvious user interface and user experience changes when looking at cross platform development.

However, equally important, is the unique differences between devices on the same platform. The most apparent example is Android, with around 150 devices on the market and at least 60 more already announced for release this year. Even though the controls for most of these devices remains consistent, they come in all different shapes, sizes, and often with different hardware capabilities which require additional customization and adaptation to ensure an optimal experience.

So how do you quickly and economically customize an app for 150 devices? That is an answer for another blog. But the point is that there is no easy one-size-fits-all solution.

3) The Core Code and Logic Layer

The code layer is the biggest and most complicated section of most apps as it brings everything together and makes everything work. Unfortunately, this layer is unique to each platform and cannot be easily moved from one platform to another.

For example, iPhone apps are generally written in Objective-C, while Android apps are written in Java and XML. Since Android does not support Objective C and the iPhone doesn't do well with Java or XML, developers have very little code that can be directly reused.

There are a few tricks and tips that make cross platform development a bit easier which do not require third-party tools. For example, if an iPhone app is developed in ANSI C or C++ it can be easier to port to other platforms. Unfortunately most apps are not created this way (for a variety of reasons), but some apps, like larger game engines, are done this way. Game engines or other apps that are written in ANSI C++, can be covered in a thin Objective C or iOS interface layer which lets it run naturally on the iPhone.

Since Android also has a Native Development Kit (NDK) which allows deployment of ANSI C/C++ code, you can reuse much of the same code except with a thin Java layer that interfaces to C/C++. Even so, Java-to-C integration is a fragile process and may not yield optimal results, and it only adds efficiency in larger complex apps. Creating smaller or simpler apps this way might help you reuse some code, but it adds a proportionately large amount of additional code and probably will not actually help save any time.

There is another option that may soon be more viable for commercial app development: third party tools.

Third-Party Tools

Third party tools make a simple promise: code once, and deploy on multiple platforms. Though technically true, this phrase should come with a couple major asterisks and caveats.

In short, while these tools may provide some level of "code once, deploy multiple times," these tools are still in their infancy and the ability to deploy on multiple platforms is still somewhat incomplete. There are many caveats, and if you are looking for a "code once" solution, then you need to be willing to live within those caveats.

The best use for third-party tools like this is to understand their limitations. In most cases, these have the potential to help with the code layer, but will still require manual user interface customization.

One other challenge is that even though there are multiple tools; there is no single tool that can deploy on all platforms, even to a limited degree. This means that one tool can do iPhone and Windows Phone 7 deployment, whereas you would need another to do iPhone and Android. This means that even though some tools may save some time on some platforms, there is not one magic solution for everything.

In order to make 3rd party tools really work for you, you must have a solid deployment plan in place and know what you are trying to accomplish. In some cases, 3rd party tools can be immensely helpful, but they can also be a hindrance if your expectations do not meet up with their capabilities.

We highly recommend speaking with an experienced mobile app developer and creating a multi-platform deployment plan. There are many options, and an experienced developer can help you find the right plan that will produce the best results, and save you time and money in the process.