Here’s a familiar situation: you need an app, and so you need an app developer.  Senior management made mobile a priority for this year and provided the budget to bring development in-house.  Your web application developers are great with .NET, but they don’t know Java or Objective-C, the languages behind Android and iPhone development.  They don’t know the Android SDK or iOS SDK, the platforms on which Android and iPhone apps are built.  They lack experience creating user interfaces for small screens.  You do the reasonable thing and budget for a senior mobile developer in Q1, so that you don’t need to do any training or hand-holding, and then you figure you’ll add two junior developers in Q3.  That way, the senior developer will have time to get a solid app published and then can start to spend time finding and mentoring junior ones.

You draw up what seems like a reasonable job description, compared to your senior web app developer descriptions.  8 years of software development experience, 3 years of Android experience.  Great benefits, casual Fridays.  You post your job, and get a million responses.  Unfortunately, 98% of them are developers who have never worked with mobile, let alone published an app.  3 candidates have published a toy app in their spare time, but nothing impressive.  One candidate looked pretty good, but took another offer the day after you saw her resume.  One guy responded with the perfect skill-set, but his compensation demands are outlandish, to the point where it’s not even worth having a discussion.  You’ve never had this much trouble finding a good .NET developer, but you’re at a loss for how to get your app development rolling.

Where did you do wrong?  How do you fix this?

• Adjust your expectations
• Adjust your budget
• Consider a mobile web application
• Get creative

Expectations

Many management teams have realized that their apps are not a one-shot investment, but an ongoing process (like most software development), and decided that bringing the development in-house would be the most effective way to approach ongoing development.  Without any existing expertise in-house, they (very reasonably) tend to go after a senior developer first, one who doesn’t need hand-holding and that can mentor future hires.  However, these very reasonable conclusions have led to a serious talent bottleneck.  The Android Market opened in late 2008, and only really caught corporate attention when things took off around December 2009 (the original Motorola Droid).  Before the corporate world set an eye on Android, there weren’t a ton of Android developers putting out professional-quality apps.  Those that had the requisite skills were often already working at exciting start-ups that would do anything to keep them (or Google).  The situation is better now, but if you’re looking for someone with multiple years of full-time Android development experience, you had better have a very strong employer brand, or you better be prepared to bend over backwards.  You also may need to shave off the number of years in software development overall.  This is speculation, but I believe that Android developers are less experienced than the market for developers in general; they chose to learn Android because they didn’t already have a strong resume with another skill set.  I recommend reducing your expectations for a Senior Android Role to 5 years software development experience, with 1 year of Android experience, and an impressive app published that you can see for yourself.  You might get a little more experience out of iOS developers, because the platform has been a round a bit longer, but don’t push it too hard.

Budget

I recently had a discussion with a recruiter in the Washington, DC area.  It turned out we didn’t have a matching position to discuss, but we did talk about the current market.  He told me that senior Android contractors are currently bringing in about $15-$25/hr more than senior Java developers (with 10 years of experience).  You don’t have to take my word for it, but you may want to consult some local recruiters before you set your price range.

Consider Mobile Web Instead

You might not need native apps.  A mobile web application can hit all the major smartphone platforms in one shot and can leverage your existing web developers’ skills.  Mobile web apps never seem to end up looking like they belong on the phone like native apps do, and it usually takes additional skills beyond desktop web development to build a wow-worthy mobile web app, but the cost savings and headache savings can be substantial.  See my previous post, Do I need an app?, for more details.

Get Creative

Staff from within.  Send a couple of high-potential developers to a bootcamp for the platform of your choice.  Find an experienced consultant and put him on retainer for office hours for a few hours a week (I’ll be happy to help with Android coaching). Your existing developers will love you for the new career opportunity.  Fair warning: be ready to compensate them once they put out good apps for you, or they’ll disappear with a 25% raise a 2 months later.

