I can’t express how much fun I had with Mat & Sean (& Red Bull energy drink) making this app.

The only excuse that I can offer for the delay for making this news public (months later) is that I’ve been extremely busy and it’s only been recently that I’ve had the mental oxygen to begin writing again. Here are some of the projects that have been keeping me away from blogging:

Power2Switch: While I resigned my CTO position at the company in October, the company remains a very active client to this day. In last couple of months, I’ve helped them improve the Django infrastructure I created over the summer and the company is now serving customers in a more markets than ever before. We’ve increasingly automated the backend, allowing Power2Switch to more responsively serve more customers while it extends its offerings into additional markets and states.

Meeps: In October, I began working with an old friend on a new product he was building in Boulder. The result is Meeps, an iOS application for topical conversations with anyone in the world. Working with the Meeps team, I had a blast pushing the envelope of iOS development to implement their vision for group conversations. iOS users: Get it from the App Store now.

Fresh Comics: Windows Phone 7 became the next major platform for Fresh Comics with an initial release of the app on the Windows Phone Marketplace back in January. The Windows Phone launch was the most successful thus far, and the WP7 application remains under active development along with its iOS and Android siblings. WP7 users: Get it from the Windows Phone Marketplace.

Research clients: Over the past several months, I have helped researchers create tools for understanding language on Twitter and I built an experimental workbench for survey researchers. The beginning of this year saw a major revision to the SMS Bot text messaging system as it is now being deployed in medical contexts to better understand how patients recover after surgeries and other major operations.

2012 is shaping up to be a promising year as the external work pipeline fills up and I plan ahead for developing more internal products. I’ll do my best to avoid another long hiatus and get back to updating this space with useful content as time permits.

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.

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.

However, for a company that purports to be a mobile developer on the major platforms, it’s been somewhat embarrassing that a search for “Audacious Software” on Apple’s App Store currently returns zero hits. While I’ve written a tremendous amount of iOS code in the last year, the only way to demonstrate that to potential clients is to enroll them in one of several beta tests underway. This is clearly not an optimal strategy, and I decided to fix that in the waning days of 2010.

The App

I always have several app ideas floating around in my head, so the challenge was to select one that I could get out the door with minimal hassle and prerequisites. Shion Touch is a poor candidate, as I haven’t launched its online service yet. Task Views was disqualified because I’m still working on the “researchy” elements (how to represent a task space in a variety of tactilely-accessible manners that isn’t a linear list) and I’m not ready to push those nascent ideas onto the wider app-reviewing public.

In the end, I selected a small idea that’s been on my mind for the last couple of months: a mobile app that helps me manage my weekly comic book runs. As an avid collector of these items, it’s customary for me to make a Wednesday run to the local comic book store to pick up any new issues released that week. To keep abreast of what’s arriving, I’ve traditionally relied on Googling “graham cracker new this week” to find a new listing page from my comic store. Since I tend to do this while travelling on the bus or train, the bulk of these accesses have been from a mobile device.

Now, Graham Crackers maintains a great page that works fine in most mobile browsers (no Flash or crazy Javascript), but I’ve always felt that the experience was suboptimal. First, I need a network connection. Not a problem, except when I’m in the subway or a building that blocks wireless signals. Second, getting to the content I want is a kabuki dance of scrolling, pinching, and zooming to enlarge links of interest enough that I can reliably click them. Third, I have to repeat this process for each item of interest: click the link, pinch and zoom the contents to an acceptable state, read the content, click back to the list, rinse & repeat. Finally, one of the neatest things about comics is the artwork. In a mobile web presentation, it’s sufficiently annoying to situate the cover image in a browser that I tend ignore it.

So, with these issues in hand, I resolved to create a more optimal experience browsing new comics with my app. The app must support offline access, it should make the lists and metadata accessible in an effective manner, and it should make it fun to appreciate the cover art. I included the additional requirement that it should remember what I like so that it can also serve as a both a recommender (“You noted that you like Chris Bachalo as an illustrator – here’s an issue that he’s drawing for another publisher.”) and a shopping list (“You’ve liked X-Factor in the past – there’s a new issue this week.”).

