Mobile Platform Strategy

Written by Mitch Denny

What platforms should I back and why?

Mobile Platform Strategy in Brief

According to the Australian Retailers Association (ARA), Smartphones now account for 63 per cent of the mobile handset market and 68 per cent of Australians plan to use mobile devices for transactions and payments in the near future[i]. It is therefore critical that organisations engaging in online commerce have a mobile platform strategy to satisfy their users.

The purpose of this document is to highlight key considerations when forming your mobile platform strategy and provides a high level recommendation. Should you require specific advice we recommend engaging Readify to provide specific guidance suitable to your situation.

Key Considerations

Rich vs. Reach

The argument about providing rich user experiences vs. reaching a maximum audience is alive and well in the mobile platform space. Each major smartphone vendor has a proprietary platform which allows developers to provide the richest possible experience for end users. Richness of experience can come from direct integration with platform services such as identity, in-app purchase frameworks, data synchronisation and offline support. But what do we mean by native/rich or reach?

• Rich/native; is when a publisher develops an application using the tools provided by the mobile platform vendor, and the output will only run on their platform. For example iOS application publishers must use Objective-C and Xcode and the output will only run on iPhone, iPod Touch and iPad devices.
• Reach; is when a publisher develops a web-site that is specifically designed to work with web-browsers built into smartphones such as iPhone, Android, or Windows Phone 7 devices. Because the UI of these sites are usually expressed in standard HTML 5, often a single development effort can reach a larger number of device types.

Providing a rich experience via a native application will almost always be better for the customer because ultimately the user interface will be more responsive and support more scenarios, but it places an increased burden on the organisation publishing the application. Specifically, when pursuing a native implementation strategy the following must be considered.

• Multiple platforms to support; two years ago pursuing an iPhone only mobile platform strategy would have made sense. But the mobile handset market is highly volatile with handset refreshes being tied typically to two year contracts. This helps account for the rapid increase in popularity of the Android platform. At minimum publishers now need to support two native mobile platforms.
• Multiple platform versions to support; not all users of mobile devices keep them updated with the latest software patches, this leads to a complicated testing regime. In some cases there are deliberate breaking API changes which lead to the publisher needing to maintain two separate code bases.
• Application serviceability; most mobile platforms have a defined publishing process which can take anywhere from a few days to weeks for updates to applications to be deployed. Even once approved and published some users will never update their applications.
• Backend service versioning; because it is certain that there will be multiple versions of the application deployed, backend systems which mobile applications talk to need to be carefully designed so as not to break functionality on legacy versions of the mobile application.
• Impact of policy changes; native application publishers are at the mercy of policy changes instituted by mobile platform vendors. Policy changes can take your application offline and cut off your channel to market.

These are some of the key considerations around choosing between a rich user experience based on specific technology from a mobile platform vendor, or a reach based approach which targets HTML5.

Driving Adoption

Regardless of whether you adopt a rich or reach based model it is important to consider how you will get your application into the hands of users. It is important for publisher web-sites to be somewhat mobile aware so that if they detect a mobile browser they can either promote their native application or suggest redirection to a mobile friendly web-site that provides application like functionality.

Organisations have both a rich and reach strategy often use the mobile web-site to "upsell" to the native client.

Mobile web-sites often have the opposite problem in that their users are looking for a native application without searching in the web first.

In these circumstances organisations that have pursued a reach only strategy are disadvantaged. One tactic that can be used to mitigate this, is to build a shell of a native application that can be published in the relevant marketplaces and application stores with just enough native functionality to pass policy checks, but wherever possible link back to the native site to reduce the need to maintain multiple platforms. This tactic provides the benefits of marketplace listings frequently used by users and as much reduction of duplication of effort as possible. This could be referred to as a hybrid model.

Beware Marketplace Policies

Policy changes were previously as one of the reasons for avoiding building native applications. One such example was a policy introduced by Apple for iOS devices where all payments for digital content must use their in-app payments system where Apple takes a 30% commission. This created a problem for established content publishers like magazines and newspapers as well as eBook vendors such as Amazon where they already had established margins which couldn't absorb an additional 30% cost.

Rather than increasing their prices by 30% and therefore becoming uncompetitive with Apples own iBooks/Newsstand features, they opted to withdraw payments functionality altogether from their applications. Some even removed their applications entirely from the AppStore.

If you are building an application that accepts payments and you don't pay a 30% commission to the mobile platform vendor then you may want to consider a reach only model or a hybrid model where payments cannot be initiated via the application.

Some vendors such as Microsoft haven't specifically published policies around in-app purchases. This introduces a level of uncertainty. Currently in-app purchase policies for WP7 are not available because there is no in-app purchase mechanism built into the platform. However, Microsoft recently announced details of the Windows Store which will be part of Windows 8.

As part of the Windows Store policies Microsoft has announced a similar 30% commission structure, dropping to 20% after total revenue from the application has reached $25,000.00 USD. However, this commission is only applicable when you use their payment infrastructure. Windows 8 Metro applications are still free to use their own payment gateway relationships and avoid the 30% commission structure. Note that these policies can and will change over time.

