Another excellent move by Google: Offload Motorola Mobile Devices to Lenovo, while keeping the patents to themselves. Skimming through the news this morning, I found there is apparently a lot of confusion about the planned sale of Motorola by Google. From decrying a huge loss by Google by such infotainment sites like Wired and Slate, to seeing Google giving up on copying vertical integration of Apple (hardware + software + services), like Stratechery by Ben Thomson. Let’s look at things from a broader perspective. The acquisition of Motorola was necessary to protect Android, after Apple, Microsoft and BlackBerry outbid Google for Nortel patents. The Apple-Microsoft-BlackBerry trio made it very clear that they intend to put a drag on then-fledging Android ecosystem and extort royalties from Android OEMs. The cost of doing nothing was huge for Google – just think how much more nasty the patent wars may have turned out for Android if the acquisition hadn’t taken place. Any “profit and loss” analysis of the Motorola deal must account for the opportunity cost associated with Motorola patents. Android is, was and will be critically important for Google’s core online ad business, as I will explain in a bit. The argument of Google giving up on the idea of vertical integration and going horizontal doesn’t hold water either. [tweetable]Google always was and will remain a vertically integrated company[/tweetable]. It’s just that Google is integrated where it matters for its core business of online advertising. Real-time processing of huge data sets is the key for deciding in milliseconds which ad to show to which user, while maximizing the revenue opportunity from multiple bidding advertisers. To excel and outperform competition Google builds and runs a proprietary big data infrastructure, which comprises of proprietary server hardware, custom-built system software (distributed databases, networking, data processing and more) and even uniquely designed data centers. There is nothing open or horizontal about Google’s core business. On the contrary, Google is very closed and vertically integrated, where it matters for the core business. But there is more. As any online advertising business, to excel Google needs: Remove any barriers between eyeballs and Google ads, Expand the footprint of ad inventory by offering new services beyond search, and, last but not least, Collect and mine maximum amounts of user data to improve targeting of their ads on both mobile and PC (where most ad revenues are still being made). Android is critically important for boosting Google’s core business in all of these 3 pillars of online advertising, as we wrote in our earlier note “The Naked Android”. Smartphones, tablets and PC are mere complements to Google’s core business. Cheaper and more capable smartphones, tablets and PC mean better business for Google. It’s no different from car makers that will have their business boosted by cheaper fuel available at gas stations on every corner. The Android ecosystem was purposefully designed to drive commoditisation of smartphones and tablets by reducing barriers to entry for low-cost OEM and ensuring “race to the bottom” in a horizontal value-chain configuration. (Chrome OS does the same for the PC.) To sum up, Google is vertically integrated around its core business and at the same time drives shifts to horizontal configuration of the value chain around the complements. “What about Nexus?” some will ask. I hope that by now we all understand that Nexus devices are not about making profits from hardware. Google Nexus is about driving the ecosystem forward (push capabilities up and price down) and, not less important, collect usage data. Being an extremely data-driven company (remember the famous story about testing 41 shades of blue?), how would Google know how people use Android devices and where Android needs to go next, without getting usage data from heavily instrumented Nexus devices? “But, what about the recent acquisition of Nest?” others will insist. It’s a fascinating discussion on the future of Internet of Things, but in short, both Nest and Google are companies creating value by making sense of data. Thermostats, smoke detectors, or connected cars for that matter, are just means to an end for solving the riddle. Both the acquisition and the pending sale of Motorola Mobile Devices to Lenovo makes perfect sense to me. Motorola patents were meant to protect the Android ecosystem from patent extortion (how effective they are is another discussion). The sale divests Google from unwanted device business that came as a cost of acquiring Motorola. And finally, Motorola in the hands of a very aggressive Lenovo strengthens competition to Samsung, which has disproportionately high power in an Android ecosystem designed to commoditize handset business. #acquisition #nest #nexus #sale #google #motorola

