The Google/Motorola deal suddenly makes it relevant to take a closer look at the other OS platforms on the market. Most industry observers in the mobile space have already written off HP/Palm’s webOS as a dead platform. From a smartphone perspective, this is obvious at first sight. With two [...]]]>

webOS from HP/Palm on different screens

The Google/Motorola deal suddenly makes it relevant to take a closer look at the other OS platforms on the market. Most industry observers in the mobile space have already written off HP/Palm’s webOS as a dead platform. From a smartphone perspective, this is obvious at first sight. With two percent of smartphone users in their only market (US), negligible global sales, and a thin app store, they don’t have much going for them. HP recently released a tablet powered by webOS but according to the reviewers the product is clumsy and behind the competition. There is talk about Samsung licensing webOS for a few handsets but no products have hit the shelves yet.

HP/webOS can not currently compete head to head with Apple and Android, even though the webOS technical platform is excellent. The platform is designed for true multitasking and for running web apps based on HTML5/JavaScript/CCS with hardware accelerated execution.

But there are a couple of scenarios where webOS can be viable. For example, if HTML5 becomes dominant and native apps fade into oblivion. In that case, the advantage of the market leaders’ huge app stores will become irrelevant and webOS will be able to compete on a level playing field. As webOS is optimized for HTML5 from the beginning, there is a good chance that apps will work better than on the competing platforms. If other OEMs become wary of using Android after Google’s Motorola purchase, webOS might be more attractive for licensing. An additional factor that could reinforce this scenario is the rise of cloud computing. If all this plays out, handset OEMs and mobile operators might consider webOS as a way of reducing the market power of Android, Microsoft, and Apple. But even if native apps are sidelined by HTML5, the smartphone market leaders will still have a huge advantage due to their brand, size, and market share.

However, if the game plan changes, webOS could reappear as a serious contender. If and when the cloud becomes the dominant computing paradigm, webOS will be a good fit for a range of devices. The drawback is that the mobile connection to the smartphone will always be unreliable and rather slow. If all your documents, contacts, messaging and apps are stored in the cloud this will be a problem. Enter the PC (and to some extent the tablet). For the PC one usually has a reliable broadband connection. That is where cloud computing (and hence webOS) would work best. And this is the direction HP is moving in with webOS. HP will install webOS on all their products (PCs, tablets, printers etc.) from 2012.

Industry observers predict that HP wants webOS so it can provide users with “experience roaming” across all devices, where webOS will ensure that users can keep their profile and contacts. The Synergy feature in webOS aggregates all the user’s contacts and supports that strategy. Enyo is webOS’s development framework and supports handling different screen sizes in a seamless way. This is probably part of HP’s plan.

But HP’s bolder move is to install webOS together with the upcoming Windows 8 on the traditional PC. I don’t know if this was part of HP’s original strategy when they bought Palm in April 2010 or added by the new CEO Léo Apotheker who joined HP in September 2010. If webOS boots faster than Windows 8, if HP gives the user a choice between webOS and Windows during boot, and if the user primarily uses the PC to access HTML5 web apps in the cloud – then perhaps users will choose to boot webOS instead of Windows and gradually stop using the legacy Windows platform. This would give HP huge leverage in future price negotiations with Microsoft. WebOS will be HP’s Trojan horse for breaking into Microsoft’s territory on the PC.

Windows 8 is a radical departure from the traditional desktop keyboard and mouse paradigm. Windows 8 comes with full touch screen support and their UI theme (“Metro”) has a look and feel with tiles that plagiarizes WP7 and most of the smartphone/tablets platforms. The traditional legacy desktop environment is hidden inside tiles. Windows 8 is built for app development in – surprise surprise – HTML5. The same as webOS. If we disregard the support for legacy desktop apps, Windows 8 and webOS will almost be head to head competitors. And while webOS is optimized for web apps, Windows 8 has to carry a huge legacy baggage to keep backward compatibility.

Will one of the most insignificant smartphone platforms rise from the ashes and conquer the giant of the PC era? Don’t rule it out just yet.

