Choosing a Mobile Platform

The 6 questions you need to ask

I spend a lot of time talking to customers about mobile applications and platforms. Here are some things every customer should ask when evaluating a vendor for their mobile app.

But before I start, the biggest point I want to make is this:

You don’t want a mobile app. What you want is technology that’s going to make you successful in mobile. Anyone can build you a mobile app. However, some vendors will have a better approach than others. In the days of desktop computing, a badly architected app was a pain. In this next generation of mobile enabled apps, a bad architecture will kill your business.

Put bluntly:

Make sure if you build a mobile app on the vendors platform that it’s not an architectural “shit show” — pardonnez mon français :0)

On to the questions…

  1. Is this a mobile platform or a platform that allows me to deliver mobile apps?

Odd question — but there’s an important principle here. If you are choosing a “mobile platform” that is used solely to deliver mobile apps, you are making a big decision. You’re basically deciding that this app will ONLY work on mobile. Make sure your platform vendor can support mobile, but that the apps you create will work on laptops also. Remember — your business apps need to be accessible everywhere — not just mobile.

For example. Appcelerator is a cool cross-platform framework for mobile. However, if you build all of your logic and code in JavaScript using the Appcelerator framework, it’s going to be difficult to port that app to work on laptops and other devices. Same goes for iOS Objective-C apps, Xamarin, etc.

Just keep in mind that mobile is one of many ways your users will want to get access to the app. If you choose mobile only, make that decision consciously.

  1. Can you show me how a mobile app is built?

Some vendors will allow you to build mobile apps on their service as part of a trial, others will want you to go through a sales process before you can get access to the technology. Regardless of approach, make sure you’ve either built an app or seen an example of your app before making any purchasing decision.

And when I say you’ve seen an example, I mean they’ve shown you exactly how they delivered it! DO NOT accept flashy demos and sparkly UI. You need to understand HOW they built the app. Get the vendor to walk you through the code, show you the development experience. Get them to make a change to the app. Make sure they give you access to the app so you can have a play yourself. If this platform is genuinely going to make you successful, the vendor should have no problem lifting the curtain.

You should feel happy about how they put the pieces together. It should feel like it was done well and it will be easy to maintain going forward. Get them to explain the principles of their architecture and why it makes sense.

The best way is to simply give the platform a go yourself, but as with all new technology, it can be quicker to get the vendor to show you around and give you examples than you spending time self-teaching.

  1. Is the stack fully supported?

Make sure the vendor supports the end-to-end platform. Often vendors include 3rd party frameworks and development tools as part of the platform offering. Make sure they will provide support for those frameworks so if something breaks you have a clearly identifiable “throat to choke”. Mobile technology and tooling is still very new and many of the frameworks are still evolving over time — make sure your platform vendor will help you weather that storm by fully supporting your apps.

  1. Does the platform have a comprehensive set of APIs? And does my app have APIs?

There’s no denying that the architecture of the internet is changing to make room for the device revolution. This architecture is changing from being about HTML to being about APIs. Make sure your chosen platform vendor takes APIs very seriously. They should offer comprehensive APIs for your apps. But more than that — your apps should be API enabled also.

Why is this important?

As time passes, you’ll want to make your app available to all the different devices and form factors that hit the market. Spent any time thinking about Google Glass? Maybe not right now, but in 3 years you might find all of your customers want to access your app through their glasses. Having API enabled apps ensures your investment is ready for the future! Don’t get pushed into a situation where your apps are hard-coded in HTML5 and nothing more than a fancy website.

  1. Does the platform support offline?

Connectivity to the internet is never going to be consistent and constant. We just need to get over the idea that connectivity will be ubiquitous. Your apps need to work just as well offline as they do online. If the vendor can’t support offline, you might question their architectural approach.

The big give-away that a platform cannot support offline is when it “prints HTML” from the server. Not only is this a tired and old architecture — it’s also a bad way to support offline.

Make sure you ask this question — and are happy with the answer. If there’s lots of fumbling around the answer, you may want to re-evaluate your vendor selection. Offline support is only going to get more important with time, not less.

  1. Does the platform support standard coding languages for your developers?

Languages are changing all the time, but regardless of your developer preferences — be the language Java, Ruby or .NET, make sure your chosen platform vendor can support them all.

Whatever you do, make sure the vendor is not forcing you to use proprietary languages. It makes life much harder for your developers and makes it even harder for you to find developer talent to manage your apps.