Recently I received a note from the company that Fresh Comics had some issues on the Kindle Fire:

Dear Audacious Software,

We have recently evaluated your app’s compatibility with Amazon’s Kindle Fire tablet. This added test process is here to verify that every app available for download on Kindle Fire will provide our customers with a high-quality experience on their devices. Your existing submission of Fresh Comics has compatibility issues with Kindle Fire. We would like to keep your app set to Compatible with Kindle Fire while we wait for you to submit an update that addresses the following issues:

Fresh Comics exhibits consistent, reproducible instances of hard-locking the device, force closing, or crashing when tested for compatibility on Kindle Fire.  When users press the map button on an individual shop’s page, the app force closes.  Steps to reproduce: 1. On the Shops tab, select a shop.  2. Press the map button to see the force close.

A logcat file is attached.

Please review these issues and update your submission to address the incompatibility. You may find it helpful to review the Kindle Fire FAQ in the Amazon Appstore Developer Portal.

To manage your account details, as well as any marketing material updates for your app, please use the Developer Portal. If you have any questions about your app, the Contact Us link in the Developer Portal is the best way to get in touch with us.

We thank you for your continued support of the Amazon Appstore.

Best regards,

Amazon Appstore Account Team

Their note included a stack trace that pinpointed a problem I had missed since I had MapQuest installed on my Fire as the default mapping app. I deleted MapQuest, and replicated the crash as described. A few minutes later, I had a fix submitted to the respective Android app stores.

I bring up this bug report as something I really appreciate as a developer. There are too many app stores out there (who will remain nameless) that treat the app store approval process as a CYA maneuver and only do the cursory testing of apps before accepting them into their marketplace. This note from Amazon demonstrated to me that they do take seriously the quality of apps on their platform and are willing to reach out to developers to address issues like the one identified.

Great job, Amazon!

For new users of Fresh Comics and potential business partners and customers, I wanted to spend a few minutes explaining the Fresh Comics business model and what I’m trying to achieve with the app(s).

If you haven’t already, please head over to the Fresh Comics website to get directions to your favorite app store (iOS & Android). Download the app – it’s free – and give it a spin.

Done? Good.

As you can see, Fresh Comics is a completely free app that lists the week’s latest comic releases as well as provides some nice features for enthusiasts looking to stay abreast of their favorite creators, titles, and publishers. This functionality is all free and I have no plans to start charging for any of that.

However, in its current incarnation, Fresh Comics is missing a vital component – the store finder. This is a feature that is implemented, but won’t be available until either I can license a database of US comic book stores or build one myself. I’m currently talking to some groups about licensing theirs, and I’m confident that this feature will see the light of day soon.

In anticipation of that, I wanted to provide a brief explanation of the store finder feature as this will be how it will support the app financially.

My goal for this feature is to create a win-win situation for comic shop owners and comic book enthusiasts. When the store locator is pushed out, it will look like the screenshot below:

In short, the store locator is a two-tiered list. The bottom group consists of all of the stores in the local area, sorted by distance from the user’s current location. The design goal behind this is to enable motivated customers (comic readers who want the latest releases now) to find a suitable shop close to them. I have no plans to charge comic shop owners to be listed in this section.

The top group – “Special Offers & Deals” – is where Fresh Comics pays its bills. How this works is simple – if you’re a local comic shop running a special promotion or sale, you can use Fresh Comics as a channel to get the word out. Your store listing will be bumped up from the free “Nearby Stores” section into the premium “Special Offers & Deals” section that the user will see first. This listing in Fresh Comics will cost a flat rate per day.

If a user clicks through to a store listing in either group, the app displays a page with information about the store:

What I want to present here is the name of the store, any relevant contact information, and an image of the storefront to help customers find and visit the store. This also includes hours of operation.

If the user clicks the button in the upper-right of the interface, the app presents several options to connect with the store:

Depending upon the contact information available, this feature will present the customer options to view the store’s website, view it in the local Maps application (with driving directions), call the store directly (on compatible devices), or to send an e-mail. The more options that a store provides for customer contact, the higher the odds of finding the mode that the customer prefers.