Operators have been trying for ages to launch mobile banking schemes hoping to create new revenue opportunities for themselves. T-Mobile’s latest attempt, dubbed Mobile Money, offers a refreshing new perspective on the space. Drawing on the playbook of innovators like Google and Amazon, T-Mobile uses two strategies that are indeed quite un-carrier-like. Analyst Stijn Schuermans explains. Many people that follow what’s going on in mobile might have shrugged their shoulders at T-Mobile’s announcement of the new Mobile Money service. “Un-carrier brings its revolution to personal finance; frees consumers from Outrageous fees!”, titled the press release. An enjoyable bit of drama, but nothing new, right? After all, operators have been trying for ages to launch mobile payment and banking schemes. Remember all the NFC buzz of the last few years? Direct competitor Sprint launched its Mobile Wallet (a very similar service) back in May 2013, leading Forbes to label T-Mobile as “The Late Adopter That Picks Up The Innovation Kudos”. But there may be more to T-Mobile’s initiative than meets the eye. [tweetable]T-Mobile is using two strategies with Mobile Money that are very un-carrier-like[/tweetable], indeed. Quite refreshing, actually. Playing in two markets: kill the one, win the other The press release headline sets the tone: this is a direct attack on banks and other payment service providers, as T-Mobile will not charge fees for the (basic) use of its checking account-like[1] service. (The service enables customers to deposit money, receive wages and make payments either with a mobile phone or a debit card. Here’s a brief description of how it works.) That T-Mobile targets the so-called unbanked has been widely reported in the media. The unbanked are a large group: in some states like Mississippi they number as high as 15% of the adult population. Presumably the value proposition is also attractive to a whole bunch of people who resent paying for what in an internet world seems a trivial service. If any service has a good chance of becoming widely popular with these audiences, it would be a free one from a major trusted brand like T-Mobile. The free aspect is important, as it will put pressure on the existing banking players that charge fees, including fellow operator Sprint. It will be difficult for them to forgo those revenues and compete, tipping the scale even more in favor of T-Mobile’s offering. Because T-Mobile is not interested in directly extracting money, it could kill the checkings account market. If the service doesn’t provide a revenue stream, then how does it benefit T-Mobile? The mobile industry has seen a textbook example of how this might work: Android. Google provides the Android operating system for free. In fact, Google doesn’t get much revenue at all directly through Android. It captures a mere $3B of the ecosystem’s total value with ads, representing just a small percentage of both the ecosystem and Google’s income statement. However, Android allowed Google to win the online advertising market and defend its core business. No handset maker or operator can push Google’s services off the mobile device now. In Android’s case, the hypothesis that a free product will upturn the market became a reality. Incumbents like Symbian were forced out of existence, handset making was commoditized to the extent that there are now 255 CES exhibitors whose name starts with “Shenzhen” (thanks ITG’s Gary Cohen for pointing that out) and the total amount of users of smartphone platforms exploded. The big losers were incumbent handset makers like Nokia, Motorola and Blackberry, who saw literally all of their profits disappear. Similarly, [tweetable]T-Mobile will subsidize banking services business (forgo profits) to boost the core telco business[/tweetable]. By not seeing the bank service as a revenue source, it can use it as a powerful tool to attract and retain customers. You do not have to be a T-Mobile customer to use the service, “but we save the best benefits for our customers,” the company said according to PCMag. “There are other ways you can get your monthly fees waived, but the easiest way is to be a T-Mobile customer.” If you want to learn more about how Google, Amazon and others have used the same strategy to win in mobile, check out our post on asymmetric business models. Leveraging the customer relationship Which brings us to the second smart strategy from T-Mobile. [tweetable]Finally a carrier that leverages its customer relationship and its retail assets to the fullest[/tweetable]! In our experience, telcos tend to be very pessimistic about the customer assets they have. On the one side, there is a belief that the customer relationship (including paying money i.e. billing, ironically) is irreversibly being eroded by over-the-top players: Apple, Google, social apps, etc. On the other side, the ubiquitous operator retail stores are seen as costs and as an unwieldy jumble of franchises that are near impossible to consistently manage. T-Mobile will have none of that depressed talk! [tweetable]T-Mobile’s retail outlets will become your banking branches, its employees your tellers[/tweetable]. Instead of considering retail as an unfortunate but necessary expense, the company leverages its market presence to provide more services to its existing customers, deepening the relationship with them in the process. It does so in a way that pure internet players like Google or Facebook will have a hard time matching. If nothing else, people will now have more reasons to walk into a T-Mobile store, be exposed to its offers and talk to a T-Mobile salesperson. At VisionMobile, we have long said that the distribution business including physical and digital retail presence holds a huge untapped potential. Read more in our post about the Modular Telco. Mobile Money is also fully consistent with T-Mobile’s branding as a challenger that fights to reduce costs for consumers and with the price-sensitive customer’s it targets. T-Mobile launched a whole range of initiatives in 2013 that put pressure on the pricing of its direct competitors. It focuses on no-contract offerings. As the good folks at PCMag explain (video): “If you look at T-Mobile’s customer base, especially MetroPCS’s customer base, these are a lot of younger people, a lot people who may not have access to mainstream financial services, these are a lot of the unbanked people. T-Mobile is serving this existing customer base with a new, relevant service.” As Forbes mentioned, T-Mobile is a latecomer in the payments market, and it will face many competitors. By leveraging its customer base, retail presence and brand, it is one step ahead of other large contenders, and miles ahead of startups like Simple that aim at disrupting the space with similar free banking services. Lessons for telcos The lessons for telcos are clear. You can use asymmetric business models to boost your own core business by creating huge value in another market. The other market doesn’t have to be a revenue generator: foregoing profits will gain you an insurmountable competitive advantage in that business. The resulting traction can be used to boost the core telco business through customer acquisition and retention. Kudos for T-Mobile for demonstrating that operators can replicate the strategies that internet companies like Google or Amazon have been using to win in mobile. You do have valuable assets and a customer base that can be leveraged to create new services. Think of the distribution layer in the telco business as a profit center, not just a necessary expense. I think T-Mobile’s Mobile Money is one of the most refreshing mobile banking initiatives to come out of telcos since the wildly successful M-PESA. What do you think? – Stijn (@stijnschuermans) [1]: Mobile Money isn’t technically a checking account, and it certainly doesn’t provide interest-earning services as banks would. From the perspective of what you do with the service, however, it’s close enough not to matter. #Android #mobilebanking #mobilemoney #tmobile

With 2013 drawing to a close, we’d like to present you with the top articles from our blog for this past year – and wish you a happy and productive 2014! So, without further ado, here are the top 5 VisionMobile articles for 2013 – enjoy! 5. Developer Economics: App market forecasts 2013-2016 by Andreas Pappas 4. The Naked Android by Stijn Schuermans 3. Which apps make more money? by Andreas Pappas 2. The Art of One-line Pitching: A Study of AngelList by Chris Eleftheriadis 1. Web Sites vs. Web Apps: What the experts think by Ciprian Borodescu [vm_form_download link_text=” EXTRA: How can HTML5 compete with Native? – Research report ” product_id=’4381′] Last, but not least, we’d like to present you with one of the most interesting reports we’ve published this year, taking an in-depth look at HTML5 development, uncovering the gaps in developer tools, showcasing the four different implementation paths for the platform, and taking a data-driven approach to the HTML5 vs Native debate. There is a lot of discussion around HTML5 vs. Native, and it’s usually polarized. But most people express opinion, rather than facts. In this report,  we answer some of the key questions with hard data. Anything we missed? Which was your favourite VisionMobile article? – Matos #Android #html5 #ios #mobiletrends