This article has previously been published on VisionMobile’s blog.

  The Android vs. iOS vs. Windows Phone platform battle has been the talk of the industry for the last year. But the market share battle between handset platforms might not be as critical for the industry as many believe.

A popular view in the industry [...]]]>

This article has previously been published on VisionMobile’s blog.

 
The Android vs. iOS vs. Windows Phone platform battle has been the talk of the industry for the last year. But the market share battle between handset platforms might not be as critical for the industry as many believe.

A popular view in the industry is that the market is inevitably moving towards an Apple-Google duopoly. Apple’s app store has more than 400,000 apps. Android is growing quickly from a base of more than 250,000 apps and is predicted to catch up with Apple later this year. Nearly 80 percent of all apps in app stores are controlled by these two market giants according to Distimo. Figures for Q1 2011 from Gartner show that the market share in the smartphone market for iOS and Android combined is 53 percent and rising.

But the duopoly may be challenged by the mobile web and cross-platform tools. HTML5 empowers all other platforms to offer apps through the browser. VisionMobile’s recent Developer Economics report shows that the mobile web (of which HTML5 is a subset) is already the third most popular platform in terms of developer mindshare after Android and iOS.

At the same time, HTML5 is overhyped and the belief that HTML5 will replace almost all native apps is in need of a reality check. Native apps will still offer richer functionality, better performance, and higher security compared to HTML5-based apps. A study by quirksmode.org has shown that every mobile WebKit implementation is slightly different, which could cause a problem for HTML5-based apps. In a recent whitepaper, Netbiscuits measured smartphone support for 18 features in HTML5 and showed that leading smartphones only offer partial (or no) support for a significant number of these features. Implementation is also fragmented. What works on iPhone will probably not work on RIM or Samsung handsets and vice versa. Or to quote Forrester’s take on the HTML5 vs. native debate: “The ‘Apps vs. Internet’ Debate Will Continue…to be irrelevant.”, “it’s not a question of ‘either/or’ when it comes to a choice between apps vs. the mobile Web, but both.”

The Landscape Of Cross-Platform Development Tools

The new types of cross-platform tools are more interesting than plain HTML5 because they can deliver higher performance and functionality than browser based HTML5. These tools produce apps as output and fall roughly into two categories:

1) Web apps/hybrid apps. These apps exploit the web engine (“web browser”) and are typically written in HTML/CSS/JavaScript.

2) Native apps. These apps are compiled into machine code and often written in C++ or similar languages.

Cross-platform tools are a nascent market with a flurry of startup activity over the last few years. The following diagram illustrates different trade-offs between complexity and performance in the cross-platform tools market.

Market segments for mobile cross-platform tools

Traditional websites: In the lower left corner is the traditional website, limited in performance but providing access to all platforms with no added complexity. Plain HTML5 could be included here once all browsers support the standard.

Web apps/hybrid apps: Adjacent in the diagram are HTML5 web apps that can be downloaded to the browser’s cache and run offline. They will offer better performance and only slightly higher complexity. One step up in the diagram is a market segment of cross-platform tools running simulated native. These tools deliver better performance but the complexity is also higher if the tool has to support multiple platforms. Here we find tools that produce web apps built on HTML5/CCS3 and JavaScript, with some added native elements, typically inside a native wrapper. These cross-platform tools often add native extensions that provide access to some low level native functionality. An example of a player in this market segment is PhoneGap, which is often used in tandem with the Sencha Touch framework. Other tools that run on top of PhoneGap are WorkLight and appMobi.

A closely related market segment is hybrid tools, where the HTML5/JavaScript input is translated into actual native source code. An example of a hybrid tool vendor is Appcelerator’s Titanium.

Other types of solutions which fall under the main heading of web/hybrid apps are based on Java, Lua, ActionScript or less common languages. The diagram shows how the heavily-fragmented Java ME offers inferior performance in spite of high complexity. The cross-platform tools Corona SDK and DragonRAD are based on Lua. Rhodes is based on HTML/Ruby while OpenPlug uses ActionScript (Flash) as source language. Kony uses drag-n-drop for building enterprise web apps. There is no reliable information about the performance/complexity trade-off for most of these solutions, so their exact position in the diagram above should be viewed as illustrative. In general, tools in which the resulting code is compiled or recompiled to native ARM machine code will have a higher performance.