Again, this functionality is provided to all stores for no cost.

For the stores that are running a paid promotion, their spot in the store list changes, as well as including a badge on their store page:

If the customer clicks the badge, they will see the coupon on their device:

The terms of the deal are completely under the store’s control, and an optional coupon code can be added so that the store can track the effectiveness of the promotion at purchase time.

So, that’s the current missing functionality. It’s implemented and is working – I’m waiting to complete the process of acquiring or building a database of the stores to populate this section.

In terms of the advertising rates, currently I’m planning to launch this feature with basic text-based promotions for a rate of $1 per day that your promotion is available to local users within the app. This is sufficient for me to meet my financial goals, and I think it’s a very reasonable rate to reach a group of savvy and motivated customers every week.

If you’re a comic store owner and would like me to contact you when this launches, please send an e-mail to shops@freshcomics.us and I’ll be happy to send out an ad kit when this feature is ready. If you have any thoughts on how I can improve the utility of this feature to send more customers your way, I’m very open to suggestions.

As a lifelong comic fan myself, I’m very excited to be in a position to help fellow readers keep up with the latest releases as well as creatively use mobile and networked technology to improve the prospects of the local comic shop.

What’s the difference in adoption between the free lite version and the paid full version?

As of this moment, the most relevant version of the paid app (at the $0.99 price) has been on the market since Dec. 24 and in that time, it’s gathered about 20 purchases since that date. (Approx. 30 day time period.) Of those installs, about a third remain active on the devices.

The lite version of the app has been available since Jan. 10 and has gathered almost 400 downloads since that date. (Approx. 10 day time period.) Of those installs, about half of the installs remain active on devices.

I’m not surprised about the order of magnitude differences in download. However, I am surprised that the active install rate for the free version (50%) is higher than the rate for the paid version (32%). This suggests to me that users of the free versions are more satisfied with their app than the paid users, which is the opposite of what I predicted.

Has the free version been an effective advertisement for the paid version?

Absolutely not.

Prior to the introduction of the free version, the paid version of the app was being purchased once about every day or two. Since the introduction of the free version, only a single copy has sold in the last ten days. This suggests to me that the free version is a sufficient substitute for the paid version and is capturing the customers that would have paid for the full version in the absence of the free version.

While I initially found this disconcerting, the results mirror the phenomenon obtained by Dan Ariely in his “free Hershey Kisses” experiments:

“Free” is kind of an incredibly tempting human hot button. And sometimes it’s great and sometimes it gets us into trouble. I’ll describe to you quickly the experiments we do. So in the experiments we do, we say “Okay what do you want, the Lindt Truffle for fourteen cents or Hershey Kiss for one penny?” Almost everybody says “Thirteen more cents for a better chocolate is a good deal because it could only take one of the other.” Everybody understands the value of the Lindt is high. Then we discount them both by one penny. Now, the difference and the qualities are the same – difference in price is the same – but now everybody goes to the free Hershey Kiss.

Given that I enjoyed Ariely’s book some months back, there’s really no excuse for me forgetting to account for this in my own outcome predictions.

One alternative explanation for the results I’ve obtained is that people just don’t like the app and the chance to try it for free warns them away from the free version. I’m not ready to accept that explanation yet, because both apps are rated quite favorably (4 stars for the free version, 5 stars for the paid version).

What are the key lessons here?

If this were a money-optimizing endeavor rather than a brief experiment in consumer behavior and price sensitivity, the introduction of the free version of the app would have been the end of the commercial enterprise. Common sense dictates that a limited free app would give consumers a chance to experience the app and a handful of customers who wanted more control would spend the meager $0.99 to upgrade to the full version of the app. This didn’t happen – the free version absolutely killed all demand for the paid version.

When I get some more time, I am planning on a follow-up to this experiment. Since I cannot add a price to the free version of the app and continue the experiment, the Wall of Life is effectively done for now. I’ll keep it up on the Market to see if anything interesting happens, but I’m not expecting too much.

