Tag Archives: apple

Succeeding in an App Store world: lessons from the Angry Birds story

At Mobile World Congress earlier this year I heard Rovio CEO Mikael Hed address a small group of Apple platform developers on the subject of the changing world of app development. His starting point is that mobile apps and the app store model are transforming the business of software. Of course he has a games industry perspective, but my hunch is that what he says applies more widely. I note that the App Store concept has already come to the Mac, and that Microsoft will follow Apple with something similar in Windows vNext.

What is the effect of an App Store? It combines opportunity and challenge for developers. Opportunity because apps can be found, purchased and installed in a few clicks. Challenge because app stores attract lots of apps, and the barriers to entry are low, much lower than traditional retail channels. This forces prices down and makes it hard to have your particular app stand out.

The App Store model seems to include the idea of single-purpose apps at low prices. Apple still sells iWork, its office suite, for £72.00 as boxed product (UK prices), but on the Mac App Store it is split into three products, Pages, Keynote and Numbers, at £11.99 each. Even if you buy all three it is half the price of the box.

Mac desktop apps are larger and more sophisticated than iPhone apps, so I guess they will always attract higher prices; but I also guess that the factors which have driven down prices on the iPhone App Store will exert the same influence on the desktop store.

So where are prices going? Here is what Hed told us:

On the pricing side, we know now that on the App Store the standard price is fast becoming free, zero. And the premium price is 99 cents. If you go higher than that, then there are higher risks, because you might never reach the top ten, or top 100, and if you do, it will drop off very fast, there’s huge price sensitivity. So this also is a big change for traditional publishers who are used to high prices up front, and that’s the classic business model in gaming. That is changing, so game developers must find additional revenue streams.

This low pricing is the foundation of his thesis. Hed’s view is that software companies, in the games industry at least, have to be ready for it. Further, he thinks that the shift toward mobile is profound and will not reverse:

We are seeing right now a big shift from retail focused, location based games where you have to have your console plugged into your TV. That is slowly slipping away and in its place is coming the digitally downloaded game that you can play anywhere.

How then do you survive and prosper in this new world? Hed’s answer is to build a brand, and find diverse ways to monetize it.

He told us the history of Angry Birds. This, he says, is the first mock screenshot which his game designer made in 2009:

image

The way he explained this game concept to me was that you have these different coloured birds and then you have blocks with similar colours, tap on one of the blocks and the birds will fly and destroy that block. I listened to that description and I felt like, maybe this game concept is not a winner as such, but everybody liked these characters very much and we felt like, hey, we have really here a good starting point.

Rovio at the time was doing what Hed called “work for hire”, such as casual games commissioned by operators or other publishers. “We didn’t have a lot of capital to put into our game,” he said. Rovio kept half its 12-strong team doing the work for hire, and put the other half on Angry Birds. This meant the game took 8 months to develop rather than the usual 3 or 4 months, but he said this slower development time worked out well because the result was more polished.

Hed told us that most app developers push out apps too quickly:

They are concerned about getting their apps quickly out there on the market in order to start generating revenue. Before Angry Birds we did release a couple of other iPhone titles and they didn’t do well at all. We learned a lot from that and one of the things we learned is that never release something that is not completely finished, because it’s so easy for reviewers to just rip your game apart because something about it was not perfect. And that is exactly what is happening. It’s tremendously demanding, the consumer on the app store is tremendously demanding even if they pay only 99 cents, they still expect it to be perfect.

Even more significant was that Rovio consciously planned for Angry Birds to be more than just a game:

Our primary goal with Angry Birds was not to make a lot of money in the app store. Our primary goal was to build a brand.

Angry Birds took off pretty fast. It became the top seller on the iPhone App Store, first in Finland, then in the UK in February 2010, then in the USA in April 2010. Rovio made some decisions. First, it would stick with Angry Birds and build it into a strong franchise, rather than simply investing its profits into new game titles. Second, it would continue to offer free updates for the original app.

