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

  • How LEGO-like software development using Microservices helped Toobler?

    Microservices: Legos for Software Development  We are so much in love with colorful plastic bricks aka LEGOs! In an age of online games and internet-connected toys, the humble Lego brick has risen against all odds.With approximately 62 pieces of Lego bricks for every man, woman and child  on the face of the earth, mere 6 […]

  • If you are in Jordan looking for app development support you should read this

    From downloading a mobile app  to visiting a brick-and-mortar store, customers today value every interaction with a brand. A great customer experience leaves a lasting impression in their minds about the happy and satisfying experience.  Winning the customer experience race Every  interaction offers  a make-or-break opportunity for a brand to either  build a loyal customer […]

  • Enhanced Efficiency & Optimized Cost of Project Development with Sweden Hybrid Model.

    Going beyond the cost factor and striving to deliver quality, innovation and flexibility to its customers across the globe, Toobler introduced a Hybrid (Onshore and Offshore) Software Development Model. Huge popularity of the hybrid model is fuelled by scores of organizations choosing to keep design and architecture phases at geographic proximity.  Driven by a customer-centric […]

Leave a Reply

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