Or, keep trying to bring in a resource from outside, but get flexible.  Let the developer work off-site 90% after first 3 months or allow hyper-flexible hours.  Offer a free phone upgrade every 6 months.  Put a freelancer on retainer for 80 hours per month.

Infiltrate the ranks of app developers.  Find them where they socialize.  Look for local meetups and networking opportunities.  Post to stackoverflow’s job boards or this new board just for app development jobs.

Or Just Ask Me

Need some more advice?  Want to contract with me to help you out?  Talk to me.  I’m not sales-y, I swear.  I’ll try to point you in whatever direction seems best for you, even if it doesn’t result in me billing any hours.

Alright, that’s an exaggeration.  If your app matches highly-searched keywords that don’t already have a bunch of competition, you already have obscenely popular apps (from which the Market can link to your new app), and you have such broad brand recognition that people are already searching for your app, you might be okay just by covering all of the bases in the Android Market upload form (screenshots, icons, video) and letting people find you.  For the rest of us, marketing a new app is not optional.

Things used to be different.  In February 2009, I put out a slot machine game called Beat The Joker Slots.  It’s a fun game to pass a few minutes, but it’s no Cut The Rope.  With no marketing effort to speak of, it managed around 500 (free) downloads per day, and based largely on early momentum, it has over 425,000 downloads today.

What changed?  Back then, there were a total of 34 games in the Cards and Casino category, and Android users had iPhone app envy.  There was a large audience keeping an eye on the “Just In” section, willing to try out just about anything that came out.  Fast forward a few years, and the “Just In” section is in disarray.  App spammers flooded the page with 100s of near-identical apps through the week just to stay on top of the list.  Google finally gave up on the concept in August 2011, emphasizing a new “Top New” section while neglecting to mention anything about the “Just In” section it replaced.  The good news is that excellent new apps have less app spam clutter to fight through.  The bad news is you have to get some traction in the first place to make your way there.

It’s now frighteningly easy to for your new app to fall in the forest with no one there to hear it. You need to be proactive about getting the word out if you want any chance to get exposure in the Market.  There are a lot of free ways to manage this, like*:

• Announce on your website
• Send out an email to your email list (which is opt-in only, right?)
• Get in touch with bloggers whose audience would be interested in your app and ask them to review it
• Promote with your company social media presence
• Promote with house ads in any other app you have published
• Sprinkle search keywords throughout your Market listing, but be reasonable about it so you don’t get banned

That still might not be enough, unless you’ve been especially diligent in laying the groundwork to build those communications channels into something powerful.  I have been reeling from just such a launch dud the last few days.  I put of Hoofit on Friday, and while it has been well-received so far, it has been well-received by its 19 total users.  Ouch.  I did everything from above that I could, using my websites, social media presence, house ads, and relevent keywords.  I may have a blog post or two in the works, but I’m not counting on it.  It looks like if I really want this app to get noticed, I’ll need to pay an ad network to help me get there.  To that end, expect my next post to report on some test runs with different ad networks.

Do you have any additional suggestions on how to market a new app?  Leave me a comment.

*You’ll notice I left out general-purpose app review sites.  I haven’t heard of any good success stories from these.  The most popular ones tend not to want to consider your app review request, the least popular ones won’t drive any traffic, and the ones in the middle might charge you for an “expedited review.”

UPDATE I’ve heard from other developers that Just In, which is still shown on older versions of the Market, is still making a difference for their download numbers.  Of course, this should become less and less the case as more users go to phones with the updated Market.

As I’ve previously discussed, it can be tough to sort through the hype surrounding apps for smartphones.  As if that’s not confusing enough, now there are tablets to consider.  Are they worth spending resources on?  Can’t I just use my smartphone app?  If not, can I at least leverage my smartphone app?  Can the same people that make Android smartphone apps make Android tablet apps?  How hard is to make a tablet-optimized app?  With this post, I’d like to help you understand the value in Android apps for tablet devices and the effort involved in creating one.