Where then are the “additional revenue streams” which Hed says are essential in order to thrive in this new world? In-app purchasing is one, he said, but Rovio decided not to sell additional levels via this channel. Instead it came up with the Mighty Eagle, which he calls a product rather than a feature:

In the Mighty Eagle we offered a way for users to pass levels that they are stuck on, so it gives added value to the users. But we made it into a product, and that is one of the important things of how we act in the marketplace, we make products, we don’t make features. And in this our big role model is Apple. You can see that nobody is that much interested in one “feature”. People want products. That’s why you don’t see Apple coming out with a feature called video calling. You see them coming out with a product called Face Time.

I am not entirely convinced by the distinction between products and features, but I understand the value of this way of marketing software. Hed says Rovio has been rewarded with a 40% conversion rate, much higher than for most in-app upgrades.

Rovio is also doing merchandising. 

image

This helps to sustain the franchise and to make sure that the franchise stays relevant for years to come, and it supports our game sales, and our game sales support our merchandising sales.

he says. It is another example of finding additional revenue streams.

Hed also talked about TV and film projects. Rovio partnered with 20th Century Fox to make a game that ties in with Rio the Movie, hence the game Angry Birds Rio.

He adds that mobile advertising is a key area:

We can see from the amount of time that people spend playing our games and playing everybody else’s games and using those apps, that mobile app advertising will be huge. We will see shifting of advertising towards mobile, because there users will be engaging for long periods of time, they will be exposed to brands repeatedly, they will be closer to the point of purchase.

This has worked for Rovio so far, though personally I am not sure for how long it can prosper if the Angry Birds franchise is all it has. It is a fashion thing and people will get bored of it – or does Rovio now have its own enduring franchise like Disney’s Mickey Mouse?

My main interest though is Hed’s insistence that software world is changing, prices are tumbling, and software developers will have to look for ways to monetize apps that go beyond the purchase price. “It’s the same for everybody. Now the industry is in the midst of transformation so everybody must adapt,” he says.

The mobile app ecosystem before Apple – was it really this bad?

For some time I have been meaning to post about a talk I heard at Mobile World Congress, by Rovio (Angry Birds) CEO Mikael Hed. What interested me about this talk was not so much the Angry Birds app itself – now downloaded over 75 million times – but rather Hed’s thoughtful perspective on what it is like to be a software company in the App era. “It’s been a year of transformation not only for us but for the whole industry,” he told us.

image

Hed started his talk by describing life as a mobile games developer before Apple launched the iPhone in 2007. Rovio was founded in 2003, and did 51 titles before Angry Birds, encompassing “every type of game,” he said.

Before the iPhone came along we were on feature phones only. That market was completely different from the iPhone market today. Looking back on it, it’s a small miracle that there were any game companies in that ecosystem.

Why? Several reasons.

In order to have a game commercially available on a feature phone, you would have to make that game, and make probably nine other strong games in order to be interesting to the carriers. And the carriers would only take your game if you could support all the handsets that their customers had. That meant hundreds of handsets.

Dealing with the carriers was a huge headache.

You would have to make an agreement with each carrier in each country, and you had to have an all-day sales team working for you to do any business at all. It was really expensive.

After all that, the revenue share and payment system was loaded against you.

All operators would take more than half of the revenue that you would make, and then pay you a long time after your game is out. They would report quarterly, and once you get the report you send them an invoice, then they have ninety days to pay. So if by some miracle you manage to get your game onto their devices , the earliest time you would see your money would be six months later.

The system was poor for consumers too.

It was also very difficult for consumers to find these games. It varied a lot across the different carriers, how you find the games. You might have to send an SMS somewhere and get a link back, click on that, download the game, and then hope that the game would actually run on your device; and probably at the end even if you had the latest and greatest phone it was made for the lowest common denominator so it would not use any of the nice features of your phone. So you would get a poor experience, if it worked at all. That was the past ecosystem.

