What do I use to write a Mobile App?

I’m at Dreamforce this week, manning the Microsoft Azure booth in the Developer Zone. It’s been a really fun and busy week explaining all the things that can be done. This post isn’t about that. It’s about a question I got on the first day of the conference – what do you write mobile apps in? The answer – it depends. It depends on a lot of factors, but only a couple matter and they are in this post.

What sort of App are you writing?

In my mind, there are three types of app. We are all familiar with Consumer Apps. Facebook and Twitter fall into this category as do the vast majority of games. In Consumer Apps you are targeting the individual with your service. The service and your app are central to the product you are offering. In this case you are interested in engagement and getting users to use your app. Business Apps are used by businesses to allow consumers to access their services. The major difference is what is the service? Is the app just one method of accessing the service or are there other methods. The canonical example of the Business App is a banking app. The bank offers you a service (money management) and you just so happen to have an app for that. You could just as easily forego the app and access the money management features via a web site, ATM or at the bank branch. Many shopping apps appear here.

Random thought: Is Amazon a Consumer App or a Business App? I tend to think of it as a business app because the core thing that Amazon is selling is not the app – it’s the products you buy.

The final category is Enterprise Apps. These are produced by enterprises for their employees. Your friendly cable technician may have an app on an iPad that tells him all about your service details. That app will never appear on the device App Store – it is distributed via a private enterprise store or via an enterprise mobile device management platform like InTune or MobileIron.

So, what’s the big deal as to the type? In the case of the Consumer App you want the app to follow all the magical guidelines that the device manufacturers put forth for app designs for the platform. You want the customer to be comfortable with the app and that means making it act like all the other apps on the phone. With a Business App, the design is secondary to the brand that is being pushed. All Amazon apps look similar and act similar, irrespective of the platform that is running on them. Finally, Enterprise Apps are more concerned with functionality than a particular design. Design rules can be broken easily. This design stuff feeds into an interesting decision later on.

What sort of Developers do you have?

I was talking to a development manager, so this was particularly relevant to him. However, even if you are an individual developer, you still have your own strengths and weaknesses. There are basically three camps:

  1. Native Apps are written in Objective-C or Swift (for iOS), Java (for Android) or C#.NET (for Windows Phone).
  2. Cross-Platform Native Apps are written in C#.NET generally (although C++ is available too), with the assistance of Xamarin and use a compilation step to compile to native.
  3. Hybrid Apps are written in HTML5, CSS and JavaScript (or TypeScript) via Apache Cordova (or PhoneGap) and then wrapped in a WebView to display the UI.

Native Apps should always look like the native platform, but you have to write the code two or three times – once for iOS, once for Android and once for Windows. Cross Platform Native Apps allow you to write a single code-base for all your business logic – probably about 90% of the app – and then adjust the UI according to design rules for the other 10%. You still have to write a bunch of code for each platform, but the bulk of it is common. The result is a set of native apps each with their own look and feel.

Hybrid Apps are rendered in a WebView (which is a restricted sandbox) so you can use pretty much the same code for a website as for Cordova. However, they suffer from the same code base being used for everything. That means Android and iOS apps look identical. Realistically, this means you are going to write the code like you do a cross-platform app – with a central project for the common code and then a UI-specific piece for each device. Even then, you are likely to be disappointed with the “native look” because there really aren’t any standardized controls to just drop in. You also have to be careful about hardware device support – not all devices can handle all hardware compoenents. If you want to support Touch ID (on iPhone), you are likely to be doing some special code for that or moving to a cross-platform native app.

Bringing it Together

If you are producing a consumer app, then you probably want the closest and best native performance and design paradigm – that means Objective-C or Swift for iOS, and Java for Android and C#.NET for Windows Phone.
If you are producing a business app, then you probably want the widest coverage while still getting the performance – that means Cross-Platform Native Apps, or treating the project like a consumer app.
If you are producing an enterprise app, then you probably want common functionality across all platforms – that means Hybrid or Cross-Platform Native Apps.

Now that you have decided what skillsets you need, you can narrow down by my final criteria:

Write the app in what you know

If you know C#.NET and don’t know Objective-C, why are you trying to write a native iOS app? Just get Xamarin and build the app using C#.NET. Similarly, if all you have are JavaScript skills, go with a Hybrid App. Unless there is a specific (commercial or personal) reason to learn a new language or develop a new skill set, just go with what you know. It’s enough work to learn a new framework – you probably don’t want to be learning a new language at the same time.