Native apps: The second main category is native apps. In cross-platform tools for native apps, developers often work with a codebase in C/C++ or C# which is then semi-automatically ported to the target platform and device. Performance is significantly higher with native code, but so is the complexity. Players in this sector include Airplay, Qt and MoSync. The Airplay SDK (now Marmalade) originates in 3D gaming but can also be used as a general C++ cross-platform tool. Qt is a cross-platform UI framework that also can be used for native C++ porting. Qt primarily supports Nokia’s legacy platforms. MoSync is a cross-platform tool for general purpose C++ development, integrated with the Eclipse IDE and also available under an open source (GPL) license.

Cross-Platform Beyond Java – Native Extensions

The traditional approach to cross-platform development has been a lowest common denominator one – much like that taken by Java, Flash Lite and mobile HTML. This approach sacrifices performance, UI pizzazz and access to specific device features.

A workaround is to add native extensions. These can provide additional SDK/NDK libraries for the IDE and also give access to low level hardware functionality. Access to low-level hardware functionality can be managed by a device database that controls which conditional code will be executed on a given device.

Several of the cross-platform vendors have built such device databases with various levels of detail. A device database contains information on screen size, input modality and exact OS version, extending to detailed hardware configurations and known bugs with workarounds.

Using native extensions, it is possible to overcome the inherent limitations that plagued Java. Instead of “write once, run everywhere”, developers can spend 90 percent of their time developing a common codebase and 10 percent adding native tweaks and extensions for each platform and device. For software purists, the 90/10 solution might not seem very elegant, but it is a way forward that can handle the incredible complexity with thousands of devices running more than five OS platforms. In this way, app developers can manage one codebase and port it to target devices without losing functionality. In principle, using a (C++) cross-platform engine with extensions should be able to offer similar functionality with minimal performance penalty as compared to direct development for the target device. There will be significant economies of scale when the common codebase is tweaked for 100s of devices.

The Disruptive Potential Of Cross-Platform

There are few signs that platform fragmentation will disappear. It’s not just Android, iOS and Windows Phone 7, which are backed by corporate giants with deep pockets, but also smaller players like QNX (RIM), WebOS (HP), MeeGo (Intel, China Mobile) and Bada (Samsung). Add to that legacy platforms, which will be around for at least a few years: Windows Mobile, Blackberry OS, Symbian, BREW, Java ME and Flash. If we also include the main desktop platforms (Windows, Mac OS, Ubuntu), gaming consoles, set-top boxes, cars, and other gadgets, the number of platforms becomes unmanageable.

App developers whose clients need to reach the entire market, face the formidable task of supporting all platforms and devices. If they can use a cross-platform engine the productivity gains will be dramatic compared to paying for separate in-house dev teams for each platform.

Early adopters of cross-platform will most likely be large consumer businesses who need to target the mass market such as media companies, games houses, entertainment companies, banks, and any brand developing B2C apps. Similarly, government agencies are often required to provide non-discriminatory access to their services and cross-platform tools will enable them to do just that. Another group of early adopters of cross-platform tools is CIOs of larger corporations. They face increasing demand from senior staff who want to use their favorite smartphone for secure access of internal company data. Once these early adopters have driven down the prices and sorted out stability issues we should expect to see a fast uptake of cross-platform tools in the mainstream app development market.

Assuming more developers move to cross-platform tools, the power distribution in the mobile sector will be challenged. The difference in the number of available apps between dominant and up-n-coming platforms will be reduced. This will allow smaller platforms to compete on a level playing field.

Web apps and HTML5 should make the largest dent in the market power of traditional platforms. But the final nail in the coffin will come when C++ cross-platform engines can offer almost the same performance and functionality as coding directly on the target platform. This is possible if the cross-platform engines can fully integrate native platform and device extensions. In that case, developers of native apps might reconsider Android, iOS and WP7 and choose to code to a cross-platform IDE, not to the platform. In this scenario, the cross-platform IDEs would become players of equal or even greater importance than the native platforms. At the very least, today’s OS platform wars will move to a totally different level.

