Multi-platform Development

The current situation in the mobile ecosystem is that there is no standardized computing environment common to all mobile devices.
The runtime environments that come closest are Java ME and Browser (browser based applications). Both of these environments have their strengths, but they lack the deep integration with the phone that is necessary to implement certain features. For example, the phone simply doesn't alert the runtime when a call is incoming; only applications built for the various native OS' can respond to and act on incoming calls. The same goes for access to the native file system, advanced graphics, multimedia routines, etc.

It is therefore sometimes necessary to develop native applications across a range of different OS'. These are the most relevant:

• Symbian/S60
• Symbian/UIQ
• Windows Mobile
• iPhone OSX
• (Android)
• (LiMo)

 

The "common source" approach to multi-platform development

Faced with the task of supporting a wide range of OS' (including internal variations), it is natural to think that the ideal situation would be to find or create a software tool that could build all versions from a common source code. Maintenance and versioning would be much easier wouldn't it?

 

Such a tool does not exist anywhere, and it would in fact be counter-productive to build one for the following reasons: 

• The above OS' are wildly different, not only in the details, but in their basic and core structure. For example, Symbian uses the notion of "classes" where OSX does not. This means a completely different application structure.
• Software created from a common source would almost certainly be slow and inefficient.
• Optimization is not possible without breaking the common source principle, and you end up having to support individual OS' after all.
• Common source forces you into a lowest common denominator situation. Only features that are available in all OS' can be implemented.
• Common source projects are highly complex and have a single point of failure.

A common source strategy is likely to lead to slow and feature-poor applications, the opposite of the current trend in mobile software.

Where is the real value created?

In a highly fragmented ecosystem, it is essential to have this question in focus. The real value does not lie in the source code. Software projects do not fail because of lack of source code.

Among the most common factors that lead to software project failure:

• Inability to handle the project's complexity
• Badly defined system requirements
• Poor project management
• Unrealistic or unarticulated project goals
• Use of immature technology
• Stakeholder politics

The "common source" approach has to be turned on its head. The main cost of developing and maintaining software is not the actual programming, and the most valuable part of a software project is not the source code. When you build a house, the most valuable parts are the planning and details that goes into the architectural drawings (before building), and the utility of the house (after building).

 

In a highly fragmented environment coding must be done towards a common spec, not a common source.

Like a detailed architectural drawing, a common spec must be highly detailed and include the exact visual representation, the interaction design, the complete technical architecture down to the individual method and class names and their documentation.

These are the main advantages:

• Risk is lower. Smaller projects have higher success rate in general.
• Development time is reduced. Coding to an exact spec is a lot more effective.
• Documentation is written before coding and this allows test-driven development practice.
• No single point of failure.
• Each platform can be optimized for speed and responsiveness.
• New platforms can be added without dependencies.

This approach benefits greatly from coordination of the development in order to ensure re-use across platforms where possible (for example Symbian/S60 and Symbian/UIQ have parts in common).

Flying cars

There is a balance here. To stretch an analogy: evolving a car so it can run in all kinds of weather, in different speeds and on different kinds of roads makes for a better car. But try to make the car fly in the air and go on water as well, and you end up with a worse car. I believe tools that deals with internal differences, between versions of an OS can be a good thing. But beyond that, you are better off with a common spec approach to development.

[Update] Simon Judge does not quite agree and has some great points in his response to this post.

Comments

[Dmitry]

Dmitry said...

It depends on a project. One project can have such a specifics that it has no common algorithm for all platforms but just common functional requirements, but some projects have such a specifics that a part of common source is inevitable (common algorithms etc.)

[Michael O'Boyle]

Michael O'Boyle said...

Thank you for this concise and persuasive post. I'd be very interested in reading a specific case study on this approach to mobile app development if you know of one. You've got me wondering now about the market share of each of the platforms as well.

[Tote]

Tote said...

Very good article, thanks for posting! I fully agree with your analysis. Please note, however, that programming for multiple platforms without a common codebase requires either highly-skilled programmers with experience on multiple platforms or very good communication between multiple programmers doing the same thing but for different platforms.