However, I have an idea for an entirely new live wallpaper and I’m looking forward to replicating Ariely’s other results – customers flocking to the more expensive truffle when the Hershey Kiss costs a cent. In this new experiment, the role of the Hershey’s Kiss will be played by a $0.99 lite app, and the truffle will be the full version priced at various points above the lite version to find the position that maximizes income. With any luck, I’ll have the time to start writing the new app in a few months and the experiments may continue as early as April.

Stay tuned.

There are already two apps that implement this functionality on the App Store: PullList and Pocket Comic. (I discuss these apps in more detail on my original Fresh Comics blog post.) When I decided to put together Fresh Comics, one of the deficiencies that I wanted to address in the existing apps was the ability to use the app when limited network connectivity is available. Since I usually look up what’s new when I’m in transit on the subway, this seemed like a reasonable feature to add.

Since Apple’s App Store approval process is not sufficiently predictable and responsive that I can bundle the comic data with the app and release updates each Monday, the app needs to download the latest data from an online server and use that copy. This data consists of two main items: an RDF metadata file that encodes the creators, title, and other information about the week’s comic books and the associated cover files. Depending upon the quantity and quality of the cover images, a weekly download may be as much as fifteen megabytes in size.

In my ideal implementation, when the user launches the app, all of the covers and metadata will be there from the beginning, and there will never be any indication that the app is missing data. To the user, the app should always appear to have a full set of the week’s latest data and covers. Using ASIHTTPFRequest, I have achieved this once all of the data has been downloaded the first time. The problem is that initial weekly download.

From a responsiveness point of view, the app has no problems downloading the comic metadata file. It’s a simple XML file that compresses well and loads almost immediately on download. The problem is the cover images. Since the app includes a full-screen cover viewer, I would like to have images that are the same size as the iPhone’s native resolutions: 320×480 or 640×960. Individual JPEG images of these sizes can be more than a hundred kilobytes in size, and a typical week may have as many as one hundred fifty new comics with covers. The total download size for this week’s collection weighed in at twelve megabytes.

In the age of WiFi and 3G, twelve megabytes isn’t an excessive size, so I have no qualms allowing the user to download the data using their broadband or cellular connection. However, the download process can some time (depending on the connection), which is where the challenge lies.

In the current builds of Fresh Comics, on a fresh download, I’ve implemented a progressive display scheme that does the following:

1. It fetches the week’s textual metadata and displays that information as soon as possible in the app. Until the cover images are available locally, the covers are shown using a placeholder image.
2. The app keeps a queue of pending cover downloads. For the rows that are visible, the app downloads those thumbnails in the background first. As the thumbnails download, the display updates to reflect the new data.
3. After the thumbnails are downloaded, the app begins downloading the full resolution cover images.

Since the goal of the app is to get the information into users’ hands as soon as possible, Fresh Comics has hierarchy of information priority: textual metadata (titles, creators, etc.), thumbnail images, and finally, full cover images. Using this approach, I’m satisfied with the results I’ve achieved on devices ranging from the earliest iPhones to the latest iPod Touches. The solution works as well as the platform permits and it degrades gracefully as connectivity becomes limited. While I’m proud of my solution, I am quite annoyed that it was necessary in the first place. Since “downloading content for later offline use” is not one of Apple’s seven permitted background tasks, there’s not too much else that I can do to improve the situation.

In contrast, on the Android and Symbian platforms, the solution is simple and straightforward. On Android, I create a system service that wakes up every 24 hours to see of there’s something new and download the updates in the middle of the night. On Symbian, it’s easy to hide the app’s user interface and implement a similar background data check. Implemented properly, neither of these approaches will have any noticeable impact on the device’s performance and battery life.

While I’ve had a mostly positive experience putting together Fresh Comics for the iPhone, Apple’s limitations on background processing results in a suboptimal product for iOS devices when compared to competing platforms. (The Android version will be out soon.) I remain more positive about Android than iOS precisely for reasons such as this. While Android is not as polished (out of the box) in terms of its native controls and look-and-feel, it’s a much more expressive environment than iOS. iOS is a very nice platform for many apps, but once you try to write a proper networked ubiquitous app, it’s limitations become apparent.

