Building a Mobile App with Azure

Creating a mobile application is relatively easy these days as we have a huge choice of WYSIWYG editors, templates and other tools. The general mobile-first push has also increased the quantity and quality of documentation for developers which gives so much support to implementing features and fixing any issues. I personally think Google has the best documentation and samples available to developers on the Android platform, and their regular events such as Google I/O (which give out tonnes of sample apps!) and their detailed online courses in Android Development really set them apart from the competition.  For my final year project, I’ve chosen to make a modular event organisation/finder application, similar to Eventbrite or Meetup, but with some really cool features and ideas that aren’t out there. (yet!)

My idea behind the project was that I always found Facebook events really boring and generic when I still had an account and I also hold that opinion of Eventbrite too. Meetup is a bit more to my liking, but that’s more community-orientated, I want my app to be used by small groups of friends or by large communities too. I picked the Android platform because I really like developing for the platform, and the majority of the devices I own also run it so it save me approximately all of my life savings for a single iPhone. Azure is like my trusty steed, whenever and wherever I can use it, I do. For mobile apps, there’s a pretty wide choice for picking a backend with Azure; you could go with Mobile Services, or the newest updated version of Mobile Services- Mobile App Service which is a part of the Azure App Service, or an API app which would be mostly HTTP RESTful interactions, or the old reliable Web API – part of the ASP.NET MVC Application. I’ll outline my personal pros and cons of each below, as I’ve had experience with all of them.

  • Azure Mobile Services

This one has been around for a while, and was an alternative to using a Web API. In reality, a Mobile Service is a Web API wrapped up in some nice containers to be easier to manage from the Azure portal. The backend can be written in JavaScript (Node.js) or C# .NET and both are fine. With JavaScript, the scripts are written as ‘Custom APIs’ along with table scripts on the database, these all contain the Get, Post, Put, Delete and whatever else there is. Azure provides a very (VERY) basic script editor embedded in the portal, but for your own sanity do not use it. The error detecting / Intellisense is basically non-existent. Download and install Visual Studio 2015 Community Edition and log into your Azure account within VS2015. View -> Server Explorer will reveal you Mobile Services here, and you can edit the scripts easily from here. Mobile Services can still be tested using POSTMan or Fiddler which is handy, and authorization is relatively easy (including custom email/password auth) From personal experience, Mobile Services can be difficult to work with, specifically the .NET backend. Only last week, using Source Control also, my NuGet packages would not work at all. I spent hours trying different fixes, rolling back versions, even trying it on completely different machines and I always got the same result. Creating a new project from scratch worked fine, but my trust in Mobile Services is limited after wasting so much time on it. (Also Mobile Services are limited to the old portal only)

  • Azure App Service – Mobile and API

A new offering from Azure is Azure App Service, which aims to merge web apps and mobile services into a single version. When it was advertised first I was thinking “Wow! Exactly what I want” but then discovered that Azure App Service is split into Web App, Mobile App, API App and Logic App – so I’m not too sure about the idea behind it. Anyway, Mobile Apps are a re-hash of Mobile Services but with a bunch of improvements to it and it actually runs as a Web App. I believe the JavaScript / Node.js SDK of Mobile Apps was just launched recently, which gives you the option of either .NET or JavaScript yet again. API apps are entirely RESTful apis, which is exactly what’s needed for mobile apps. They are very similar to Web API projects in general, but you can use .NET, PHP, Node.js or Python as the backend language of choice.

  • Web API

File -> New -> ASP.NET Web Application. I think we’ve all done this at one point in time with Visual Studio. Selecting Web API in the options gives us a great backend for our application, which can be accessed through RESTful calls to controllers / api’s. I’ve found a Web API to be one of the easiest to develop, alongside API App in simplicity. The overall documentation and user questions and answers across the internet are far greater than any other option listed above. Also any solution to a problem in C# from another type of project can generally be applied with very little trouble.


Once you decide on a backend system, most of them have getting started tutorials on Azure and MSDN. I’ve chosen Web API for my project, so the majority of my information to come will be based around this. Databases would be the next logical thing to sort out, if one is to be used. Azure SQL databases are my preference as it makes it easier to work with when both the server logic and database are hosted in the same environment. Plus publishes and updates are super easy with Azure. If you’re using .NET, the Entity Framework is the way to go for database persistence, and is ridiculously easy to work with. I’ll be talking about my general Web API setup next, including custom authentication and authorization with .NET and tokens!