Takeaways: GA’s ‘How to build a mobile app’ class

Class: General Assembly session on “How to build a mobile app“, led by @peterbell.

Date: February 15 2012, 18:00-21:00

This was a useful session which focussed (for the better, I thought) more on how to think about developing a mobile strategy than on the technical nuts and bolts of building a specific application.

Peter Bell, CTO of Go Pow Wow and a lean startup coach, divided the session into five sections:

The Importance of Mobile

The stats on mobile growth and penetration are staggering: a recent report by Forrester Research posited that there will be 1bn smartphones in use by 2016 (and of these, only 257m in the US).

Here’s a chart from another study by Chitika Insights showing the share of web traffic accruing to iOS devices (i.e mobile devices made running Apple’s software) vs Mac OS (i.e desktop) devices:

And here’s a broader snapshot of the desktop vs mobile trend in search, via Bernstein research and @pkedrosky:

In short: it’s often not a question of whether you should “go mobile”, but how.

Mobile is not just about using a different device; it’s also that the person using it is mobile, and the fundamental things you do when you’re on the go are different – Peter Bell

Do you need an app, or will a mobile site do?

Bell said that for some organizations/companies/publishers, a web site that was “mobile friendly” (optimised using responsive design, for instance) might suffice.

When you have one set of code to solve two sets of problems, you almost always do a bad job of both. Responsive design makes your code hard to maintain – Peter Bell

A tip from Bell – if you do take the path of responsive design, start by thinking about the mobile site first. In other words, add features until you get to the desktop site, and not the other way round.

(More on this in the section on “Stepping toward mobile“).

When building for mobile, you typically want to break your audiences down by the kinds of problems they’re looking to solve…then you need to find the overlap between your audience’s needs and a compelling business case – Peter Bell

Native vs web

As Bell put it, it’s a native app if you go to an app store to download it; it’s a web app if you need to first open a browser. (He later added some caveats to this as there are “fake-native” apps; see the section on “Stepping toward mobile“)

Advantages of native apps

Better performance – a major consideration if you application needs to perform a lot of mathematics (like games)
Access to all device/OS features

One of the biggest reasons people go for native apps is the marketing benefit [that comes from access to the app store] – Peter Bell

Advantages of web apps

Generally a much shorter time to market than native apps (faster to build, may be easier to find developers and, for iOS, no app approval process required)
Tends to be cheaper to build
Easier maintenance (only one code base, vs the “versioning” required with native apps)
Better coverage – easier to support multiple devices with one app
Can tap into existing developer skills (rather than needing to find someone fluent in Objective-C or Java)

A world of natives

iOS
Android
Windows Phone 7
Blackberry
Palm WebOS

A key question for any mobile development strategy: where is the audience? (In other words, what mobile OS is your core audience using most?)

A second key question: what’s the form factor of those mobile devices?

If your audience is using iOS, are you going to develop for iPhones or iPads, or both? If you’re developing for Android — which Bell described as a world of pain — you’re thinking not just about tablets vs smartphones, but about the a range of different shapes and sizes therein.

There is almost nothing in common between developing for a tablet and developing for a smartphone except for the language – Peter Bell

Stepping towards mobile

Bell identified a range of options regarding mobile strategy, as follows:

Do nothing (because you don’t need one)
Upgrade your website (using responsive design)
- CSS media queries
- Grid layouts
- Fluid images
But! Issues with responsive design
- Speed matters on mobile – and image resizing on mobile is slow
- Javascript still downloads, even if it’s not rendered (speed issue)
Build a dedicated mobile site
- m.yousitehere.com or touch.yousitehere.com depending on devices targeted – these sites will be functionally different/optimised for either touch or keyboard interfaces
- Always provide a link back to the desktop version! (As an aside, I recently needed to visit the foursquare desktop site while out and about. No such luck. Bad form, foursquare)
Frameworks
- JQuery Mobile
  - Designed to progressively enhance or degrade in terms of functionality depending on divide, and is a useful way to work with older and/or non-touch based devices
JQ Touch
- Optimised for WebKit (i.e touch-based devices)
Sencha Touch
- All javascript, so the experience (for users) is all or nothing. (If their devices aren’t compatible with the version of javascript, they will only see a blank page)
- The problem for web developers is that even though you’re using the same languages (HTML and CSS), you’re not using them in the same way
Phone Gap
- Allows access to “native features” (like the camera in iOS) without having to write a native app
- Gives access to the app store
- Multi-platform
- Beware the uncanny valley – the app won’t quite “look” right (i.e fully native), which might put some users off. (This is also the reason major brands tend not to use Phone Gap)
Appcelerator by Titanium
- Looks and feels very native – gets you through the uncanny valley
- Only available for iOS and Android
- You should build two sets of views – one for iOS and one for Android, unless having an app that definitively looks like neither platform is a marketing/branding point
- Generally faster and provides better performance than all other non-native options
- Easy until it isn’t – supporting multiple views and versioning gets time consuming
- Appcelerator code can be a whisper behind the native code and features for iOS and Android – but this is only an issue if access to very bleeding-edge options required
Native
- Go native when you know definitively no other option will work for you – e.g. gaming, or cases where memory management and garbage collection are essential (like magazine-style apps)

At this point the lean startup coach in Bell kicked in:

Remember whatever you end up building will not be what your eventual customers want (so don’t spend $$$ on the first iteration of your app, and don’t design something which will slow down your availability to upgrade or overhaul features as customer feedback and business cases demand)

Testing

Mostly sucks
Any developer writing in Objective-C or Java should be doing unit tests and integration/acceptance tests
Emulators
- only catch 60-70% of the bugs – entirely possible to write code that works perfectly in an emulator and completely breaks in a live environment
- iOS Simulator (packaged with XCode)
Test Flight
- Allows distributed beta testing for iOS apps
- Not free
Automation (of unit testing)
- Fone Monkey
  - Least bad option for automated testing of iOS apps
  - Comparable to Selenium or Cucumber
- Robotium (Android)

Bonus section!

Since you read all the way to the end (or maybe just scrolled down…), here are some other odds and ends from Bell’s class:

On Developers
- I generally won’t hire developers in the US who work for less than $100 per hour, because it’s so much more expensive to hire cheaper
- A “good” developer in the US is generally working for $100-$125 in the major cities
- Three questions to ask any developer you’re thinking about hiring:
  1. What versioning control system do you use? (Prefer Git, worry a bit if they say Subversion)
  2. What unit test framework do you use and why?
  3. What frameworks do you use and why? (more a question for web developers
- Any good developer will relish the opportunity to answer those questions, to discuss and defend his choices, and be able to do so in a clear and concise way.
On Prototyping
- Don’t discount Keynote or Powerpoint – there are clickable templates available for pro typing
- Whatever you use for the prototype, make it look rough and ready, because if it’s too slick people will get hung up on design issues instead of functionality