Apple’s iOS decisions place it firmly in the “direct manipulation” camp in the direct manipulation vs. software agent debate. However, as long as processing power and network availability remain limited and unpredictable on mobile devices, there will be a need for applications to implement some autonomous functionality to respond to these limitations in order to provide the best experience possible. That I hit this wall writing a simple new comic releases app is somewhat disconcerting. I wonder how many iOS apps remain stunted because of the lack of proper background processing. There’s a solution to this problem, but Apple’s continual refusal to allow iOS programmers true multitasking makes iOS a more limited platform in terms of what is possible on mobile devices.

This post shares some the results thus far.

Pricing

In late October, I released the app on the Android Market for a price of $2.99. I kept that price until late December and “shipped” nine (9) copies of the wallpaper. Four (4) of those shipped copies were refunded within the Market’s refund window, netting a grand total of five (5) sales between Oct. 21 and Dec. 22. (Please keep in mind, I have not marketed this app in any meaningful way outside the Market, so these numbers should be interpreted as baseline performance figures.)

Around or on Christmas (Dec. 25), I updated the application in the Android Market and slashed the price to $0.99. In the last two weeks, I’ve had eighteen (18) total downloads, seven (7) refunds, yielding a net gain of eleven (11) copies successfully sold. If this trend persists, I’m on track to make more money at the $0.99 price in three weeks than I managed in two months. Lesson learned: small changes in price can lead to an order of magnitude more downloads. This isn’t unexpected, but it’s nice to have some numbers to quantify the difference.

The Wall of Life  - Lite

Last week – after the price drop – I received a request via e-mail to make a free version of the live wallpaper. The requester explained that she was in a tough financial situation and would appreciate more free apps (who wouldn’t?). I didn’t know how to interpret this message – was the writer someone truly down on her luck, or was this a scam to get a free app? I didn’t know.

Since the Wall of Life is more a petri dish for me than a revenue generator, I played along. This last weekend, I created a “lite” version of the wallpaper and listed it on the Market for free. The “lite” edition differs from the full version in that I removed all the configuration options, save for the options to change the cells’ color and shape. I removed the options for setting the interval between generations, the size of the cells, and the option to keep the field stationary (as opposed to the visual illusion of “flying” over the grid as you swipe between screens).

I listed the app on the Market shortly after it was finished and waited for the market results. For reasons unknown to me, the download count in the Market’s developer console remained stuck at zero for several days. Then, this morning, I finally received the results that I was awaiting.

The paid version of the Wall of Life currently sits at 26 (lifetime) downloads, with 10 users currently using it (38%).  The free version is registering 225 downloads, with 162 users currently using it (72%). So, in two days, the free version has almost 9 times the number of downloads that took the paid version more than 2 months to reach. Again, this isn’t an unexpected result, but it’s nice to have some data to back up the intuition. I would explain the difference in the number of active installs as an artifact of how new the wallpaper is. As time elapses, I expect this number to regress around the 38% of the paid app.

An unanswered question that I still have is the effect of the “lite” version as an instrument to up-sell users to the full version. Since I don’t have a lot of data on the free version yet, it’ll probably be several weeks until I can do a proper statistical analysis to see if there’s a significant effect there. An interrupted time series analysis should be quite useful in this particular case (paid downloads before the introduction of the free version vs. paid downloads afterward).

(In)conclusion

Other than what the numbers currently show, I don’t have any deeper conclusions or insights to draw at this moment. Apps “sell” better as prices fall, which is common sense. I’m interested in seeing if the “lite” version improves or worsens the money made by the paid version, but that post will have to wait for a few more weeks while I collect data.

What about marketing? Since this particular app is a fairly niche bit of software that appeals to a small subset of users, I don’t expect that I’ll expend too much effort on getting the word out. As it stands now, it’s a useful tool to simply have online to get a sense of the baseline Android Market performance and I’ll probably keep it like that. If there’s an argument made to do otherwise, I’m happy to listen. Unfortunately, I think that “Life” is probably a bit too niche to draw any useful conclusions about the efficacy of various marketing strategies.

