Year 2014 challenges to your app development strategy and the solution.

Its 2014 and you’re looking for an app developer for your startup or your organization.

And you might very well think. Lets Focus on building a mobile app first as these are users connected to the internet 24 hours a day. Hold on.

Let me first show you an important issue in “going mobile” namely the multiplicity of screen widths and OS versions on Android and more generally the wide array of potential API clients.

Table 1:

The general mobile API client fragmentation problem. From the point of view of API-based design or service-oriented architecture (SOA), mobile means not just mobile devices, but the set of potential clients/distribution targets for your application/content. Note that for several of these targets (iPhone, iPad, Android) one may also need to design an alternate layout of the page for portrait and landscape mode.

API ClientClient language/librariesDesktop web       HTML/CSS/JSMobile web       HTML/CSS/JSiPhone       Objective-C/iOSiPad       Objective-C/iOSAndroid devices       Java/AndroidNative Mac appObjective-C/CocoaNative Windows app       HTML/CSS/JS/Metro UI or XAMLCommand line       Node, Python, Ruby, Java …3rd party API client       Node, Python, Ruby, Java …Twitter cards       Twitter APIFacebook Open Graph       FB APIGoogle Rich Snippets       Google MicroformatsGoogle Glass       Glass Cloud APIiWatch (?)       Likely Objective-C/iOSiTV (?)       Likely Objective-C/iOS

The Android OS fragmentation problem (Source: Google.)

While a bit of a pain, the situation is not as complicated as these figures and tables may make it out to be. From a business perspective, you need to consider whether you will be optimizing for sheer global availability (in which case a mobile web app with RWD is the first choice), for maximum current App Store revenue (in which case iOS-first is still the best), or for the maximum number of handset users and potential future app revenue (in which case Android-first may be worth a bet).

From a technical perspective, there are essentially two options for dealing with client diversity in the context of mobile web apps. At one extreme one can use the one-size-fits-all approach of responsive web design. In this case, the server returns the same HTTP response for all clients, with CSS media queries in the body of the response used to implement some conditional logic (e.g. hiding or showing certain divs on a phone or tablet). At the other extreme the server can return different HTTP responses for different User Agents, as specified in the headers of the HTTP request. This can be used to deliver custom mobile-optimized sites and is what Facebook, Google, AirBnb, Twitter, The Guardian, TechCrunch, and now Github are doing (often via a URL like m.example.com). An even more labor-intensive version of this is to build both a mobile web app and a native app for each client.

The second approach of custom sites for each client is significantly more expensive, but can be partially facilitated with a so-called API-based design or Service-Oriented Architecture (SOA). In this setup the core of the application is an API calling a database. All clients (internal command line tools, the mobile web, and iOS/Android) then simply call this API to create/read/update/delete objects and then render them using the tools of their native environment: e.g. ASCII for the command line, HTML for the mobile web, iOS widgets for iOS apps, and so on. That said, even with this kind of approach one needs engineers to constantly maintain the templates for each and every device (and in both landscape and portrait mode), ensuring that they don’t break or subtly lose functionality as operating systems are updated and new devices come out.

While Facebook can afford this kind of investment, for a small company it is infeasible to support many different clients. And it is usually unnecessary: picking one platform and using it to prove out your market is probably the best idea. Steve Jobs’ heuristic was to pick a “technology in its spring”, a technology which is fresh and growing yet has been used in production applications by at least a few people. One way to measure this is by comparative Github forks/stars, Stackoverflow activity, Google trends/search data and the like. Obviously, the ideal first platform will change over time; for example, Instagram timed their pure iOS bet perfectly, but a company that was doing something similar today might seriously consider doing Android first (or perhaps even getting a Google Glass dev kit).

A Mobile Solution: RWD first, Native immediately after, and then use logs

Toobler recommends mobile web first because it is relatively easy and will get you “on base” for each platform and (b) it will be useful no matter what you do. However, it should be explicitly noted that even if ChromeOS and mobile HTML5 are the future, the present is still very much native.

here is a reasonable approach to get started with an app as of mid-2013.

1. Start with a responsive web design app, built on top of an API.
2. Don’t try to build an RWD framework yourself; this is an enormous effort in its own right. Use Bootstrap 2 (or if you want to be aggressive, Use Bootstrap 3).You might also consider Zurb Foundation.
3. Theme your Bootstrap app with an off-the-shelf theme from wrapbootstrap or bootswatch or the like. Customize with Google Fonts or get a designer from dribbble.com or 99Designs.com to do more in-depth customization.
4. Now deploy your site and get some users.
5. Analyze your log data very carefully, looking at User-Agent in particular to determine what devices your customers are using.
This approach will let you up and running quickly with something which is functional on virtually every platform. Then you can use the log data with your business strategy to prioritize further targets. Alternatively, you can launch the RWD app and then go with (say) an iOS or Android app, using the log data to prioritize your second target (depending on your product, that might even be IE clients rather than iOS clients). The use of an API at the core of the site will then allow you to generalize to new platforms over time (e.g. Google Glass or Apple’s Watch, as well as embedding your app in Twitter or FB )