The Competition

While I would like to say that I did my due diligence and researched any possible competition before writing a line of code, the truth is that I was well into the app before looking for any similar available apps. However, for the sake of the exercise, let’s assume that I did.

After a lengthy review of the App Store, I found two competitors: PullList and Pocket Comic.

PullList is an app by comixology that hooks into their backend and allows users to see what’s coming out. There’s an overwhelming amount of functionality available from podcasts to commentary to previews. As an initial user wanting a simple experience, the app is overwhelming in its scope and complexity, and not in a good way. A downside of using comixology’s online infrastructure is that the pull list (comic geek speak for “weekly shopping list”) requires signing up for an online account, which is more hassle than I’m willing to deal with.

Another beef with PullList is the inconsistent aesthetics found within the app. The initial interface is visually distinct list, but diving into a level or two reveals a standard iOS table-driven app. In the item list, the developers made the unfortunate decision of including the (often incomplete) textual descriptions in the summary view instead of more relevant metadata like price and creators.

Clicking through to the item details reveals yet another display style where the information isn’t presented as effectively as it could be. In some entries, there are occasional data errors such as a price being “$PI”. Add to the mix that non-comic entries are included in the lists (such as “Settlers of Catan” game expansions), PullList is one of those apps that would drive me nuts. It’s too complex, the design is inconsistent, and the additional complexity makes it very unstable and crashy. Given that the app doesn’t have the most positive update history (frequency & quality – see the App Store reviews), this isn’t the most confidence-inspiring app on the store.

Pocket Comic is a similar app that is much simpler than PullList. It provides a simple list of items available in stores with a feature to pull commentary from Comiclist.com and keep a list of saved comics on the device. Pocket Comic avoids most of the complexity problems of PullList and would be my choice between the two.

My main criticisms of Pocket Comic are aesthetic. First of all, I’m not a big fan of their ad placement, but I recognize that this may be a necessary evil. (A paid version exists without the ads, which is a Good Thing.) As situated now, it’s too easy to accidentally click the ad and get pulled out of the app while trying to scroll a lengthy list.

In the comic lists, the app just shows the title and cover, leaving a lot of unused whitespace. The issue detail view is poorly organized and requires too much scrolling to get to information of interest. Finally, while this app will look fine on older iPhones & iPod Touches, the pixellated graphics on the newer high-res devices detracts from an otherwise solid app.

Overall, I think that Pocket Comic is a good effort at solving the “new comics list” problem and with a few refinements, would have made my work a waste of time and effort. However, since the last update was in September 2009, I don’t know if this app’s creator is still paying any attention to it.

In the end, given PullList’s multitude of issues, and Pocket Comic’s lack of updates, I think that there’s room in the market for another app of this type. These examples show that there’s at least a small market for these kinds of apps (PullList: 527 ratings, Pocket Comic: 40 ratings – estimate an order of magnitude more total users who haven’t taken the time to rate the apps?).

Building A New App

Given that none of the apps on the store really met my criteria for what I wanted in a “new comics this week” app, I went ahead and implemented my own in roughly two days. This was a straightforward exercise in iPhone app programming, and everything fell into place rather well. (If anyone’s interested in the details of the implementation process, please post a comment in the questions.) Since the app is mostly independent of any other systems, it was easy to build quickly.

Here are some screenshots from the results.

As you can see, I favored the same general list user interface that the other apps use as well. I thought about implementing an alternative gallery interface for when the device is landscape orientation, but this feature has been pushed off to a future release. The cover image and title are both visible, and I tried to include other metadata about the primary creators, publisher, and price as well.

By default the list is split into sections grouped by publisher. By clicking on the button in the upper-right, the user can select a different grouping criterion.

