So, you (that’s you: a business owner, entrepreneur, start up, venture capitalist, or just anyone) come up with a great idea for an application that’s going to solve THAT PROBLEM. You know, it’s THAT PROBLEM that everyone has and this application will be THE SOLUTION to THAT PROBLEM. What’s more is you’ve done a bit of research and decided to go “mobile first”. THE SOLUTION to THAT PROBLEM will be a mobile application.

The decision to go mobile first is a good one, recent statistics show that 98% of individuals who own phones use a smartphone. This is a fertile field for bringing THE SOLUTION to all those people with THAT PROBLEM. To put a figure on this in 2015 the United Kingdom will see the number of smartphone users rise to 37.8 million(thanks to ASTP’s #DIGITAL NATIVES paper for the figures).

At Codified we’re approached by a lot of people who want the mobile app that will be THE SOLUTION to THAT PROBLEM. Sometimes we have to break the news that getting the mobile app made will take more than a few weeks of development. Oh, were it so simple! There are other things that mobile app is going to need, things that go on behind the scenes, things that most people don’t know about.

I apologise in case you thought that an app is just an app. It’s not.

Most mobile apps that are going to be THE SOLUTION to THAT PROBLEM will be something known as “dynamic”.

The other type of mobile app is “static”. A “static” mobile app is one that after downloading needs no outside data to do its function. Static apps are things like the calculator or dictionary on your phone. For a static app to work there’s no need for a phone to have an internet or data connection, all it does is display information or perform a simple function.

The mobile app that’s THE SOLUTION to THAT PROBLEM will be “dynamic”. These applications will need data provided through an internet connection or the phone’s network. A simple example might be an application that updates local weather. These apps need to access databases to provide information that may be changing from one moment to the next.

A good example of a dynamic app is Uber. To get a cab to you Uber has to know your phone’s location, who you are, the locations of drivers near to you who are looking for a passenger, who the driver is, how to get the driver to you, how to take the quickest route to get to you and to get you from A to B, and how to bill your account after the journey. This is done using a mixture of location services, internet and mobile networks, and information hosted on Uber’s server and databases. All this data is communicated through something known as an API or Application Processing Interface.

The API for a “dynamic” mobile application will be 50% of THE SOLUTION to THAT PROBLEM with the mobile app making up the other 50%. The API works alongside a server and allows a product or service to talk to another product or service, exchanging data that changes in real time.

When a company release an API, like Uber did in September (check out the Uber API Hackathon), this gives others access to their data and resources creating more possibilities for other developers within and outside a company. The release of the Uber API allows developers to add the function for summoning an Uber to their digital product. When it was released in September 2014 it already had several companies partnered with it such as Expensify (put a cab on expenses!), Hyatt Hotels & Resorts (order a cab from the Hyatt app!) OpenTable (order a cab to & from the restaurant!), Starbucks (order a coffee and cab!), United Airlines(order a cab after getting off a plane!)

What’s the point of sharing the Uber API? It’s simple, sharing the API will cause an increase in traffic and in sales. Uber is so well known that users of other apps into which the API is integrated will be familiar with it and have no problem using it. I will say that I am curious about how this affiliate business model works and who’s paying who…

There’s a need for caution when sharing the API outside of a firewall. This past week saw the release of the Tinder API and some of it’s randier users became part of what is now known as #BrosSwipingBros. A computer engineer exploited weaknesses and loopholes in the API to create a perfect storm of males users “catfishing” each other thinking that their match was a girl.

For the app you’ve got in mind to be high quality, fast, provide accurate information, and make a difference to its users you’ll need an API and a database that pulls in data without using up too much bandwidth or doing it so slowly that it changes the User Experience. 

Curious about what it takes to make an API? Get in touch with Codified at [email protected]