Posts Tagged ‘mobile’
In Hindsight: What Went Wrong with Adobe Flash in Mobile
[This is a repost of my guest article at the SlashData blog]
Ever since Adobe announced that it will stop developing Flash for mobile browsers, the blogosphere has been buzzing with a broad range of sentiments including “I told you so” by critics, disbelief by Flash developers, Monday morning quarterbacking by analysts, and even a petition for Adobe’s CEO to resign. Check out also the Occupy Flash and Occupy HTML manifestos from the opposing camps. Flash is one of those topics that attract very emotional responses from both its passionate developer community and its very vocal detractors. Although I am generally an Adobe supporter, I will put emotion aside and summarize, in hindsight, what went wrong. For full disclosure, I am a former Adobe employee, but this post is based only on publicly available information.
HTML5 did not kill Flash. Steve Jobs did not kill Flash. The death of Flash was caused by a time bomb planted inadvertently by Adobe many years ago.
Although Flash for mobile ultimately died because Adobe did not adapt fast enough to post iPhone changes in the ecosystem, the seeds for Adobe’s failure were planted earlier on. To understand what went wrong, let’s first review what happened before the iPhone and how those events set the stage for what happened later.
Read the rest of this entry »Mobile Blog Digest for May: Carnival of the Mobilists #249
I have the pleasure to host this month’s Carnival of the Mobilists. If you are new to the Carnival, it is a digest of the best mobile blogging for the previous month. Please join the conversation by contributing your posts and hosting in the future.
Last month we had a good mixture of analysis and round up type blog posts. I selected the ones that I thought were more insightful and/or contained practical advice for developers or marketers. Be sure to check out my pick of the month at the bottom of this article.
If you are a developer, Sean Thompson, VP of Production at GOSUB 60, wrote a nice piece on the WIP blog to help you decide if your app should be free. The top grossing apps are free to download and are monetized through in-app purchases, but should you also monetize your app this way? Sean helps you decide by considering five key questions.
Is RIM in the Smartphone Business? Or the Messaging Business? Time to Decide
When you buy a BlackBerry, why do you do it? Because you want to run many apps? Or because of RIM’s leading messaging applications and services?
In the era before the iPhone (aka “Bi“), this question did not matter as there were no viable alternatives. In fact, with hindsight, the notion of a smartphone to run many apps did not exist for most consumers. You bought a BlackBerry primarily for messaging and phone calls (maybe a couple extra apps, at best). However, in this new “Ai” era (after the iPhone), the situation is dramatically different. RIM has been incapable of defending its position as a smartphone platform against new entrants Apple and Google. And the situation can only get more difficult for RIM with the resurgence of Web OS under HP and of Windows Phone thanks to the recent Nokia deal. If RIM can’t compete in a 3 horse race, can it survive a 5 platform war?
By contrast, RIM has been very successful with its messaging and collaboration applications. RIM is the clear leader in Enterprise email, with others playing catch up. And in case you have not been paying attention, RIM has been able to build a very large base of consumer messaging users with its flagship BBM application especially in international markets. In fact, RIM’s troubles in North America are only being masked by its unprecedented growth of consumer messaging users internationally (for more on this, check out Mike Mace’s Tale of Two BlackBerries).
Should RIM continue to try to compete as a platform play? Or would RIM shareholders be better off if RIM focused on building its messaging franchise across more platforms?
Microsoft Shows its Cards with Windows Phone 7
As the launch of Windows Phone 7 approaches the question in everyone’s mind is: is it too late for Microsoft to secure a leading position in mobile? We’re now at year 3 “Ai” (After the iPhone). In the last 3 years the landscape has changed dramatically:
- Apple launched 4 successful phones plus the iPad
- Google launched Android and quickly secured a market leading position
- RIM has lost some ground with two under achieving devices (Storm and Torch)
- Palm launched the failed Pre and ran out of cash
- Once almighty Symbian faded
- Nokia and Intel joined forces with Meego
- Samsung launched Bada….
all this… and Microsoft has yet to make its first move.
In a platform battle that is surely to consolidate, in the limit, to likely one big winner plus niche players, it’s not a pretty situation for Microsoft. But if you are in Redmond you can’t afford to lose in mobile. PC shipments are an increasingly small share of device shipments, with mobile devices enjoying all the growth. Losing in mobile would relegate the Windows platform from a virtual monopoly to a minority player in only a few years when looking at all connected devices.
The question is what cards does Redmond have to play (besides a ton of cash)?
Why Steve Jobs will Never put Adobe Flash on iPhone OS Devices
[First a quick disclaimer: although I worked for Adobe in the past and I still have many friends there, I have no inside information on this topic. This post represents my personal opinion based on publicly available information.]
Given the launch of the Flash-less iPad and the leaks from Apple’s post launch employee meeting most industry insiders have finally concluded that Adobe Flash is not coming to iPhone OS devices. Over the last two-and-a-half years the conversation has shifted from
- When will the iPhone support Flash? to…
- Will the iPhone ever support Flash? to most recently…
- Why won’t Apple devices ever support Flash?
The question in most people’s mind now is why not? That is the question I want to address with this post.
While most of the debate in the blogosphere centers around technical reasons, the real reason is not technical at all. It is a calculated business decision made by Steve Jobs.
Dynamic Cell-ID: Clever way to Block Google, but will it Backfire?
Location was once a unique asset for the mobile operators. You wanted to locate someone? only the mobile operator could find him/her. A valuable asset indeed, but as we now know most operators missed their opportunity to monetize it. Location is now being commoditzed and is available freely on many high end handsets, especially those that support GPS or WIFI. However Google also offers location based on the operators own base stations, and it does this in an aggregated way, across operators and countries. This service is available on any handset that supports Cell ID APIs (most smart phones and many Java devices). To be fair, operators still have the advantage of offering location across all devices, however. In addition, operator APIs are network based and don’t require that software be installed on devices which is an advantage for some applications.
How did Google build this database of operator base stations?
The Mobile App Store Landscape 5 years Ai (After the iPhone)
[This is a repost of my guest article at SlashData‘s blog]
2009 was the year of the app store wannabes. Following the remarkable success of the Apple App Store, OEMs, mobile platform vendors, mobile operators, and traditional aggregators either created new app stores or repositioned their existing offerings as app stores. There are now between 24 to 32 app stores depending on who is counting (see Distimo’s app store report and the WIP App Store Wiki for reference), and more stores are surely to follow. However, key questions remain about how the app store landscape will emerge after the current period of hysteria subsides and the dust settles.
– Are we going to see many app stores on each handset?
– Will app malls emerge to host multiple app stores within?
– Will operator stores gain critical mass?
[Or will we see a “no app store” future as proposed by Matt Millar via the comment thread?]
Andreas Constantinou wrote an excellent article that defines the app store building blocks and predicts a “dime-a-dozen” app store future. I will build on this post, but will offer an alternative view of how the landscape will evolve.
It’s a Winner-Take-All Contest
If we were to extrapolate the current trend, we could expect a future where each handset will host many app stores. An LG Android device on the Orange network would have the LG App Store, the Android Market, and the Orange App Shop. The Verizon version would have the V CAST store in place of the Orange App Shop. On top of this, you could add the Getjar multiplatform store and several specialty stores for say, games, health, and productivity apps to name just a few. Can you imagine the mess this would create for the user experience? Which app store do I launch? Which apps do I find on which store? Are apps duplicated on multiple stores? Are the prices the same across stores or do I need to shop around? Are the versions of the apps consistent across stores?
Read the rest of this entry »How to Merchandise Your App 2 Years Ai (after the iPhone)
I want to write about merchandising apps in the mobile ecosystem, but first let me say that we need a new way to measure time in mobile. The launch of the iPhone changed the ecosystem so dramatically that any discussion of how the mobile ecosystem works must specify Ai or Bi (After or Before the iPhone), in a similar way that historians use BC and AD to date historical events.
As an example, how you merchandise a mobile application today is very different than at any time Bi. And this is what I want to post about.
At CTIA in San Diego I attended and spoke at the #wipjam event and I found the discussion on merchandising apps most interesting. It was led by Mitch Oliver from Qualcomm with many developers sharing their experiences, and I thought it would be good to share some of the learnings with developers looking to go mobile. Some of you not interested in the details may want to skip to the recommendations below.