Ouch. Was it really that bad?

The immediate conclusion is that while Apple’s closed and dictatorial iOS ecosystem has drawbacks, it is at least one that works, whereas what existed before was badly broken.

So how are things for app developers now, in the Apple era? Look out for a follow-up post soon. And by the way, it is still by no means easy.

Why Spotify should stick to streaming, not copy iTunes

Today Spotify announced iPod support. Essentially it has reverse-engineered enough of the Apple iPod’s protocols to let you connect an iPod and sync a Spotify playlist to it.

The catch: in order to sync a playlist you have to buy MP3s for all the tracks it includes.

Spotify has great software and I love the service, though sadly it is now crippled for free users. It already supports smartphone users through an offline feature, combined with a mobile app, though this requires a premium account.

The new model is different. Instead of being an offline cache for streamed music, it is old-style MP3 purchase. In fact, the promotional video presents the new feature in simple terms: you can now purchase and download your Spotify playlist.

So what is Spotify now? A streaming service, or a download service? Was the crippling of the free service done with this in mind, to push users towards MP3 purchase? Is this another symptom of music industry pressure? Will Spotify further cripple its streaming service, to promote download purchases?

Personally I have little interest in yet another MP3 download option. For iPod or iPhone users, Apple iTunes wins on usability and integration, Amazon MP3 on price.

I have great interest in subscription though. Spotify has been liberating in this respect. Want to play something? Just search and play, instantly. That is what Spotify does so well. It should stick with it, rather than moving back into the download era.

Building a PhoneGap app for iPhone with Adobe Dreamweaver CS5.5

After trying out Adobe’s new Dreamweaver CS5.5 for building a PhoneGap app for Google Android, I was keen to try the same for Apple iOS. In particular, I wanted to see if the performance problems with jQuery Mobile and PhoneGap on Android were also an issue on iOS.

This turned out to be more complex than I had imagined. Bear in mind that I have not done a lot of previous iOS development; but I reckon that makes me a good test case for Adobe’s market here. Ideally you should be able to use Dreamweaver alone to build your app and make a fortune on Apple’s popular app store.

I installed Dreamweaver CS5.5 without any issues and copied my Calculator example from PC to Mac. I am not going to repeat the steps that were the same as for Android; read my earlier post. I will mention that I puzzled over the setting for the IOS Developer Tools Path. After trying various sub-directories I eventually discovered that simply entering /Developer here works. One of the issues I have with this stuff is that clicking Help generally does not help. I resorted to watching one of Adobe’s videos and checking out the screen there.

My app worked fine though and I was able to run it up in the iPhone simulator. However I really wanted to test it on the device itself. The problem: this is all you get in Dreamweaver in terms of application settings:

image

I have not yet found any documentation from Adobe concerning what to do once your PhoneGap app is ready for on-device testing, though there may be some somewhere.

My solution was to download a separate install of PhoneGap, picking the latest version which is 0.9.5. Then I downloaded Xcode 4 and the latest iOS SDK; I had not previously installed this as I have only just signed up for Apple’s paid developer program.

I might have been better sticking with Xcode 3.x, as it turns out that PhoneGap’s support for Xcode 4 is still work in progress. I used Shazron Abdullah’s script which creates an Xcode 4 PhoneGap project from the command line. Then I copied my Calc application and the jQuery mobile directory into the project and opened it in Xcode 4.

Nothing worked and I had to do a number of things to get it to build. Most problems were solved using this guide by Cameron Perry and the comments which follow. Here’s what I recall doing:

  • I removed a red link to PhoneGapLib.xcodeproj and added it back from ~Documents/PhoneGapLib
  • I added i386 to the list of Valid architectures in build settings, for both the PhoneGapLib and my Calc project
  • I added an entry for PHONEGAPLIB to the Xcode 4 Source Trees, set to /Users/username/Documents/PhoneGapLib/ using the full path and not the ~Documents abbreviation.
  • I obtained an ID for my app from Apple’s developer portal and pasted into the project as the Bundle identifier (info section).