When the user selects an entry, the app brings up a details view. This view shows the full metadata for the record in a space-efficient and unobtrusive manner, including a clickable cover thumbnail that displays the full image. The display scrolls smoothly, revealing an “actions” button at the bottom of the view. This button will eventually hold actions applicable for a given record such as e-mailing it to a friend.

If the user taps the star button in upper-right, the “favorite things” interface appears. Using this list, the user can select attributes of the issue that they like. These attributes are then used to select new issues for inclusion in the favorites list. For example, if the user selects “Ant Man & the Wasp” as a favorite series, new issues of this series will automatically appear as soon as released. Rather than limit the user to using series as the sole criterion, I also extended it to creators and publisher. If you want to know about all new issues illustrated by David Finch, you can do so by selecting that in one of your favorite issues.

The “last week” list and favorites list function almost identically to the main “This Week” list. The settings section provides the user some options to manually clear any cached data, refresh the comic sources, and to send feedback about any issues encountered or suggestions to offer.

So, that’s about all there is to the app in its current state. I still have about half a day’s work ahead of me to finish implementing some minor features and polishing the wording of a few strings in the program. My major task now is to approach a designer for an application icon and talk to one of my artist friends about making an interesting launch graphic. After that, the app will be ready to list in the App Store. Not a bad result for 2-3 days worth of programming.

Selecting a Business Model

Since the app is largely complete, the next challenge is to select a suitable business model. Unfortunately, this is not a “fire and forget” kind of app. All of the metadata and screenshots must be collected and packaged for the app’s consumption. Diamond Comic Distributors publishes a weekly list of new releases that serves as a good starting point, but this list does not include cover images, descriptions, or other interesting metadata. So, to keep this application fresh, someone needs to collect this information.

Based on my testing, building the comic list is probably a 2-hour task that must be completed during a small window weekly. Since building the list is more of an effort in tracking down the necessary information online, I’m confident that I can hire someone to do this for me for roughly $20 per week. My current top candidates to approach are some bright middle or high school students looking to make some spending money. If that fails, I have a larger network I can send the job description to, and failing that, I’m confident that I can hire a worker overseas to do the task.

So, in the end, the app will cost a little more than a thousand dollars a year to maintain in its current incarnation. As a marketing expense for representing my company on the App Store, this isn’t an unreasonable cost, and one that I would pay gladly.

However, I also like tinkering with business models and this app provides for some interesting possibilities:

1. Charge $1.99 per download. This is the most obvious model, but not one that I’m a big fan of. Given that Apple will take 30% of this price, I’d have to sell 15 copies a week (on average) to break even. 15 sales per week is probably not a big deal, but the main challenge is determining when market becomes saturated, and whether the window between release and saturation is one that can sustain the app as a serious ongoing business.
2. Run generic ads. This means that I would take something like adMob or Quattro and run generic ads in the app, which I would release for free. Given that this approach actively annoys me as a user, I would not use it for fear that it would reflect poorly on my company.
3. Run targeted ads. One idea that I’ve had this last week is the possibility of building out this app to be something akin to a Groupon for comic fans. The fundamental idea is that I charge comic book stores to run coupons in the app to bring people into their stores (“Buy 3 new issues, get a back issue for equal or lesser value free.”). If I had a sufficiently large and geographically dispersed population of users, this app would be probably the most effective means of advertising for this market. We have a lot of customers already interested in making a purchase, so what deals can we make to have them choose one store over another? Add auctions of geographic “areas” to the mix, and this could become a very potent income generator.
4. Start a virtual comic book store. As a kid growing up in the country, I would have loved this app, but been limited by my local lack of comic book stores. I had to make do with what the gas stations and drug stores decided to carry that week. Another avenue for monetizing this app would be to include some purchasing functionality in a future update that allows collectors in my previous situation to purchase comics as if they had a full store in their local area. I’m not a huge fan of this model due to the logistics involved, but this might be a good opportunity to partner with an existing store already doing mail order in exchange for a cut of the sales.