However, I do have another app coming soon that will be listed on both the Android and iPhone markets. This app will have a wider appeal, so in addition to the cross-app store comparisons, I hope that it will shed some light on concrete Marketing strategies to improve download numbers and sales.

Stay tuned.

Still, given that I’ll be speaking next month on the topic of App Stores, I thought that I should probably have something up on at least one app store, so I spent a couple of hours yesterday and today putting together a small app for the Android Marketplace.

When I first began to run Android 2.1 (Eclair) on my Motorola Droid, I was interested in the potential of the live wallpapers and not too impressed with the initial shipping batch. I thought that it would be great if I could implement John Conway’s “Game of Life” as a wallpaper and check in on my mini-world from time to time. While a couple of developers beat me to the punch (1, 2), I figured that the exercise would still be worthwhile and went ahead and created “The Wall of Life”.

In terms of development, there were three main phases:

1. Implement the basic Canvas-based drawing system.

2. Implement the Life model.

3. Implement the settings panel.

Each phase took me approximately 2 hours, and I didn’t run into any major potholes. The only significant issue that I had to deal with was porting my initial class-based naive model (grossly inefficient) to a primitive-based model (much quicker). Given that I could read the debug logs from the phone directly, this optimization problem was solved much faster than similar situations on other mobile platforms. After the basic wallpaper was complete, I tested it on a variety of Android devices to check that I didn’t have any stray assumptions about specific devices. The wallpaper ran well on both the Motorola Charm and HTC G2. Success!

After I polished the app a bit more, I set up an Android Market seller account for Audacious Software. From start to finish, it probably took me less than thirty minutes to get established. After the account was set up, I uploaded the app and posted a Facebook note to friends and family.

I tried downloading the app myself, but I ran into a server error on Google’s end. While I don’t exactly know what’s going on, I suspect that the issue may be that the seller can’t purchase their own app. I’m hoping that one of my Facebook buddies can download the app and confirm that the issue’s specific to me. (Hint, hint…)

While testing the build that I uploaded to the Market, I did find serious issue and was able to upload an update rather quickly. Fortunately, no one had purchased the wallpaper, so there are no potential angry customers. In terms of patching efficiency, the Google system beats Apple’s approval-laden process silly.

In the end, I am very impressed with how easy Google makes it for developers to get their apps up and running on their Market. Of the major mobile platform vendors, I’m most impressed by Google’s end-to-end setup. The Android Eclipse integration works well, apps are extremely easy to debug on the devices, and I didn’t have to deal with any signing headaches to get my app up and listed. The weakest point of the Google ecosystem is their feeble market app, but I expect that I have to do the bulk of my marketing in any case.

My one complaint with Google is that they don’t have a robust web presence for the apps in the Market, and this makes marketing to desktop users a bit more difficult. However, third parties have stepped up and my wallpaper is already visible at Android Zoom. I hope that Google eventually beefs up their web-based Market presence in the same way that potential customers can now find AppStore content.

I don’t have any major plans or expectations for this small app. I wrote it for myself, and I’m using it as a small experimental portal into the Android Marketplace. At the moment, I’m interested to look into app pricing on the Android Market. My two competitors are both less than a dollar, while my wallpaper is $3.00USD. I’ll be curious to see if anyone bites at that price. If I don’t attract many customers at that price (with some proper marketing on my end), I’ll drop the price to attract customers and go from there.

So, in summary – it’s absurdly easy to get started selling Android apps. The development toolchain is top-notch, and Google has done a great job lowering the barriers to getting listed in their app store. While the web and native Market presences are somewhat underwhelming, I’m curious to see how much demand I can create marketing outside the Market. I had a great time with this little project and look forward to following up with some interesting results from my tinkering.

As a software developer trying to support myself in the mobile ecosystem, platform statistics are invaluable when it comes to making informed decisions about where to spend my attention and resources. Unfortunately, in the race to become the top mobile platform, Nokia, Apple, and Google have not been helpful when describing their respective ecosystems.

Apple likes to brag about the total amount paid out to developers, while neglecting to share the actual statistical distribution of those payments. Google highlights the number of devices being activated, but downplays the lack of purchase options internationally. Nokia highlights the total number of downloads from the Ovi Store, but declines to share any meaningful revenue details.