At this point the project almost built but I still got two Apple Mach-O Linker errors relating to PhoneGapDelegate:

image

I tried a couple of things to fix this. I added the PhoneGapLib project as a target dependency for Calc, which did no harm but was not a fix. Then I went to the Link Binary with Libraries section of Build Phases and added a reference to libPhoneGapLib.a

image

The odd thing is that libPhoneGapLib.a now appears in my project in red, suggesting something missing, but the project now builds fine; I am sure an Xcode 4 guru can advise.

So here is my app running on a real iPhone 4:

image

I slightly modified the design to fit the iPhone 4 screen.

Now for the bad news: performance is still not really good enough. To be clear, the problem is a slight pause between tapping a button and the number being entered. One bad symptom is that if you are in a hurry and tap several numbers quickly, some may not register. The iPhone 4 runs the app slightly better than my HTC Desire, but I would still not be happy releasing it with this performance – leaving aside the fact that a better calculator app comes free with the iPhone.

I tried specifying a release build in Xcode 4 but it made little difference. I suspect performance could be improved either by not using jQuery mobile, or by configuring it to reduce the richness of the buttons it creates.

Leaving that aside, it seems to me that Adobe has some work to do in making it easier to get from a Dreamweaver project running in the emulator, to an app that you can test on a device and deploy to the app store. Although the steps I took seem arduous, it is not really so bad once you get it working. You could create a much more complex app entirely within Dreamweaver, and then the work involved in moving it to Xcode would be pretty much the same as I had to do for my simple calculator. So I am not going to say that the PhoneGap integration is no use, just that it needs better documentation. Maybe in the next version we will get fuller integration that will do device build and deploy as well as building for the simulator.

Photosynth for iPhone: capturing the unphotographable

We are having some unusually fine weather in the UK and I went for a walk in the Derbyshire Peak District yesterday. I was reflecting how hard it is to photograph wide vistas of countryside when I remembered that I installed the Microsoft Photosynth iPhone app a couple of weeks ago.

image

It really is easy to use: you just fire up the app, tap to start a new picture, and turn the iPhone to new positions guided by on-screen markers. When the iPhone beeps, hold it still and a new photo is added.

image

Panoramic photography is not new of course; my old Canon Ixus has a panorama feature. However, you have to navigate several menus to get the mode engaged, manually position the camera, and then use a separate application to stitch the images together.

The Photosynth app by contrast is great to use, and I have taken a landscape picture which I would never have bothered with before. My only complaint is that the beep can be hard to hear, but even if you miss it, the app does a reasonable job, especially in bright sunlight.

There are plenty of interesting images now turning up on the official Photosynth site – check the Mobile Panoramas section.

For more information see the official announcement post and video.

The point to ponder is why the app has come out first for Apple’s iPhone, rather than the company’s own Windows Phone7? Apparently a Windows Phone version is in preparation.

Hands on: Building a PhoneGap app with Dreamweaver CS 5.5

One interesting feature in the new Adobe Creative Suite 5.5 is that PhoneGap is integrated into Dreamweaver. What this means is that you can build a mobile app for Google Android or Apple iOS from within Dreamweaver.

I have just installed the new suite, so decided to give it a try. My project: to create a working calculator app and install it on an HTC Desire (Android 2.2).

I started by creating a new document based on the PhoneGap Mobile Starter.

image

Next, I created a new site with the name “Calc”, in a folder called Calc.

I saved the page as index.html. When I did so, Dreamweaver prompted me to copy a bunch of JQuery Mobile stuff into the folder.

Then I selected “Configure Application Framework…” from the Mobile Applications option on the Site menu.

image

This menu is pretty much all you get for PhoneGap support. The Configure option lets you select the Android SDK or install it. Mine was already installed.

