Close

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 Client Client language/libraries
Desktop web        HTML/CSS/JS
Mobile web        HTML/CSS/JS
iPhone        Objective-C/iOS
iPad        Objective-C/iOS
Android devices        Java/Android
Native Mac app        Objective-C/Cocoa
Native Windows app        HTML/CSS/JS/Metro UI or XAML
Command line        Node, Python, Ruby, Java
3rd party API client        Node, Python, Ruby, Java
Twitter cards        Twitter API
Facebook Open Graph        FB API
Google Rich Snippets        Google Microformats
Google Glass        Glass Cloud API
iWatch (?)        Likely Objective-C/iOS
iTV (?)        Likely Objective-C/iOS

 

The Android OS fragmentation problem (Source: Google.)

 

android-OS-fragmentation-problem

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 )

Latest stories

  • 7 Proven Hacks to Enhance Your Mobile App User Experience

    In this digital age of fierce competition, quality and performance easily outweigh brand loyalty. Creating a fluid user experience is essential for the  success of any mobile app. Efficient user experience UX is the backbone of a visually appealing and engaging app. It can either make or break an app.  Here are a few considerations […]

  • Things To Know About App Testing During Development

    With years of experience in app development and testing, we give utmost importance to quality assurance in mobile application development. Our team of adroit software testers ensures that quality assurance is an integral part of the development lifecycle right from ideation to deployment and in post-development reviews. Here are a few things the QA engineers […]

  • Go Live: 6 Things To Do Before Publishing an App

    After years of publishing applications to the app store, our team has come up with a checklist showcasing important things to do before publishing your app on Google Play or Apple App Store. Without further ado, let’s get started.  #1.Thoroughly Understand The App Store Policies and Guidelines It is vital to understand the app publishing […]

Leave a Reply

Your email address will not be published. Required fields are marked *