In the short story “Silver Blaze”, Sir Arthur Conan Doyle penned the following exchange between Sherlock Holmes and a Scotland Yard detective:

Gregory: Is there any other point to which you would wish to draw my attention?

Holmes: To the curious incident of the dog in the night-time.

Gregory: The dog did nothing in the night-time.

Holmes: That was the curious incident.

From my perch as an independent developer, the statistics that platform vendors withhold reveal more to me than the large numbers in their keynote slides. Aggregate developer profits mean little if the payouts follow a power-law distribution where a small minority receives the vast majority of the sales. A large quantity of compatible devices is irrelevant if users cannot buy apps. Not sharing the most basic financial details suggests to me that the app store is underperforming. I understand the platform vendors’ motivation in withholding these details, but as someone in the process of building a mobile software business, the lack of meaningful statistics makes me wonder if these ecosystems are as lucrative as vendors claim.

While drafting this post, I debated whether I was too pessimistic about the prospects of app store models and wondered if my extrapolations went too far. Seeking independent corroboration, I looked for anyone who approached this question using a rigorous approach and found VisionMobile’s 2010 report on the state of the mobile software economy. Their conclusions supported what I already suspected:

Our survey found the number one issue for mobile developers to be the lack of effective marketing channels to increase application exposure, discovery and therefore customer acquisition… Developers reported persistent challenges with getting traffic, customer visibility or in short ‘being seen’. One developer put it succinctly: ‘It’s like going to a record store with 200,000 CDs. You’ll only look at the top-10.’ (p. 24)

The dubious long-tail economics are reinforced by our findings on developer revenue expectations. Only five percent of the respondents reported very good revenues, above their expectations, while 24 percent said their revenues were poor. (p. 26)

Combined with the lack of financial transparency from the app store operators, these findings suggest that I would be foolish to build a business solely dependent upon these markets. Combined with degraded customer relationships created by generic billing systems (a topic for another post), I am not comfortable building my business by relying on payments from the Nokia, Google, or Apple app stores. Their goal is to maximize aggregate market performance, which does not always align with an independent developer’s own goals. While Apple demonstrated how app stores can become a profit center for the platform vendor, it failed to demonstrate that the market can be a reliable profit center for the independent developer. For every Ravensoft, Tapulous, or Car Locator, how many others struggle to make ends meet?

While I believe that app stores are a dangerous environment for building healthy businesses, I wouldn’t be writing mobile software if I didn’t think there were plenty of opportunities available. In my upcoming presentation at SEE 2010, I will share how my company avoids the pitfalls of the modern app stores to sustainably build compelling systems for our customers. I hope to see you there.

1. As described in an earlier post, I cancelled my iPhone subscription in exchange for the T-Mobile G2. In the past week of using the device, I’ve been exceptionally pleased with it, so from my perspective, we can call the G2 an iPhone killer. I’ve been very happy with the apps on it and have begun leaving my laptop in the office when I head home. The G2 works just fine for keeping up with e-mail and the other tasks that don’t require a lot of work.

2. One of the apps that I lost in the transition was Shion Touch, the iPhone app for the online service I’m building. I am happy to report that I have acutely felt its absence on the Android device, and can’t wait to have mature version running on the G2. While it’s annoying that I can’t tweak with my house or office from my phone anymore, this is a good sign as it demonstrates that the technology noticeably contributed to my daily life in a positive way. I’ve lost count of the number of things I’ve built that I thought were great ideas, but ultimately abandoned as they were not sufficiently compelling to continue using over the long term. It’s nice to have some proof (however minor) that Shion isn’t one of those.

3. Given my upcoming talk at the Symbian conference next month, I picked up a Nokia N8 to see how the platform has progressed since my work with the XpressMusic 5800s. Two thumbs up to the following:

• Hardware design: This is an elegant phone packaged in a robust exterior. It feels nice to hold, but I won’t worry about it in my pocket.
• Capacitive touchscreen: The new finger-friendly touchscreen makes the device much simpler to use overall. The device feels much more responsive when I don’t have to fumble around with a stylus.
• Growing app support: I was especially pleased to see Bloomberg and Angry Birds on the platform. Still notably missing: Audible & Kindle support.
• iSync support: It’s nice to see a modern device that still supports this largely-neglected application. I was able to transfer my contacts & calendars with no problem.
• E-Mail: Nokia fixed a bug in the mail client that finally let this phone connect to my Audacious Software IMAP account.
• Widgets: It’s nice that they are here. I missed those on the XM5800.

I was less than pleased with these things:

• Windows XP support: I have plenty of experience getting Nokia phones to talk to Windows XP, but I was unable to get this device to talk to the Ovi Suite. The error appears to be a driver issue where Windows is unable to start “N8-00 USB Phone Parent”. To be fair, I was installing this on an VMWare virtual machine, but I’ve never had any similar issues in the past. If I can’t get the phone to talk to Windows, how am I going to develop and test apps on it using Qt Creator?
• Inconsistent UI language: Among Nokia’s own apps on this device, there is a large amount of variability in the overall software design and little to no consistency. Some apps use the softkey buttons to exit applications, while others hide the exit in a popup menu. The Ovi Store app looks nothing like anything else on the system. The Maps app looks sharp, but again does its own thing. While some of this may be me nitpicking, I had to explore within the apps to accomplish simple things like exiting an application.
• The Social app would fail with an error about a gateway timeout. (Not the most helpful message.) This wouldn’t be a problem, except that I couldn’t find a suitable replacement in the Ovi Store. (I seem to remember an official Symbian Facebook app.) The app eventually started working, but I don’t understand why Nokia thinks it’s necessary to inject Ovi between me and these social services. I’d rather have apps from the services directly than deal with a unreliable middleman.
• The message view in the mail client looks like it was designed by a junior high intern. The default font is way too large and the icons are quite distorted or out of place visually. (The rest of the mail client is fine.)

Overall, I have a positive impression of the N8. Nothing I’ve highlighted can’t be fixed in a future update, and it’s clear that Nokia has learned something from the competition and is (steadily) improving their devices. Given my limited experience with this phone, I would say that it is a device on par with something like the T-Mobile MyTouch Slide in terms of the user experience.

I hope that Nokia brings the price down to something more competitive with the Slide, as its current $550 USD list price places it more in line with the Samsung Galaxy phones ($499 on T-Mobile), which are superior devices. Nokia needs to price the N8 down around $350 USD if the N8 is to compete with the Android devices. (All prices quoted for unlocked phones.)

Since the phone is compatible with my T-Mobile SIM card, I’ll be spending more time with the device over the next couple of weeks. If I can figure out how to get the phone to talk to Windows XP, I may pull out some of my older QXmpp code and see about putting together an app for SEE2010.

• (Originally) No support for Kindle or Audible electronic books.
• A manufacturing defect with the headphone jack led to audio issues after a month or two of use.
• The Android 2.2 Froyo update slowed the Droid considerably.

While the application support issue (Kindle & Audible) resolved itself in due time, I didn’t make the transition from the Droid to another Android phone (until the G2) for two major reasons:

• I strongly prefer vanilla Android to any of the customized versions provided by the various manufacturers and carriers. The Audacious Software Android test lab has MotoBlur, HTC Sense, and Samsung Touchwiz devices, but I never warmed to these interfaces the same way I enjoyed the stock Android UI & widgets.
• I really like the slide-out keyboard form factor, and the bulk of 2010 Android form factors released were either slabs or similar to the Blackberry (e.g. Motorola Charm). I like having a slab form factor available most of the time, but prefer to work with a keyboard when it becomes necessary to do text-heavy work like system administration or writing.

When the details about the G2 emerged, I became extremely interested, as it seemed that the Android ecosystem had finally produced a suitable successor to my original Droid. The only thing to dampen my enthusiasm was the announcement that T-Mobile would be disabling the tethering functionality of the G2. While I was hoping that the G2 would replace 3 devices (iPhone, Droid, and Palm Pre), this tweak to the Android firmware made it necessary for me to retain the Pre as my mobile hotspot.