image

If you want to build for iOS, you need to run Dreamweaver on a Mac, though I guess you could code on Windows and build on the Mac using PhoneGap in the normal way.

The next step was to write the application. I mostly used the code view. DreamWeaver has a handy Insert panel which you set to jQuery Mobile. Drag controls from here into your code or design view.

image

Beware: the design view is a bit hopeless for jQuery Mobile apps, unless you have Live view switched on. Here they are side by side:

image

I built probably the world’s worst calculator. Assembling the user interface was easy though. I used a jQuery Mobile Layout Grid for the buttons. I wrote some quick JavaScript with no error handling whatsoever. I used Firefox and its error console for simple debugging.

When I was done, I selected “Application Settings…” from the Mobile Applications menu. Here you can set a few properties including the version and the icon.

image

Build and Emulate from the Mobile Applications menu.

image

This installed the app in the Android emulator. I could run it successfully, though it was mighty slow. You click a button, then after a noticeable pause the app updates to show the value you clicked. However, my app worked.

image

Next, I attached my Desire phone, and copied across the calc-debug-apk package which had been built. I detached the phone and tapped the app. Again success – but the app, while faster than the emulator, is still slow.

image

That is possibly because it is a debug build. But how do you specify a release build? I cannot find a setting for it in Dreamweaver, which seems a striking omission. I am hoping it is possible to tweak the PhoneGap build properties in the generated source, but it looks like I will need to consult the PhoneGap documentation for this.

On the one hand I am impressed. The UI looks nice considering how little time I spent on it, thanks to jQuery mobile. Further, the application works, and I was able to build it entirely in Dreamweaver. The code completion in Dreamweaver’s editor is decent.

On the other hand, documentation is terrible. This article is almost all I can find – beware the dud link to abobe.com:

image

I am not complaining about the PhoneGap docs or the jQuery Mobile docs, but the Adobe docs for using this in Dreamweaver. I hope that more will come.

Update: I spent some more time on this trying to fix the performance issues. The fact of being a debug build should not affect performance as far as I can tell; it merely signs the app with a debug key. I moved the project to the standard Eclipse tools and built it there in case Dreamweaver was messing up the build in some way, but performance is just as bad. More research throws up threads like this one:

I’ve been using Phonegap & JQM on a real device and it is also very slow (HTC Hero, upgraded to 2.1), but it flies on an ipod touch 4th gen. I guess the HTC is just getting old but I’d like to try it on a more modern device.

My initial conclusion then is that a jQuery Mobile/PhoneGap app on an HTC Desire running Android 2.2 will never perform well. It sounds like it might be OK on iOS; I guess I should try that next.

See also my interview with Nitobi president André Charland about PhoneGap.

Developers and mobile platforms: lies, damn lies and surveys

I’ve been reading the IDC/Appcelerator developer survey about their attitudes to mobile platforms. The survey covered 2,760 Appcelerator Titanium developers between April 11-13, so it is certainly current and with a sample just about big enough to be interesting.

The survey asks developers if they are “very interested” in developing for specific platforms, with the following results, and with comparisons to 3 months ago:

  • 91% iPhone (fractionally down)
  • 86% iPad (fractionally down)
  • 85% Android phones (down from 87%)
  • 71% Android tablets (down from 74%)
  • 29% Windows Phone 7 (down from 36%)
  • 27% Blackberry phones (down from 38%)

The survey is titled:

Apple shines, Google slows, and Microsoft edges RIM in battle for mobile developer mindshare.

Is that a fair summary? It is not what I would highlight. I cannot read the exact figures from the chunky graphic, but it is clear that the iOS figures are also fractionally down, maybe by just 1%, but hardly much different from the Android figures on a sample of this size. Both are pretty much flat.