The survival of large enterprises calls for innovation. It requires continually creating a new set of businesses to sustain growth and profit. Guest author Avner Mor identifies five crucial ingredients that senior management should use to succeed in their innovation program recipe. Innovation exists in the form of ideas, innovation leaders and teams. Everyone talks innovation. Yet we see more and more opportunities missed by large enterprises to leverage their enormous assets – technologies, brands, relationships and routes-to-market – within their internal innovation programs. Innovation programs are constantly being established and funded, but months pass and success is often not materialized. I have seen quite a few testaments to this through my years at several global corporates and startups. I believe it possible for these large enterprises to transform innovations into sustainable future businesses. But only if senior management enables the right conditions for the innovation leaders, the expert starters, to get off the ground and to prosper with their program. Large enterprises are good in producing more of the same, or at best, continually improving current products and processes. Leapfrog innovation calls for a fundamentally different structure because the existing corporate culture and practices are destructive for internal innovation programs. Throughout my working experience in the past 12 years, I have singled out five crucial ingredients that senior management should use to succeed in their innovation program recipe. 1- Free the corporate clock [tweetable]Enterprises have their own corporate clock for tracking and measuring progress[/tweetable]. The corporate clock conducts periodical reviews of operations and financial KPIs (key performance Indicators) to evaluate success. We are all familiar with the concepts of strategic planning, market research processes, quarterly forecasts, roadmap and the infamous 3-year business plan. The innovation program leader is buried under the corporate clock: meetings, worksheets and slides upon slides. She is constantly facing operational managers who are excellent at KPIs measurement but do not necessarily have the know-how on the relevant market; neither do they have the ‘innovation spark’. Furthermore, the innovation program doesn’t know yet how its product will look or who it’s the target customer is. So how can such a program provide a breakdown of its future products sales, margins and profits for the next 3 years? Strategic planning, an 18-month roadmap and market research analysis will not – and cannot support – an internal innovation program. If the market research already exists, the opportunity is already lost. Following the corporate clock, common practice analytical methods, and KPIs to manage innovation will destroy the business, not revive it. It is true that process and management are musts for the internal innovation program. For that, the senior management should design new methodologies, to release the innovation program leader from the corporate clock and allow her to iteratively experiment, seek customer input and adjust the product and go-to-market route at every step. As Mason Cooley said, “to be fulfilled, a prophecy needs lots of flexibility” Eric Reis in the “The Lean Startup” captures it concisely – “I believe a company’s only sustainable path to long term economic growth is to build an ‘innovation factory’ that uses Lean startup techniques to create disruptive innovations on a continuous basis…breaking down a business plan into its components parts and testing each part empirically.” 2- Reward making mistakes and risk taking Paving the way for the internal innovation to become a commercial product and a sustainable business is all about small steps and experiments. Each experiment provides a new insight on what is the right way to go to market or what are the most valuable product features. Each experiment faces uncertainty and reflects risk. The correlation between taking risks, making mistakes and achieving success is obvious. At the same time, another correlation exists: when you take risks, you expose yourself to unforeseen opportunities to get to non-incremental results. The only people not making mistakes are ones playing their game without taking any risks – and without making progress. Large enterprises are intolerant of mistakes. A manager is subject to be burned out if she presents an idea, a strategy, or a direction and then changes it. The change, even if can be is clearly justified, stands out as a failure. The innovation program leader is stained with a failure to plan or a failure to deliver. If the enterprise cannot accommodate, and or even reward failure, then in the long run, it cannot succeed in building sustainable a business out of innovation programs. 3- Unlock access to the enterprise assets On the surface, having an innovation program within the enterprise can outcompete most start-ups. The innovation program can tap into years of know-how and enterprise assets, including technologies, brands, relationships and routes-to-market. This aggregate Intellectual Property is a gold mine for the corporate innovation program. These already existing elements are invaluable. They can provide a competitive edge in product value, product cost and in time to market. At the same time, established enterprise assets are owned by other divisional units – units and managers that have goals, budgets, target revenues and profits. Units and managers that are struggling to achieve their quarterly KPIs. Will they allow an unknown, zero revenue intuitive to mess with their goals? Well, good luck with that. How do you get access to assets controlled by divisional units? The answer your ‘re likely to get is: “sorry, it’s not within our strategy”; “are you trying to compete with us?”; “give us 5 headcounts and $500K to adapt the interfaces”; “we will consider it on our roadmap planning for the next 18 months” or “you can get it, but this is the ‘transfer price’ for using our product”. Summing it all up: good luck. The result will probably be, either that the enterprise innovation program waives off using the already proven company asset or that it goes to buy it from external companies (sometimes it is easier to engage out of the family). Either way, the innovation program losses the potential edge of either valuable, low-cost product or time to market. [tweetable]Enterprise is not a ‘free market’. There is no place for Adam Smith’s “invisible hand”[/tweetable]. A self-regulating behavior is wrong here. The senior management plays an important role: finding the balance between the ongoing mainstream businesses and the innovation programs. At a minimum, the senior management should: Guide the divisions to produce their functionality together with a simple service that any other group in the company could reach. In Jeff Bezos, Amazon, CEO famous memo (https://plus.google.com/+RipRowan/posts/eVeouesvaVX): “All teams will henceforth expose their data and functionality through service interfaces; Teams must communicate with each other through these interfaces; Anyone who doesn’t do this will be fired.” Guide the divisions to hide all internal transfer prices and remove internal margins on their assets’ internal usage. Thus allowing the innovation program to introduce a market-competitive price for its product. Define certain innovation programs as corporate priorities and embed them within the KPIs of the annual unit managers. Closely manage an innovation “speed boat” process that circumvents the company roadmap process 4- Clear the road to customers [tweetable]Any innovation program must strive to get its first customers[/tweetable]. The value of the first customers is unparalleled: product feedback, business model validation and your first revenue. Yet, most often the enterprise innovation program cannot reach the enterprise’s existing customers. You see, customers are owned by the enterprise sales force. The sales force is struggling to achieve its own goals for numbers of new customers, deals and actual revenue. Their focus is on short-term results. Why should they allow access to their customers to an a tiny new division with zero revenues? Again, as an innovation manager you‘re on your own. Here too, when the innovation programs approach the sales force to get access to their customers, the answer typically is: “My quota is $100 million this year, the most you would accomplish for me will be a few thousand”; “I am not going to risk the relationship with my customer for an unknown, low-quality product”; “you are competing with me on the same deal” or “wait for 12 months until I get that big deal”. Again, the senior management plays a crucial role here. Regulation is required to make innovation programs a success. If the sales force is acting upon its quota, then that quota should include the innovation program’s KPIs for revenue and new customers. The sales and the business development people should be aware that their annual commission is dependent, also, on the low numbers of the innovation programs. 5- Support and protect from the inside In the 1970s, Henry Kissinger, the US Secretary of State, made this observation on Israeli political culture “Israel has no foreign policy, only domestic policy”. Isn’t this just like corporate life? How many times do we make decisions and take actions due to internal sensitivities? Managers in an enterprise are busy making alliances; striving for consensus and trying hard to please their managers, their peers and the functional units – whether it’s HR, financial, legal or procurement. Haven’t we all seen misuse of power within an organization for the pursuit of agendas and self-interest without regard to their effect on the organization’s efforts to achieve its goals? Managers learn to ease into situations with caution, picking battles wisely, and adjusting their approach if things are not working. Working this way is inevitable, and at times, exhausting. Extreme effort must be made in order to simply interact. Asking this from the innovation program leader means that her success depends on to her ability to navigate the company corporate policies, personnel and processes to get things done. This means pushing the program to uncompetitive compromises or even jeopardizing its success to begin with. The senior management cannot help here with any guidelines or regulations. I would recommend matching the innovation program leader with a sponsor in the company, an executive who can navigate the corporate culture and create the conditions necessary to protect the innovation program leaders. A sponsor that can provide the innovation program with a seal of ‘corporate importance’,.establish an ‘island of freedom’ and alert before conflicts arise. You also need to take special care in nominating the leader of the innovation program. She needs to show personal resilience and perseverance when standing in front of internal power struggles – gossip, manipulation, or informal information sharing. She should be proactive in expressing her views and leading to a solution; show conviction and have clear influence on her internal/external peers. She should be assertive and stand for her opinion in the face of disagreement and confrontation. Clearly, not every manager has these qualities. – Avner #businessmodels #innovation

We know many of you have been eagerly expecting the announcement of the winners to the October-November 2013 Developer Economics survey. So – here they are: AR Drone – Christopher W. (@cwilkinson1998) GoPro Camera – Xu J., China Lego Mindstorm Robot – Magnus Söderberg, Sweden (@MagnusTriolith) iPhone 5c – Edy Braun, Canada (@doctorbraun) Samsung Galaxy S4 – Bryan C, USA Lumia 925 – Alex G., USA Lumia 925 – Alfonso M. $500 in-app coupon by Mob4Hire – Varun N, India (@varunnarula) A big thank you to all participants and congrats to the winners! And don’t forget – the results of the survey will be published as a free report in Jan 2014! Subscribe to our updates to receive word!

How do developers perceive different platforms and how is their platform choice affected by the type of apps they developed or the way they define success? Andreas Pappas looks into the data from VisionMobile’s Developer Economics survey in Q3 2013 to shed some light on these questions. Not long ago, the choice of a mobile platform, i.e. which mobile platform to support was a key question for developers. That question has more or less been addressed now: iOS and Android accounted for 94% of smartphone sales in Q3 2013 and there is little doubt that they will continue to dominate the market in the years to come. For organisations that require massive scale, combined with all the perks of a mobile ecosystem (monetisation, distribution, platform services), iOS and Android are the platforms of choice with a combined Mobile Developer Mindshare of over 85% based on the last Developer Economics survey in Q3 2013. Despite the dominance of these two platforms, our latest Developer Economics report showed that the majority of organisations utilise more than one platform at the same time, while [tweetable]50% of organisations utilise three or more platforms at the same time[/tweetable]. This strategy that makes perfect sense for pro developers and organisations where scale matters. So how should your organisation prioritise across all platforms you publish on? For the majority of organisations involved in app development this is a key question, as resources are scarce and, quite often, a choice must be made. For example, which platform to support first with a new game release or which platform to invest more time on when supporting an existing app? Ideally all supported platforms should be allocated the level of resources required in order to deliver the best possible product on each platform, but in practice this is rarely the case, even for the largest of organisations. There are of course, many factors to consider, such as costs, capabilities, resources, target market, revenue potential etc. The common perception regarding Android, iOS and HTML5 would probably look like this: Android is better for reaching more users iOS is better if you want to make more money HTML5 is better if you want to go cross-platform or have existing web assets We’ll now examine how developers in our survey prioritise the three big platforms (Android, iOS, HTML5) based on other selections they make or the type of business they run. We’ll see how these choices correlate with their platform priorities and whether we can shed some light on common perceptions held for each platform, as stated above. iOS is prioritised by high-grossing organisations and developers Looking at how priorities vary by respondents’ revenues we see that respondents in the lowest ranges, i.e. those that make no money or earn less than $1,000 per month tend to prioritise Android. From $1,000 and above iOS becomes the priority platform, with the share of respondents prioritising it increasing with revenue. However, the picture becomes more balanced once revenues exceed $5M, with iOS, Android and HTML5 being almost equally prioritised. While we cannot conclude that iOS brings more revenue, there is, undoubtedly a strong correlation between the amount of revenue generated and use of iOS as a priority platform. The sharp increase in HTML5 is likely associated with the use of HTML5 among large enterprises that mobilise existing HTML assets. Developers in the lower revenue brackets tend to prioritise Android more than high-earners do. This is likely associated with lower barriers to entry for Android developers and the use of Android among Hobbyists. What does Success mean for developers? We asked respondents to indicate how they measure success in app development, i.e. whether they measure success by money generated, users reached, cost savings etc. Looking at how priorities vary across different success metrics, we find that [tweetable]Android is the main platform of choice for developers that do not care about success[/tweetable] or value the level of knowledge acquired through app development, i.e. two metrics that have little to do with the business side of app development. This indicates that Android is much more popular as (but not limited to) an entry-level platform on which developers experiment or learn. Prioritisation of HTML5 increases considerably among respondents valuing cost reduction or efficiency gains. This segment most likely consists of large organisations that view HTML5 as a cost effective way to mobile existing business processes and assets, such as enterprises. [tweetable]iOS priority rises among developers that value direct revenues or brand recognition[/tweetable]. The latter factor (brand recognition) is particularly important as it indicates that iOS is the platform of choice for brands, an important value-adding element for mobile ecosystems since brands contribute to user retention and engagement. How platform selection criteria relate to developers’ priority platform Looking at selection criteria vs platform priority we find that iOS is the main platform of choice for respondents that want discovery, targeted reach and monetisation, all of which are key challenges among mobile developers. Android, on the other hand, is preferred among developers that value open standards, porting and choice of development environment, i.e. factors that are associated with the technical, rather than the business side of app development. HTML5 peaks in terms of priority among developers that value open standards, ease of porting and speed & cost of development but drops when it comes to platform APIs, graphics capabilities and revenue potential, reflecting the gap between HTML5 and native application platforms. How do different types of developers select their primary platform? Android gets much more attention than iOS and HTML5 among developers that are involved in app development as part of a side project, i.e. those whose main occupation is not app development. The reverse is true among independent app developers, i.e. developers whose main occupation is app development and are primarily self-employed: [tweetable]indy app developers show a clear preference towards iOS[/tweetable]. It is clear that Android attracts more hobbyists as it is more accessible in terms of startup costs and effort. However, developers whose livelihood depends on app development tend to prefer iOS, a platform that is known to monetise better overall. For organisations outside the app development business that develop their own apps (i.e. verticals), HTML5 becomes a key contender, surpassing Android in terms of priority and being almost equal to iOS. For such organisations (e.g. banks, retailers) cross-screen and cross-platform is very important, making HTML5 a cost-effective option. Platform priority varies by app category There are small differences between iOS and Android when it comes to app categories. Developers that develop Music/Video, Utilities and Location services tend to show a preference towards Android. Across all other categories the differences are quite subtle, with the exception of Enterprise apps, where iOS has the upper hand. But what is really interesting in this category is the rise in HTML5 prioritisation, among verticals, a clear indicator of the importance of HTML5 when it comes to enterprises. So what does all this mean? Apart from the relative differences in priorities between platforms shown above, perhaps a more interesting indicator is how priority varies for each single platform, across these choices. There are clear messages that can be taken from such analysis. For example, HTML5 is clearly considered more valuable as a platform among large organisations and enterprises, as these organisations prioritise HTML5 a lot more than organisations that don’t fall in this category. Similarly, iOS is prioritised more by brands and developers who are mainly interested in generating revenues. So coming back to our original assumptions, let’s see whether these hold, i.e. whether developers share the same views. Android: does it help you reach more users? While the statement holds some truth, developers do not necessarily associate reach with platform market share. While Android has the largest market share in terms of device ownership, there are numerous factors that can limit the addressable market for developers: API & device fragmentation, demographics and user maturity, data connectivity etc. As a result, Android does not seem to be a clear preference by developers that are interested in reach. On the other hand it is preferred by hobbyist developers and those valuing open standards, reflecting relatively lower barriers to entry and openness compared to iOS. iOS: is it better when it comes to monetisation? While Android has been monopolising the consumer market, iOS still remains the platform of choice for developers that are interested in revenues, preferred by developers who generate over $1,000 in monthly app revenues. It also has an edge among game developers, offering a less fragmented API and device ecosystem and better monetisation opportunities via direct downloads. HTML5: is it better for cross-platform and enterprise applications? The priority of HTML5 invariably increases when enterprise development comes in play. HTML has long been used for web services in enterprises and is the platform of choice for extending such services across screens and devices. We’ve summarised the key points from this analysis in the table below. Note that these are indicative of market trends, i.e. they reflect developers’ choices and should not be seen as advantages or disadvantages of each platform. For example, there is no reason why enterprise apps cannot be deployed on Android (and they are) if a business case for doing so exists. Similarly, while iOS is usually associated with higher revenues, there are many high-grossing Android apps that far exceed average iOS revenues.Prioritised more by developers whoPrioritised less by developers whoAndroidgenerate no revenue don’t care about success value open standards support develop apps as a side project develop music / video appsgenerate revenues > $5M define success by cost reduction / efficiency gains value application discovery develop apps for verticals develop enterprise appsiOSgenerate revenue btwn $1M – $5M define success by brand recognition value revenue potential independent app developers develop gamesgenerate no revenue don’t care about success value open standards support develop apps as a side project develop maps / navigationHTML5generate revenue > $5M define success by cost reduction / efficiency gains value open standards support develop apps for verticals develop enterprise appsgenerate revenue btwn $1M – $5M don’t care about success value revenue potential are independent app developers develop games Tell us what you think. We’d love to hear from you, particularly if your experience contradicts our observations! – Andreas (@pappasandreas) #Android #html5 #ios #mobiledevelopment

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools? VisionMobile’s Web Technology Lead, and author of our acclaimed “Can HTML5 compete with native?” research report, debates the performance vs. tools issue. In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers). We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen. Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps. Experts point to a tools gap As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode). It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap. Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools”. Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it? HTML5 is like a car without a dashboard [tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools. With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created. Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation. Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference. Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post. Better tools are needed HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools. With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs. Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps. What other improvements do you think are needed in HTML5? Download our research and participate in the discussion. #tools #famous #html5 #profiling #opensource #debugging #api #gooengine #performance

Why outcome-based segmentation should be the cornerstone of developer outreach strategies. VisionMobile’s Data and Operations Manager, Christina Voskoglou, explains why everyone running a developer program should focus on outcome-based segmentation and not technologies, demographics and platforms. 00 Shooting the duck Two statisticians were hunting for ducks by a creek. Spotting one taking off behind a bush both hunters fired simultaneously: The first man’s shot fell 1 meter too low while his friend’s shot flew 1 meter too high. Thrilled, they dropped their rifles and started congratulating each other, hopping about, happily chanting: “We got it on average, we got it on average!”. The duck, even happier than the statisticians, had of course in the meanwhile flown away to safety. This is a lesson on how working with averages is a sure-fire strategy to miss your targets. [tweetable]There is no average person. And there’s no average developer[/tweetable]. 01 “Are you talkin’ to me?” There are mobile platform companies like Microsoft and Apple. There are ad networks like AdMob and Inneractive. There are back-end tools companies like Parse and StackMob. There are cross platform tools like Appcelerator and PhoneGap. All of them are serving developers. All of them are competing for developer attention with marketing dollars. Most of them are talking to the Average Developer. Consumer segmentation has been a popular strategy since airlines figured out how to sell an airplane seat in 100 different ways to 100 different people. Segmenting a population to better understand it has long since been proven to be doing a better job at getting those campaign response rates up than simply addressing the whole population with an ‘on-average’ interesting message. Now companies from Amazon to ZTE are figuring out how to grab developer attention through segmentation. The bigger and more heterogeneous a population is, the more effective segment-based outreach campaigns are. And one could hardly wish for a faster-growing and more diverse population than mobile developers across geographies and platforms. Question is, how do you segment developers effectively to make sure you’re talking to the right people with the right message? The classic approach practiced by platform vendors is to segment based on demographics, skills or technology considerations such as platforms – e.g. Android vs. iOS developers. Trouble is, technology used is a choice that may have been made by different developers for different reasons. For example, a developer may have chosen Android to take advantage of its wide customer base, while others because of its lower cost of development vs. iOS. Simply grouping together people who made the same choice doesn’t necessarily result in a homogeneous group that behaves in a coherent way – choices made by Android developers who care more about reach will differ to choices made by Android developers who want to learn at low cost. If we fail to understand the drivers behind these choices we won’t be able to understand how and why choices change over time, for example why developers would switch from native to HTML5 or switch their main platform from Android to Windows Phone. Nor will we be able to see how to convince developers to switch from an existing choice to a new one – e.g. from a tool they use today to a new one offered – or why and how developers decide to commit resources and take risks in the app economy. [tweetable]Effective developer segmentation can only be based on what drives developers[/tweetable], what they’re trying to achieve in the app economy. In our Developer Segmentation report we adopted an outcome-based approach to segmentation, backed by hard data from a survey of 6,000+ app developers. The research resulted in eight distinct behavioural segments: The Hobbyists, the Explorers, the Hunters, the Guns for Hire, the Product Extenders, the Digital Content Managers, the Gold Seekers and the Enterprise IT. By focusing on the motivations that drive developers to adopt a new technology our model provides actionable insights on which developer groups to approach and how. 03 A success story Let’s consider a common scenario of an outreach program pivoted around supporting developers to succeed in the app economy. So, how do developers succeed in the app economy – how do they perceive success? You can simply assume that most people care about revenues – for example Microsoft and Nokia’s AppCampus program is pivoted on rewarding developers with money for a limited app exclusivity. However, our research proves that [tweetable]revenue-based success is only half the truth[/tweetable]: We found that just above 50% of all developers give success a definition that involves direct revenues. This implies that if you addressed all developers out there with a revenues-oriented message, about half your marketing budget would be predictably wasted. What if you segmented developers based on the platforms they use – Android vs. iOS vs. Windows Phone et-al? The next chart presents the popularity of four success metrics (out of the six explored in our research in total) within each platform – Android, BlackBerry 10, HTML5 mobile, Windows Phone and iOS. We have normalised the results over the developers’ desired outcomes in the app economy to remove bias and isolate the effect that platform choice alone has on success definitions. Differences between platform-defined segments are obviously very small to be actionable. For example, there is no great difference in what platform segments think about reach as a success metric – around 60% of all segments alike say reach is important. Platform-defined segments obviously fail to define distinct clusters of developers that perceive success in different ways. If you’ve used platform-based segmentation to understand your developers, you’ve been wasting your money. Segmenting developers based on app categories leads to similarly un-actionable results. For example take four category-based developer segments – those developing games, apps, games and apps and enterprise apps. How do developers differ based on their success metrics? Do game developers vs. app developers measure success in different ways? Again, technology-based segmentation fails to understand differences among developers with respect to success perceptions: All four app-category segments give approximately the same weight to knowledge gained (47%), while exactly the same percentage within each segment (6%) doesn’t care about success at all. ‘Games only’ developers seem to differentiate themselves from the other three segments with respect to reach and slightly with respect to direct revenues, however the resulting differences are not intuitive: Why would game developers care less about reach and more about revenues than other segments? 04 What are you trying to achieve? In our Developer Segmentation research, we segment developers in terms of what developers are trying to achieve. This is based on the Jobs-To-Be-Done segmentation methodology popularised by Harvard professor Clay Christensen. The results are not just refreshingly clear. They are refreshingly actionable. Consider the success metrics distribution for five of our eight outcome-based segments as shown in the graph below. First, notice how direct revenues are important to only 27% of Hobbyists as compared to 81% of Hunters. Hobbyists more than anyone else state that they don’t care about success (23%), while Explorers define it mostly in terms of knowledge gained (72%). Product Extenders, who aim in promoting a non-mobile product, care most about reach (70%). It is evident that [tweetable]outcome-based segmentation results in distinct behavioural groups[/tweetable]. Success metrics is obviously not the only instance where segment dissimilarity occurs. In our Developer Segmentation report we explore how outcome-based segments differ in their motivations (personal, commercial, community), in the choices they make (including platforms and tools), in the way they think (challenges, platform selection reasons), in markets they target (devices, audiences, app categories) and in the ways they make money (revenue models, monthly revenues made). We also profile them in detail (including their geographical distribution, their experience and role) and discuss what share of the app economy each segment holds. 05 Mind the sub It may be that you are interested in understanding a subpopulation of developers – you may be addressing only developers of a particular region, or developers that use a particular platform. In such cases, you will get more accurate profiles if you segment only the subpopulation of particular interest – e.g. Asian or Android developers – rather than the whole developer population. Consider for example Hunters in Russia vs. those in the US. As Hunters will always be hunters, both groups are mainly after revenues. However, Russian Hunters care more than their North American colleagues about the knowledge they gain, and also a slightly higher percentage states to be indifferent to success. These differences point to a less ‘mature’ market and therefore a less ‘mature’ set of hunters in Russia: Most probably a higher percentage of Hunters there than in the US are at their early stages, currently more focused on building know-how rather than reaching customers – something you wouldn’t have picked about Russian developers if you had just used the ‘global’ profile of Hunters. If you care to understand developers, you need to understand what motivates them, what they consider success and what they’re trying to achieve. Our Developer Segmentation research has done just that. What other stories have you seen where developers are poorly understood or mis-marketed? – Christina (@ChristinaVoskog) #developersegmentation #mobiledeveloper #segmentation

It had become painfully clear to Android’s executives: they had officially lost control. Something had to be done. There was only one option: to strip Android naked. Senior Analyst Stijn Schuermans explains how Google made it tough for ambitious rascals to fork Android and dump Google. It had become painfully clear to Android’s executives: they had officially lost control. The operating system had been forked by Amazon and too many Asian handset makers. Worse, it had become too easy to replace Google Play with a proprietary app store yet leverage existing Android apps; too easy to replace Google’s services (Maps) with 3rd party alternatives (Nokia’s HERE). Even the Android brand wasn’t the king of the hill anymore, being eclipsed by Samsung’s Galaxy. Something had to be done. There was only one option: to strip Android naked. And so that’s what Google did. It let go of control over Android-the-OS. Instead it consolidated control on the APIs needed to make apps, consolidating them within the Google Play Services app. If any rascals want to fork the Android operating system, let them: they can no longer take the entire app ecosystem with them. Google’s control of Android is eroding Several years ago we wrote a post criticising Google’s openness statements around Android. Our 2011 study on the Open Governance Index found that [tweetable]Android is the most closed of all mobile open source projects[/tweetable]. We were also the first to document the Android control points in 2010, three years before the EU finalised its antitrust investigation. [tweetable]Android has been open to developers, but not to handset makers[/tweetable] who have had to comply with Google’s draconian certification and bundling of their apps and data mining software. Despite the open source and zero-priced nature of the Android OS license, Google could not easily be bypassed. OEMs needed Google for the trademark, Google’s killer apps that leverage its online services and identity (GMail, Maps, and many others) and the Play Store, to get access to the hundreds of thousands of apps that end-users demanded. By cleverly closing down those parts of Android that matter, Google had gained a large amount of control over those who wanted to make an Android handset. A reaction was inevitable. [tweetable]Over time, Google’s control points were systematically attacked and eroded[/tweetable]. Amazon and Yandex, to name just a few, successfully replaced the Google Play store with their own app and content stores. The One Platform Foundation (led by Yandex and Opera) attempted to liberate in-app payments and the app store packaging format from Google’s control, so that you can publish an app on multiple stores with a single click. Nokia HERE (formerly known as Navteq) provided a decent licensable alternative to Google Maps. Samsung spent a lot of effort in recreating all of Google’s services. Samsung also spared no expense in creating its own Galaxy brand, which is becoming as well-known as Android. With Google partially losing control over Android’s app ecosystem, the advertising giant had to do something. It decided to strip Android naked (a term coined by Nicolas Sauvage). It did so by shifting the control points one level up. Closing down the APIs Instead of gaining control through operating system certification, Google moved more and more critical APIs out of the open source operating system and into its proprietary Google Play Services software. Update: We just learned Google will ship Android 4.4 without the Chrome browser. This had an immediate advantage: it reduced the fragmentation problem that had been plaguing Android for years. Google Play Services is a piece of software that Google can update silently (without the user’s action or even knowledge) and over the air. Google no longer depends on handset makers and operators to update the software that app developers depend upon. Many users might (and do) have old Android versions on their devices: 26% of devices still use v2.3 Gingerbread, released almost three years ago, while only 2,3% uses v4.3 Jelly Bean, released in July 2013 (source: Google, Nov 1, 2013). Over 99% of devices, however, can run the latest version of Google Play Services. It is this which matters most to app developers. But this was just the start. Controlling app development Many developers will now be using a mix of OS and Google Play Services APIs; the former being available on any Android fork, the latter not. Before, the API gap between Google’s version of Android and forks of the OS was mostly in-app billing (the problem that OnePF was trying to fix). Now this gap includes many important services that a lot of developers depend upon: authentication, location APIs, messaging, to name just a few. Developers will now be forced to rewrite parts of their app for each Android fork they want the app to be distributed on. [tweetable]Google has lost some control on distribution & discovery, but is regaining it on development[/tweetable]. ARS Technica has done a good job of documenting the end-user implications of this move. Yes, you have your photo, email and other apps in Android public codebase (AOSP), but they are poor cousins of their Google-supported versions. Google seems to prioritize APIs that add innovation and end-user value to their services, so that AOSP apps look outdated. But beyond the effect on end users, the implications for device makers are far more widespread and lasting. Google’s move puts up the pressure on Amazon and other Android spinoffs to provide alternatives APIs on top of Android to replace those incorporated in Google Play Services. Some are trying: Amazon for example recently added analytics and split testing capabilities to a list of APIs including login, backend services, billing, push messaging, ads and of course the Amazon Appstore for distribution. Amazon and other are taking great pains to making migration to new APIs as easy as possible, e.g. by showing how to match the Maps APIs with theirs. Even so, companies who fork Android will have to convince developers – who have limited resources and attention spans – that their version offers a large enough user base to be worth supporting. Only a few, if any, will succeed. The endgame for Google: flatten, expand, mine The “Android ecosystem” has become a misnomer. It really should be called the “Google Play Services ecosystem”. (Sadly, it doesn’t’ have the same ring to it.) Google has re-established firm control over the apps that drive Android’s success as a platform. Android as an operating system is still important to Google in the light of its defensive strategy to flatten everything standing between the user’s eyeballs and Google’s ad inventory. Android has succeeded, and will continue to succeed, in preventing any mobile platform from becoming a monopoly in the way that Microsoft Windows was on the PC. But Google’s strategy has two more pillars: to expand its footprint across the user journey with more services, and to increase the value of its ads by data-mining the user’s behavior. Not Android, but Google Play Services is now driving Google’s expand and mine imperatives. Google has certainly shown mastery in making open source work to its advantage. Of course, we can’t assume that this is the end of this story. If you were Amazon, Yandex or Samsung, how would you react? – Stijn (@stijnschuermans) #fragmentation #amazon #googleplayservices #google #yandex #Android

Our very own Dimitris Michalakos will be presenting our latest HTML5 report at the Eurapp Workshop: Rebooting the EU App Economy (Berlin, November 13).

After Blackberry announced disastrous Q2 results, news broke that Fairfax’s offer to take the company private had hit funding snags as pension funds were uninterested. This shouldn’t be particularly surprising, but it means that a break-up is now the most likely outcome for the embattled smartphone manufacturer. Let’s use Blackberry as a lens to see what we can learn about declining businesses. This article, by Sameer Singh, was first published at Tech-Thoughts. 1. Companies cannot attack established ecosystems from behind The easiest takeaway from Blackberry’s decline is that no single company can compete against an established ecosystem. Blackberry’s decline began once iOS and Android were firmly entrenched as leading mobile ecosystems. Blackberry failed to understand that creating a viable ecosystem around the BB10 operating system was extremely unlikely given the timelines. By the time BB10 was productized, iOS and Android already held dominating positions in the market and developers had no reason to look back. It is possible to compete with ecosystems, but only with a truly disruptive product that offers consumers a new user interface paradigm with a new form factor. New user interface paradigms need new types of applications and, therefore, attract a different breed of developers. However, this requires a much longer time horizon as the new platform/ecosystem needs to improve sufficiently to challenge the incumbent platform. The transition from the PC to tablets in the consumer market is an ideal example of this pattern. 2. The “best” customers cannot be used as a benchmark to gauge its prospects There is a tendency among industry watchers to gauge the future of a company based on feedback from the company’s best customers. Unfortunately, the highest or most demanding tiers of a customer base are often the worst judges of an established company’s prospects. While Blackberry’s business was being disrupted by the iPhone and Android smartphones, their core “enterprise” and “prosumer” markets remained fiercely loyal. Many analysts remained steadfast in their opinion that Blackberry’s core customer base would ensure the company’s relevance in the years to come. The problem with the “best” customers is that they provide no information about the dominant basis of competition in the industry, i.e. the mainstream market. Blackberry’s core user base always held the opinion that their email/messaging services and hardware keyboard gave the company a sustainable competitive advantage over competitors. Unfortunately, while industry watchers were preoccupied with those features, the basis of competition in the mainstream market shifted to ease of use, availability of apps, full featured browsing, etc. 3. The seeds of failure are planted well in advance Blackberry’s market cap peaked in 2008, a year after the iPhone was launched. In fact, some of Blackberry’s best financial results came after the mobile computing disruption was well underway. While Apple and Android OEMs focused on the shifting basis of competition in the industry, Blackberry was content with milking their existing user base. However, once the basis of competition shifted, Blackberry could do nothing to regain its competitive advantage. Therefore, it is impossible to gauge the prospects of a company purely by tracking short-term financial results. The true test of a long-term strategy is how well it fits with the evolving basis of competition in the industry. #ios #mobilebusinessmodels #BB10 #Android #Blackberry

We’re happy to announce the launch of the Developer Economics survey (running October 23 to November 22) – you can take the survey here. Every respondent to this new survey gets one month of free crash reporting & app performance tracking (value of $19), courtesy of our friends at Bugsense. All respondents also enter a draw for an iPhone 5c, a Galaxy S4 and two Nokia Lumia 925s after the survey is completed. We also have extra prizes to people who subscribe to the panel (you can do that via the survey).

As we launch our new Developer Economics survey [UPDATE: Survey now closed – results out Jan 2014], Senior Analyst Andreas Pappas quantifies the international dimension of the app economy to visualise app trade routes. With barriers to international expansion disappearing, today’s app economy knows no borders. But almost 50% of developers are not yet crossing those borders. One of the things that make app development attractive to developers is the relatively low effort involved in selling apps across international borders, compared to other forms of international trade. The low barriers to selling apps internationally make app development attractive even in regions where smartphone penetration and app consumption has yet to reach a level that can effectively support local app development. This is the case in Asian countries with smartphone penetration below 20%, compared to over 50% in Western Europe. To some extent, app development is even more attractive in Asian regions, as labour and other costs are lower, compared to western app economies. [tweetable]Despite the global app economy, the majority of app developers only address their local markets[/tweetable]. This observation is more prevalent in regions with high smartphone penetration and more mature app users. As the next chart shows, over 95% of developers based in North America and Europe generate app sales in the region in which they are based in. On the contrary, in Asia, Latin America and Africa there is a sizeable minority of the local developer population that do not report any revenue in their local markets. For example, in Asia, 17% of local developers do not generate revenues in Asian markets. In Africa this number rises to 31%. North America is a prime target for developers across the world Looking at app exports, i.e. sales outside of a developer’s own region, we see that the majority of developers that generate revenue via exports, export to North America. [tweetable]35% of developers based in Europe and 33% of developers based in Asia, generate revenues in North America[/tweetable]. The number of developers that export to Europe is quite lower, with just a quarter of developers in North America and a fifth of developers in Asia generating revenue in Europe. In other words, the North American market is clearly a prime target for developers across the world. Going global leads to higher revenues For developers within any region, export revenues exceed local revenues by a large margin. [tweetable]Developers in North America generate 61% of revenues via exports, compared to 39% via local sales[/tweetable] For Europe-based developers, sales are similarly skewed towards exports: 65% exports vs. 35% local sales. This makes perfect sense, since the global addressable market outside of each region is larger than any one region, and demand for apps is global. However, looking at the share of developers that export apps, within each region we can see that nearly 50% of developers that have yet to seize the global opportunity. While localisation may still pose significant difficulties and not every app may be a good export candidate, international expansion should be among the top objectives for app developers and entrepreneurs, particularly those based in small markets and those that need to scale fast. You can help us capture and share more app economy trends by taking part in the 6th Developer Economics online survey. Have your say today and shape the app economy to come. Plus, figure out how you compare to developers in your region in terms of revenues, tools and platforms (free subscription to research panel required). [UPDATE: Survey is now closed – results out in January 2014] Love this article? Hate it? What you’d like to read about next? – Andreas P follow me on twitter (@PappasAndreas) #Android #appmarket #ios #mobiledeveloper

VisionMobile Managing Director, Andreas Constantinou, presenting at Swiss Mobicamp: – App Economy trends: developer sentiments, forecasts and motivations As the leading authority on the app economy, Andreas Constantinou, will present Vision Mobile’s latest findings from the largest ever developer survey. – Workshop #7 – Business model disruption: decoding the masterminds of Google and Amazon How does Google monetize Android? How do Google’s 60+ services fit into the ambitions of the most successful advertising network? Want to register? Don’t forget to use the “VisionMobile” code for a 15% discount – register here: www.mobicamp.ch/registration/