2 minute read

When building for mobile there isn’t a silver bullet. Instead we have a myriad of compromises to make. If your an enterprise wanting to build apps here are four broad options.

Native code (Objective C for iOS, Java for Android, C#/Xaml for Windows)

Pros:

  • Build the best experience in each platform (Native UI, Performance)
  • Discoverable in app stor

Cons:

  • Cost (3 codebases)
  • Dev skills
  • Publishing to each app store, wait for approvals etc

Native with re-usable code (C# for platforms -> MonoTouch for iOS, Mono for Android, C#/Xaml for Windows) http://xamarin.com

Pros:

  • Build the best experience in each platform (Native UI, Performance)
  • Discover-able in app store
  • Code reuse (except for the presentation layer in each platform the rest of the business logic, web service calls etc are reusable)

Cons:

  • Cost (Cheaper than 100% native but will cost more than plain html)
  • Dev skills (Devs still need to understand the UI APIs for each platform e.g. CocoaTouch, UIKit…
  • Publishing to each app store, wait for approvals (e.g. you find a bug fix it and submit to app store, it will then take 5 business days before the bug fix is available for end users to download).

HTML but deployed natively (PhoneGap, Sencha, etc…)

Pros

  • Javascript (Use frameworks /tools such as jQuery mobile, TypeScripts etc)
  • Costs less to build (one code base across platforms)

Cons:

  • Performance issues with iOS webkit (Only Apple apps and Safari browser can use the hardware accelerated Nitro JavaScript engine, everyone else is forced to use the slower js engine. This is why Facebook ditched HTML5 and wrote a native iOS app). If the apps we’re building are not going to be flashy and don’t rely on animations then this is a non-issue.
  • UI is not native to each OS
  • App updates need to go through approval process for each App Store

HTML only: Basically a web site (ASP.NET MVC or a SharePoint app / application page with responsive layout to adapt to a mobile browser)

Pros:

  • Javascript (Use frameworks /tools such as jQuery mobile, TypeScripts etc)
  • Costs less to build (one code base across platforms)
  • Performance will be better (but not as good as native) since the site runs in Safari and can use hardware acceleration
  • Updates to app is just a matter of pushing update to website (user doesn’t need to upload etc)
  • Option #1 and #2 will anyway need a website to host the webservice

Cons:

  • UI is not native to each OS
  • Discover-ability: No app store. User needs to bookmark app url. Enterprises can work around this by having a single Web App Store that lists all their web apps (ala http://www.apple.com/webapps). Or build a shell native app that acts as a launcher for the web apps.

Need more options/tool choices? See http://en.wikipedia.org/wiki/Mobile_application_development

Another disadvantage with the native options. You need to build and publish a mobile and a tablet version of the app.

My view is that while native apps are the better choice for companies that build and sell services/products, the web option gives the best ROI for enterprises. Even when it comes to product/service companies a strong case can be made for going web only. Ask the guys who built Basecamp.