Comments can be left at VisionMobile’s blog.

Corporate users can pretend that the service is free but their employers certainly notice if the mobile Net bill is larger than the hotel bill. In the [...]]]> One of the major hurdles for further growth of mobile data services, and LBS in particular, is the exorbitant data traffic fees customers incur when using their phones abroad.

Corporate users can pretend that the service is free but their employers certainly notice if the mobile Net bill is larger than the hotel bill. In the private market segment, price sensitivity is much higher. Prices have to come down for this market to reach its potential.

As long as the price elasticity of demand is larger than one, lower traffic fees will lead to such high growth in traffic volume that the total revenue increases, despite the lower prices. The entire industry would benefit from an agreement to remove most of the roaming charges, but that is not even on the horizon.

A single operator could see the benefits of offering affordable data traffic abroad for its own customers. But as long as other operators don’t reciprocate, the industry will be stuck in a sub-optimal stalemate.

The problem is that the same operator who wants to offer an affordable rate to its own customers has no incentive to lower prices for other operator’s customers who travel into the operator’s coverage area.

It would not help much if two operators were to reach a bilateral agreement about lower roaming fees. In most countries there are three or more operators and as long as the handset connects to the strongest signal a bilateral agreement would just create a random patchwork of affordable and exorbitant fees. It would still be confusing, add uncertainty and deter usage.

Even if most major operators cooperated and formed a club with mutually lower prices, it would undermine the arrangement if only a few defectors refused to participate. The minority of defecting operators would be able to both reap exorbitant data rates from other operators’ customers as well as benefit from a larger total market and customers’ expectations of low prices.

For the operator market as a whole, the optimal end-state would be if all operators chose the strategy of cooperation, but the optimal individual rationality for one operator is to defect from any agreement. The result is that all operators are worse off in a sub-optimal state of mutual defection.

This can be modeled in game theory as an n-person Prisoner’s Dilemma. Here is a simplified numerical example with one operator (player A) playing against all the other operators (player B). Both the players can chose between two strategies: Cooperate (charge affordable data roaming fees) or Defect (charge exorbitant data roaming fees). Player A is the interesting active player in this game and Player B should more be viewed as a passive dummy.

If both players cooperate they will each receive a payoff of 10, denoted as (10, 10) for Player A and B respectively (where 10 for Player B is the payoff for each operator in the operator pool). If Player A chooses to defect while B cooperates the payoff will be (20, 9). The defecting player gains significantly and receives a payoff of 20 while Player B loses and only receive 9. If both Player A and B defect, the payoff will be (5, 5) which means that the total payoff to the players is significantly lower. One the other hand, if Player A is the only player that cooperates in an environment where Player B defects, the payoff will be (2, 6), and A only receives 2 (instead of 5). The figure below shows the game matrix described in normal form.

The payoff matrix shows the strategy of one operator (A) versus all other operators in the end states where either all chose to cooperate or all chose to defect. It is also possible to model the payoffs when the number of cooperating telcos moves from 0 –> 100 percent (described here). Regardless of the share of operators that chose to cooperate vs. defect the conclusion for Player A is the same. The dominant strategy for Player A is to defect, which makes it a classic Prisoner’s Dilemma for the active player. For Player B (all the other players) this is not a Prisoner’s Dilemma as the dominant strategy is to cooperate even if one Player (A) decides to defect. The problem is that for each individual operator it is a dominant strategy to defect even though the common good would be maximized if everybody cooperated.

I don’t have a clear answer for how to escape from this sub-optimal state. A few years ago, European voice roaming showed a similar pattern until the EU Commission mandated a price cap and forced down the prices. If the industry can’t solve this themselves the politicians may intervene again, at least in Europe.

The industry might be able to handle this on its own if the major operators form a club and then exert strong peer pressure on the remaining operators. One way is to punish defecting operators with very unfavorable roaming deals or refuse roaming. However, that will leave the club’s customers with inferior network coverage. It could possibly also be considered anticompetitive if a cartel of market dominants bullied smaller operators.