The figures for Windows Phone 7 and Blackberry are more dramatic; though we should at least note that Appcelerator Titanium is a cross-platform toolkit that does not currently support Windows Phone 7, and that its support for Blackberry is only in preview. That was true last time round as well, but I’m not sure that asking developers about their plans for a platform which the toolkit does not currently support is the best way to gauge overall interest.

Another question that interests me: is developer interest a cause or an effect of a mobile platform’s success? A bit of each, no doubt; but personally I think the “effect” model is stronger than the “cause” model. Developers pick a platform either because they have immediate customers for apps on that platform, or because they think they can make money from it.

Nurturing a strong developer community is definitely important for a platform provider; but I doubt it ranks as highly as other factors, like building a strong retail presence, delivering excellent devices at the right price, and focusing on usability and a good end-user experience.

If you are interested in Appcelerator Titanium you might like to read my interview with the CEO at Mobile World Congress; and this discussion on whether Titanium really builds native apps.

The rise of the eBook is a profound change in our culture

The Association of American Publishers has announced that in February 2011 ebooks ranked above print in all trade categories. Note that these figures are for the USA, and that in revenue ebooks are well behind print – $164.1M vs $441.7M. It is also worth noting that print sales are falling fast, 24.8% year on year, whereas ebooks are growing fast, 202.3% year on year.

image

This does sound like a reprise of what has happened in the music industry, where broadly speaking physical formats are heading toward obsolescence, download is growing, but the overall pie is smaller because of the ease of piracy. There is perhaps another more subtle point, that when the marginal cost of production is near zero, prices too tend to race to the bottom in a competitive market.

Books are not equivalent to music. Physical books still have advantages. They have zero battery requirements, work well in sunlight, some have beautiful pictures, you can write on them and fold back the corner of a page, and so  on. There are more advantages to ebooks though, in cost, weight, searchability, interactivity, and freedom from the constraints of a printed page. Years ago I was in the book publishing industry, and convinced that ebooks would take off much sooner than in fact they did. Much money was wasted in the light of false dawns. I remember – though it was long after I was involved – how some booksellers invested in Microsoft’s .lit format, readable on PCs and Pocket PCs, only to discover that there was little market for it.

What changed? It was no single thing; but factors include the advent of high-contrast screens that are both low-power and readable outside; the appearance of dedicated tablet-style readers that are lightweight but with book-sized screens; the marketing muscle of Amazon with the Kindle and Apple with the iPad – though the iPad screen is sub-optimal for reading – and some mysterious change in public perception that caused ebooks to transition from niche to mainstream.

Books are not going away of course, just as CDs and even vinyl records are still with us. I think though we can expect more high street closures, and libraries wondering what exactly their role is meant to be, and that the publishing industry is going to struggle with this transition just as the music industry has done. Ebook growth will continue, and as Amazon battles its rivals we will see the price of the Kindle fall further. Apple will lock its community more tightly to iTunes, as its policy on forbidding in-app purchases that do not go through its own App Store and pay the Apple tax plays out.

That is all incidental. What I am struggling to put into words is what the decline of the printed word means for our culture. You can argue that it is merely a symptom of what the internet has brought us, which is true in its way; but it is a particularly tangible symptom. No longer will you be able to go into someone’s room and see clues about their interests and abilities by glancing at bookshelves.

I am on a train, and by one of life’s strange synergies someone has just sat down next to me and pulled out a Kindle.

I do not mean to be negative. Much though I love books, there are now better ways to store and read words, and while the printed word may be in decline, the written word has never been more popular. I am in no doubt though that this is a profound change.

Spotify is now less free but still a better deal than Apple iTunes

Spotify’s Daniel Ek has announced restrictions to Spotify’s free edition:

  • Users will be able to play any track for free up to 5 times only
  • Total listening time for free users will be limited to 10 hours per month

The changes are presented as a necessity:

It’s vital that we continue offering an on-demand free service … but to make that possible we have to put some limits in place going forward.