I will probably continue to debate internally which monetization model to ultimately use up to the point that I have to submit the app for Apple’s approval and listing. The “charge per download” model is appealing for it’s lack of overhead and logistics. Given that I’m willing to write the app off as a marketing expense for my consulting company, each $1.99 that I collect is gravy. The third model of a “comic book Groupon” appeals to the tinkerer in me as it’s an interesting system to build (geographic area auctioning system) and it’s probably a more sustainable and expandable business model than the straight sales. The major downside is the initial outlay involved, and whether the pain of creating and running the auction system is worth the gains. Fortunately, I have time to continue thinking about which way to go.

Wrapup

I always like to look at my efforts after the fact and ask my self a simple question, “Given what I know now, would I do this again?” In this case – even with the unanswered business model question – the answer is a resounding “yes”. In the past couple of days, I’ve built an app that addresses a specific “pain” that I’ve been feeling, and I’ve created something that I would be happy to associate with my company name. Lots of unanswered interesting questions remain, suggesting that this may become of my more interesting endeavors in the new year. I’m excited about the possibilities and seeing where this goes.

If you’re interested in joining me on this project by serving as a beta tester, please let me know by e-mailing iphone-app@audacious-software.com. I’ll be happy to send you a prerelease version of the app that you can bang on before it hits the App Store in a few weeks.

https://www.shiononline.com

I’m in the process of growing Shion from a single app to a full cloud-based home automation platform that will allow you to monitor and control your environments using a variety of desktop and mobile apps from anywhere you have an Internet connection.

The new online service entered beta today and I will no longer be posting about Shion at this site. If you’re interested in following along, check out the link above and subscribe to the site.

If you’re interested in becoming a beta tester, I sent the following note to folks who expressed interest in the project over the past two years. Please join the beta test if you’re inclined.

Subject: Shion Beta Update

Thanks for your continued patience while I’ve been getting this Shion monster online.

Good news: I’m ready to go full tilt with the beta test. The user account infrastructure is ready, as is the payment system and the Shion apps. If you’re ready to go, here’s what you need to do:

1. Download & install Shion 3.0b3:

https://www.shiononline.com/2010/12/shion-3-0β2/

This is an update from yesterday that points Shion at the new infrastructure.

2. Sign up for an account by following the instructions at

https://www.shiononline.com/software/shion-touch-beta-test/

You’ll need to sign up with Chargify (even if you already did so), and create a user account for Shion Online. Note that you DO NOT need to enter a credit card to get started.

3. The final page of the signup page shows how to set up Shion. In short, just enter your newly-created username and password in the “Online” tab in the Shion preferences.

4. After Shion is up and running (the lightning status icon should be black, not red), download and install the Shion Touch iOS app:

https://www.shiononline.com/2010/12/shion-touch-1-0β3/

You’ll need to download the app IPA file and a .mobileprovision file. Copy these files to your iTunes and add Shion to one of your devices as you would any other app.

If you didn’t send me your device’s UDID, you will not be able to install the app. To find the ID:

http://www.tuaw.com/2008/08/08/iphone-101-find-udid-with-a-single-click/

then send it to me via e-mail and I’ll update the appropriate files.

5. Send me your thoughts and feedback.

If you have any problems installing Shion Touch, please let me know. This is a lot of new infrastructure, so I expect to find the occasional glitch here and there.

Moving forward, I’ll be distributing updates to the Shion Touch via the weblog, so if you’re RSS-inclined, please subscribe to

http://feeds.feedburner.com/ShionOnline

or use e-mail:

http://feedburner.google.com/fb/a/mailverify?uri=ShionOnline&loc=en_US

Thanks so much for helping me test and get this system off of the ground. I’m looking forward to your feedback and thoughts about how I can continue to improve Shion and its growing stable of apps.

-Chris

PS. For the Android fans out there, I’m aiming to have a functional Android client available by the end of the year. Stay tuned to the weblog for details.

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.

• (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.