To be effective and protect the customers from accidentally connecting to a network with exorbitant prices, an operator club probably needs to have a technical software solution installed on their customers’ handsets. This software would ensure that the handset only connects automatically to networks that are members of the club, even if a renegade network has a higher signal strength. This should be manageable for operator branded handsets but if customers just have SIM cards it will be complicated to mandate that they install an app that can control low-level functionality on almost any device.

An abbreviated version of this article has previously been published on the Technorati Technology Channel.

Now that the Blackberry Playbook has been released it is fairly obvious that RIM is putting the building blocks in place for a future positioning of the Playbook as a gaming platform, most likely in their next model. [...]]]>

Blackberry Playbook

An abbreviated version of this article has previously been
published on the Technorati Technology Channel.

Now that the Blackberry Playbook has been released it is fairly obvious that RIM is putting the building blocks in place for a future positioning of the Playbook as a gaming platform, most likely in their next model. After sifting through the last few week’s industry chatter and reviews of the Playbook it seems that this connection has gone unnoticed.

The Playbook tablet received rather mixed reviews when it was released on April 19. Most reviewers liked the fast dual-core processor, the sleek design, the excellent stereo sound, and the crisp HD video. However, the reviewers were dissatisfied with the buggy software and the lack of available apps. Another thing they disliked was the need to connect with a Blackberry phone for native email, calendar etc. The most extensive reviews can be found here, here, here, and here. The impression of the Playbook is of an unfinished product that was rushed to market, though RIM promises upcoming free software upgrades.

Fair enough. But RIM is clearly positioning the Playbook for the enterprise market in this first iteration. The Playbook only has WiFi connectivity and to access the mobile networks or access your email app you need to establish a Bluetooth bridge with your Blackberry smartphone. This might seem like a clumsy solution but is actually a “CIO-friendly” move. Most corporate users in the target market already own a Blackberry smartphone. The corporate email will still reside inside the smartphone, with its very high security. If the connection is lost, no sensitive information remains on the Playbook. This would enable RIM to avoid the complexity of making the Playbook as secure a platform as the traditional Blackberry handsets right now. From a marketing perspective, it is also the right tactical move for RIM to get the tablet accepted as a dull product in the enterprise market before embarking on a gaming strategy.

There are a number of indications that the Playbook is designed to be a gaming platform. The new operating system QNX that RIM bought last year is a fast and very stable real-time OS. In embedded systems where stability is absolutely critical such as in cars, satellites, the military, medtech, and industrial equipment QNX is an established market leader. QNX will easily compete with Android, iOS, and WP7 in terms of raw performance. And at the Blackberry developer conference last fall, the QNX founder Dan Dodge said: “The Playbook will be an incredible gaming platform for game designers”. One of RIM’s top exceutives called it a “party machine“.

The design choice by RIM to equip the Playbook with high quality sound, HD-video, and a fast dual core processor also fits with this strategy. Another strong sign of RIM’s commitment is the recently announced alliance with the two cross-platform game engine firms Ideaworks and Unity. Support for QNX is currently being developed. This will make it easy to quickly port the 100s of gaming apps using Ideaworks SDK to enter the Playbook ecosystem.

Once Ideaworks has added QNX to their C++ cross-platform tool (Airplay SDK), I expect intense activity behind the scenes followed by a splash launch of 100s of fast games running native code on the Playbook when RIM releases the next model of the tablet. And I don’t think it is a coincidence that RIM chose the name Playbook.

For some time, bashing RIM and Blackberry has been popular among industry pundits. Their sagging market share is viewed as proof that it’s only a matter of time before Blackberry will be a dead platform. But don’t underestimate RIM.

With QNX and the recently acquired Swedish UI framework from TAT they are assembling an excellent technical platform. All they need now is a way to migrate apps into their ecosystem. Obviously, attracting apps is a top priority for RIM and they have chosen to use as many paths as possible to enter their new platform. QNX on Playbook supports Flash, AIR, and sandbox app players for Blackberry Java plus Android 2.3 apps. It also supports the cross-platform tools WebWorks (for HTML5/JavaScript), Airplay SDK and Unity 3 (for C++ games), and native SDK (for C++). Expect future Blackberry phones with QNX to be equipped in a similar way.