Despite the lack of tethering, I purchased the device from my neighborhood T-Mobile store. I set up the device on my way to the office, and spent a good part of the evening transferring music from iTunes to the device. (I swapped out the default 8GB SD card with the 16 GB card that shipped with the Droid.) While I’m still getting used to walking around with just one device, I’ve been enjoying the new phone immensely.

Since I don’t intend to draft a full review of the device, you’ll have to look elsewhere for the details of the device. I really enjoy the phone, and look forward to using it for quite some time. However, I do want to highlight the other side of the switching equation: where Apple & AT&T lost me.

Apple: The iPhone is a revolutionary device that reset users’ expectations for mobile phones and personal portable computers. While Apple made a major leap in 2007, the iPhone platform’s progress has been much more sluggish since then. While the iPhone gradually improved over the last 4 iterations, those improvements pale in comparison to the evolution of the Android platform. Personally, I prefer the intra-party competition of the Android ecosystem driving platform development more than Apple’s planned yearly obsolescence. Apple had a chance to change course in iPhone OS 4, but failed when they punted on true background multiprocessing for third-party apps. I have some very specific app ideas that I’d like to implement, but Apple’s platform remains too limited to do so. Android doesn’t present this problem.

iPad & Apps: Despite my waning enthusiasm for the iPhone platform, I really enjoy using the iPad. As I mentioned above, there were a handful of must-have applications in early 2010 that prevented me from migrating from the iPhone to the Droid. Some of this problem was solved when Android equivalents became available, and the rest was resolved when my must-have iPhone apps migrated to the iPad. In particular, I really liked the Comixology application on the iPhone, but ceased using it when it went to the iPad. Netflix on the iPhone would be a strong motivator to stick with the platform – if there was not a better version on the iPad. Given that the iPad took over most of my mobile entertainment & web browsing usage, the iPhone became much less attractive when those features became less important

AT&T: The largest contributor of me leaving the iPhone platform is AT&T. As others have complained, the “phone” part of the iPhone is extremely unreliable. (This is why I carried around the Droid for the last year.) However, the straw that “broke the camels’ back” was their phone locking policy. While it is 100% legal for consumers to unlock their phones for use with other carriers, there are not legal provisions that compel a carrier to unlock a device on customer request. Since Apple will not unlock a phone without permission from the local carrier, AT&T enjoys de-facto control over every iPhone that Apple sells in the United States.

I am sympathetic to the desire to lock phones and the necessity of recouping the costs of phone subsidies with contracts. However, my understanding dissipates when it comes to phones no longer on contract or even in use. From my perspective, there is no valid reason that I should not be able to use an unsubsidized iPhone on another network. In my role as a mobile developer, I need to cycle through phones for extended periods of time to robustly test the systems I am building. If I need to spend some more time with Shion Touch on the iPhone, I should be able to swap in my SIM card (acknowledging that I will only be able to get EDGE speeds due to hardware limitations), and use the iPhone for a few days. My mobile number should come with me. It shouldn’t be a big deal. Instead, my choices are either to pay for an AT&T account for testing purposes or jailbreak the device. Yuck.

While the iPhone will cease being my main mobile phone, the iOS platform will continue to be one of the main platforms that the company supports. While the iPhone is no longer the right fit for my needs, there are still plenty of customers and clients on the platform (such as my wife) and it’s still a good platform for particular kinds of applications. I’m currently talking to my European friends about the best way to acquire an unlocked iPhone that I can use with my existing SIM card, so I will still be able to give my apps a decent workout “in the wild”.

In the end, I’m pretty satisfied with how things have turned out. Over the past year, the cost of running Audacious Software has been inching up as I’ve invested in more mobile platforms and the networks to support them. I’ve been very impressed with T-Mobile’s overall customer service and developer-friendliness and I look forward to consolidating as much as possible under their plans. The new G2 alone will replace 2 devices with 2 plans, resulting in some significant savings in the next several months. The phone itself has been a joy to use (for all of a day) and I look forward to further tweaking it to make it an indispensable part of my personal and professional life.