Let me start with the most important number: 4%*.  That’s the percent of of Android devices that are tablets.  Not so exciting, is it?  To be fair, this figure represents over 3 million tablets, but that’s not much compared to 38 million iPads that Apple sold last year.  The short answer to the title of this post is “No.”  You don’t need a tablet app.  But you still might want one.

First, figure to see less competition in the tablet space.  There are a zillion news apps out there, but not so many that are optimized for tablets.  Second, expect higher engagement with tablets, where users are likely to be sitting on the couch for a browsing session rather than checking their phone for the 10 seconds before the light changes.  Besides user preference, you also have to opportunity to engage more fully with rich media content.

You can re-purpose an Android smartphone app for tablets.  In fact, if you make use of the standard flexible layout options in Android, your app figures to look okay on tablets with little or no tweaking.  You can take it a step further and re-work some of your smartphone app to be tablet-friendly while still making use of what your development team has already written.  A common example would be a news application.  On the smartphone version, you’ll have one screen that lists headlines and another screen that shows the story for a single headline.  On the tablet version, the headlines will show on the left side of the screen and the selected story will show on the rest of that same screen.  I generally wouldn’t recommend going further than that — creating two completely separate apps for smartphones and tablets — but I’m sure somebody out there has a good reason to.

In conclusion, don’t fret too much about Android tablets right now.  Make sure your development team writes your screen layouts to be flexible (which is good practice anyway), and keep an eye on the tablet market.  Visit the Official Android Screen Sizes Chart every few months and look for growth in “large” and “xlarge” screens, and if it becomes a big enough piece of the pie for your tastes, dive in.

Many thanks to Mary Ellen Slayer of Reputation Capitalization for indirect inspiration on the topic of this post.  Mary Ellen is an expert at helping companies create value with their blogs.  She’ll even help write the posts if it’s all too overwhelming.

* Despite the bold typeface, this is still just an estimate.  It’s based on the 3.3% of Android devices that access the Android Market are using the tablet-only Honeycomb version of Android (3.0/3.1/3.2), and a educated guess of 0.7% for the small collection of other Android tablets that are not on Honeycomb.  This ignores a number of Android tablets that do not participate in the Android Market, but these tablets are not big sellers, and you’re not going to reach them in the Market, so don’t worry about them.

At Google I/O 2011, the Android team announced that there were over 300 Android devices in distribution throughout the world.  These devices range in size from 2.5″ phones to 10″ tablets (or 60″ televisions).  They cover 9 different versions of Android and a variety of custom interfaces.  Some Android displays contain 143 pixels per linear inch, others as many as 342.  Some have physical devices, some have trackballs, some have gyroscopes.  Android was supposed to move us past the J2ME world’s compatibility issues, but with this much variation between devices, it still takes a lot of effort to look good on all of them.  What’s a company to do?

Fortunately, the Android team has done a lot to make adaptable apps possible.  All (…almost all) of Android’s layout classes are design to work well on a variety of screen sizes.  There’s a nifty resource scheme that makes it easy to provide different icons for screens with different pixel densities, and known patterns for making use of new features on newer Android versions while still degrading gracefully on older versions.  9-Patch graphics allow custom buttons and text boxes to stretch and shrink appropriately.

There are examples of companies handling almost everyone.  Rovio covered 97% of Android devices with Angry Birds Rio, and Pulse managed 99%.  Still, you have to draw the line somewhere and looking great on 95%+ of all Android devices requires an investment in polish.  If this is you first foray into developing a mobile app, I recommend targeting Android 1.6 (Donut) and up.  This covers 99.2% of all devices accessing the Android Market today.  If you end up needing an API from version 2.1 (Eclair), the next version still active, you can pretty safely jettison support for 1.6, which will only cost you another 1.3% of the Market’s devices.  2.1/Eclair is a tougher case to drop, at 9.6% of the Market, and you barely have a choice but to support 2.2/Froyo (35.3%).  You can use the fancy new features from later platforms, but again, you’ll have to go out of your way to build a simpler experience for older versions.