Another of RIM’s strengths is a strong foothold in two attractive market segments: corporate users and the 16-25 youth market, though RIM is not present in all geographical markets.

RIM’s stronghold in the corporate market is based on their seamless integration of secure email while the youth market is driven by network effects from the instant messaging app BBM (Blackberry Messenger). In markets such as the UK and Indonesia where the BBM has reached a critical mass it has become a must have in the youth market segment. BBM has even superseded the popularity of SMS in this market segment. You need a Blackberry to be part of the BBM messaging network.

Making gaming apps a high priority is a logical move for RIM, enabling them to attract the needed critical mass in the youth market segments in countries where Blackberry’s position is currently weak. It might even be the case that the smaller form factor of the Playbook (lower weight; 7 inch screen vs. 10 for the competitors) is a way of making it easier for teens to carry it around. Even though the gaming platform strategy is viable on its own it might just be a means to promote the real killer app for Blackberry – BBM.

Palm didn’t have the resources to quickly match the iPhone, RIM, and Android. Palm’s own smartphone, the Pre, was late to market when it launched in June last year. The industry [...]]]> The company that managed to develop the first successful PDA in 1996, the Palm Pilot, is losing out in the battle for the smartphone market.

Palm didn’t have the resources to quickly match the iPhone, RIM, and Android. Palm’s own smartphone, the Pre, was late to market when it launched in June last year. The industry chatter before the launch viewed the Pre as Palm’s last chance to survive and a do or die project.

Now the results are in. Sales of the Pre have been a disappointment. During Q3 2009 they only sold 408,000 units to customers, a drop of 29% from the second quarter. Their global market share in Q309 was 1% and Palm only has a significant presence on the North American market with a 5% market share. The Palm app store only has 525 applications.

The smartphone market already has too many incompatible software platforms: iPhone, Blackberry, Symbian, Windows Mobile, BREW, Bada and LiMo. The weakest players will not be able to build an ecosystem of developers and I think the network effects will be ruthless once the market has decided that a platform is a loser. The WebOS from Palm is just one too many.

Palm might have a slim chance if they abandon WebOS in favor of Android, but that means even more lost time. Perhaps a strong industrial buyer will acquire Palm but most of the players have already placed their bets on Android or one of the other platforms.

Palm Computing defined the PDA market in the 1990s and in 1998 they held a 59% market share. In 2005, they brought a well designed PDA-phone (Treo 650) to the market. However, at that time the mobile data networks were too expensive and lacked seamless roaming. There were no app stores. The high end smartphones of 2005 were an expensive niche product with little appeal to the mainstream market. It is a sad story that this company now seems to be heading for the grave. But if there are winners on the market there have to be losers.

Rumors about a Google Phone have been floating around for some time but gained momentum yesterday with tweets claiming that [...]]]> Google has the Midas touch and never fails – right? What if they made a Google Phone (gPhone?) and disrupted the global phone market? They already have a smartphone OS and aggressive plans for the market.

Rumors about a Google Phone have been floating around for some time but gained momentum yesterday with tweets claiming that Google employees had been given a test series of a HTC phone equipped with Android 2.1. Google’s CEO Eric Schmidt will give a keynote speech at the Mobile World Congress in 2010. Connect the dots? Yes, today Google confirmed.

Google launching their own smartphone is a significant move for this pure play internet and software company. However, I doubt that Google will be a serious threat to the major players in the market. Apple is already too entrenched as the smartphone market leader. Android is still immature compared to the iPhone OS. Nokia is unbeatable in the mass market of less advanced models. The major operators are wary about Google’s growing ambitions and will most likely be less than cooperative. Google might be best positioned to work with second tier and disruptive players such as 3. To sum up, a gphone is notable news but will most likely not overturn the industry – at least not in 2010.

Update: The phone will be called Nexus One and here is a picture (it looks exactly like a HTC Passion).