We hope that all mobile platform vendors will move to a more sensible commission structure more in line with other payment providers used by existing e-Commerce sites.

Special Cases

From time to time there may be times when a reach only strategy should become a reach first strategy.

Platform Launch Marketing

From time to time mobile platform vendors will look for launch partners to be among the first to build platform specific applications. In these circumstances investment should be evaluated just like any other marketing campaign. Will the co-branding benefits from the various launch events and promotional materials help build awareness of your application the organisation it represents? In many cases the mobile platform vendors have investment funding available to try and offset some of the initial development costs.

Investment in a reach first strategy will definitely accelerate implementation of these launch-focused native applications because it is possible to develop features that show off the mobile platform and then fall back to a hybrid embedded browser model for base functionality.

Future Considerations

The mobile application platform landscape is very dynamic and in some ways unpredictable. But there are some forces at work that application publishers need to be aware of.

Windows 8 and Metro Application Implications

With Windows 8, Microsoft is introducing a new application model specifically optimised for Tablet computers with a more mobile form factor. This will allow Windows to compete with devices such as iOS tablets (iPAD) and Android tablets which is an important sub-segment of the mobile market.

Perhaps more important is the specifics of the new Metro application model. One of the valid combination of languages/runtimes for Windows 8 will be HTML+JS (JavaScript) applications, delivered through the Windows Store. With this combination it may be possible to share some assets (such as JavaScript modules and HTML/CSS design elements) with both the mobile site, and a native Windows 8 application.

The increased developer productivity of using HTML+JS may also inspire other mobile platform vendors such as Apple and Android to adopt a similar application model which further increases the benefits of a mobile web-site (reach) investment. The size of the Windows PC market is significant so it is important not to underestimate the impact this change will have on the mobile eco system, especially if Microsoft takes their own lead and builds a similar application model on Windows Phone 7.

Death of Flash Mobile

Adobe has long advocated the use of Flash for mobile sites but has failed to get any traction on significantly adopted platforms. iOS devices could not use Flash, either as a complete application model, nor embedded in a web-page. Whilst Flash was supported on Android it was somewhat buggy and the Blackberry Playbook use of Flash didn't significantly increase market share of Flash in the mobile sector.

This combined with the increased capabilities of HTML5 and associated technologies led Adobe, predominantly a tool vendor to kill off mobile flash[ii]. Their focus will instead be on HTML5 tooling. Adobe has a significant designer community and mobile applications should be designed to be functional, but also engaging.

If Adobe can successfully enable designers to build high quality HTML5 applications then that might further put pressure on the mobile platform vendors to adopt it as a first class application model that can be deployed through their respective marketplaces.

Gaming and Advanced Visualisation

Rendering speeds for mobile web-sites are still at a level which prohibits them for casual to serious gaming and advanced visualisation (particularly with high refresh rates). Even though desktop web-browsers have now reached a point where they can easily render high quality 3D graphics, these capabilities have not reached their mobile browser counterparts. For this reason, if these capabilities are required it may be necessary to build native applications. On Windows Phone 7 there is also a different application framework called XNA that is used for games because even Silverlight is not sufficient for many games.

Industry Specific Applications

In some cases the consumer mobile platforms are not appropriate for certain industry types. A good example is the transport and logistics sector. Currently there are very few good options for building applications in this area. Many existing applications are built on legacy Pocket PC/Windows Mobile architectures which have poor tooling support in the current generation of Microsoft's products. Customers who are looking for alternatives may need to consider vendor specific offerings from Motorola who is building a ruggedized Android-based device. Note however that the problems with these specific devices is that you need relationships in-place to ensure that these relatively expensive devices receive OS upgrades for the underlying platform.

For organisations with significant investments in Microsoft technology, it may be worth investigating small handheld PCs running full copies of Windows until Microsoft puts some focus on supporting existing customers with Windows Mobile investments.

Recommended Strategy

Readify recommends adopting a reach first strategy where a mobile web-site is first created to maximise the number of smartphone users who can access your application functionality. Once the core features of your application are in place we recommend the construction of native shell applications with minimum functionality required to pass marketplace verification. This will create a valuable promotional channel for your mobile experience.

Finally, once your shell applications are established, you can decide whether more investment in core features of the platform are desirable, or whether increasing the level of richness in native applications will yield better customer engagement results.

It is our belief that this strategy will provide better returns on your mobile platform investment over the long run and maximise the number of customers that can be reached. The features provided by native applications are still important, but not at the expense of maximising reach in a highly volatile handset market where leading positions are changed on an annual basis. 

Read our case study on Australia Post: Windows Phone 7 Application.

---

[i] http://www.retail.org.au/index.php/news/Smartphone_growth_fuels_mCommerce_adoption_-_Australian_retail_goes_mobile

[ii] http://www.guardian.co.uk/technology/2011/nov/09/adobe-flash-mobile-dead