You can easily escape the restrictions by subscribing to the unlimited service at £4.99 per month (or equivalent in your currency), or the Premium service at £9.99. Unlimited offers music without advertisements, while premium includes mobile and offline music, and a higher bitrate of 320 kbps.

While it is a shame to see free Spotify become less attractive, the free and premium services are well priced. For the cost of one album per month you can play anything on Spotify’s service as often as you like. The main downside is that there are gaps in what is available. Over time, my guess is that either Spotify will win the argument and the business, and those gaps will be filled; or of course it may fail.

Spotify’s problem is that it has to pay even for the music that is streamed for free. That is always a difficult business model, and it seems that advertising is not enough to pay for it at the rates the music companies require.

If the restrictions result in a surge of new paid subscriptions, this may even work out well for the company, though the service is still not available in the USA.

Personally I think Spotify is inherently a better deal than iTunes downloads, for example, which offer an unlimited license but only on a track by track basis and with no resale value. Anyone who still buys music is likely to spend less with Spotify, and to get more choice. The subscription model is the only one that makes sense in the internet era.

At the same time, I can understand why the music companies want to maintain a high price for streamed music. They are playing a high-risk game though, since by making legal music more expensive and adding friction, they make illegal music more attractive.

For example, there is now more incentive for a user to record a favourite track during one of their five free listens, and never pay for it again; or to get the tracks they want from a friend’s ripped CD – both actions that are untraceable.

Escaping Apple: trying to switch away is hard

Mark Wadham posts his Thoughts on switching to Android. Last week he sold his iPhone 4 and switched to an HTC Desire S. I found this interesting, since I have an iPhone 4 and an HTC Desire.

The motive behind Wadham’s switch was to escape Apple’s “over-controlling ways”, rather than immediate dissatisfaction with its products, and there is mild disappointment running through his whole piece:

So in summary, android isn’t really /that/ far off the iPhone. It’s missing the cleanness of the user experience, consistency in the user interface and the glorious wealth of apps, but hopefully that will all come in time. This is a great little phone and I’m happy I made the switch. It’s not as fun to use as an iPhone, and if you’re a real UX freak you should probably stick with the iPhone at least for now, but if you’re someone who likes to tweak and customise and play around with your device android seems much more suited than Apple’s offering.

There is also some irony: HTC’s offering is not as free as he would like.

I would have loved to get rid of HTC Sense and install one of the modded roms like Cyanogen, but that currently isn’t possible due to restrictions HTC has placed on these new handsets …The good news is that, according to the research I’ve done, the root for the Desire S (and the incredible S) isn’t far off.Actually the worst thing about this phone is that it comes with a Facebook app that I can’t remove until it gets rooted.

Still, there is no question that Android is a less tightly controlled platform than iOS. The fact that you can install apps from outside Google’s Android Market is all you need to know.

In usability though, Android falls short. It lacks the obsessive attention to design that characterises Apple’s devices and software; and once you are used to iOS it is particularly hard to switch:

Eventually I got the hang of it, but even now after two days of playing and installing apps and tweaks, the UI still feels counter-intuitive and I have to consciously remember how to do things rather than it being obvious and simple like iOS.

One thing I have noticed since getting these two phones is the impact of Apple’s dock connector. There are countless iPhone/iPod docks and although there is often an option to use a non-Apple device with a mini-jack cable it is not as convenient or elegant. You cannot easily build a generic Android dock because there is no exact equivalent.

Another issue is apps. Once you have purchased a bunch of apps, you can transfer these to another iOS device. If you switch to Android, you have to start again.

There is also iTunes to think about. Let’s say you have got used to iTunes and have your music stored there. While it is possible to transfer non-DRM music to Android or other non-Apple devices, it is not necessarily obvious how to do so; and iTunes itself will only sync to Apple devices. Personally I am not a fan of iTunes; but I can see how it tends to encourage users to stick with Apple.

The bottom line is that escaping Apple requires some determination, once you are hooked into its ecosystem.