If you’re pretty sure you’re going to make an ongoing investment in native Android apps, you should be designing your apps with some of the newer UI features like fragments and action bars, especially because they make it easier to develop related, but distinct, interfaces for phones and tablets.  As a bonus, using newer UI features means your app won’t look dated 9 months from now.  Less than 3% of devices (3.0+) support Fragments today, but the Android team has provided a compatibility library so that you can use fragments all the way down to 1.6.

I hope this post and its included links have helped you understand what you’re up against in supporting the myriad Android devices available and what you can do about it.  If you’d like some more guidance, contact me and I’ll be glad to help you get past these challenges.

Since iTunes App Store and Android Market launched in 2008, apps have been the hot thing. While apps on phones are not a new idea, these new distribution channels cut through a forest of red tape and their respective development platforms made it much more practical to bring an application to a large number of users on a large number of devices. With developers able to reach consumers so much more easily, the results have been staggering. The iTunes app store boasts 18 billion downloads, while the Android Market recent passed 10 billion. Together, that’s 4 app downloads for every person in the world.

Businesses are clamoring to meet their customers in this new medium, and understandably so. However, native app development is expensive, so it is important to consider what an app can and cannot do for your business before diving in. You may find that a different type of application might make more sense.

One reason people offer for wanting in an app is so that their customers can find their business in an app store. This made sense in 2008, when there were few enough apps that anything decent got exposure, but it is no longer the case today. There are about 1 million apps in the iTunes and Android stores today, and the lists of newest apps can turn over before anyone sees what you’ve published. The app universe is now a bit like the web – you know you need to have a web site, but just having a web site isn’t good enough. You must offer something that people want, you must be findable, and you probably need to do some marketing to get people there in the first place.

So if just showing up in an app store isn’t worth the investment, why build an app? The answer lies in what a native app can do that other media cannot. Native apps can take advantage of hardware on a smartphone or tablet, like a camera, GPS, accelerometer (tilt and jiggle detection), and compass. You can bring up an alert when something important happens (a client passes by a house for sale that falls in their price range). You can load data in the background (like today’s TV listings) so that it’s already there when the user wants it – even if they’re in a subway station with no signal.

The mobile-savvy reader will point out that most of the above is possible with a “hybrid” app – using something like PhoneGap to build a website that looks great on mobile devices and has access to native device features like GPS.  This is true, and you should certainly consider this strategy.  Hybrid apps can generally run on multiple platforms (like Android, iPhone, and Blackberry) with only minor tweaking to get things right for each platform, and so developing a hybrid app is a cheaper way to get to all the relevant smartphones and tablets. Furthermore, hybrid apps are wrapped up into a native app “shell” that makes it possible to upload them to the iTunes App Store and Android Market, so you still have a chance to gather ratings, reviews, and popularity there.  The downside to hybrid apps is that they almost never feel like a “real” app – if you write a single app, it won’t look like an Android app, or an iPhone app, it will look like a website.  If you’re not very careful, a hybrid app can feel cheap and flimsy.  You can absolutely get around this, but it takes a great deal of effort, negating the advantage of building a hybrid app in the first place.  In general, I recommend a hybrid app if you have existing in-house expertise with web development, but build a mobile-friendly web site isn’t powerful enough for what you want to accomplish.

Of course, that brings up the subject of mobile-friendly websites.  If you want your customers to interact with you with their smartphones and tablets, but you don’t have any need to take advantage of what makes those devices unique (compared to a desktop computer), a mobile-friendly website may be all you need.  The trick is to not just shrink your desktop-friendly website.   You need to think through what will be important to your customers on the go compared to when they’re sitting at their desks.  Think bite-sized content and easy information look-up.

It can be difficult to come to a decision on which of these options will work best for your business.  If you’d like some help talking through your priorities and how they match up with mobile development, please contact me.  I’ll be glad to give you a quick consultation for free, or provide a more in-depth report.  As you can see from this post, I will provide unbiased analysis – I’d love to work on a development contract for you, but more importantly, I want you to make the right decision.