Ever since the launch of the iPhone back in 2007, we’ve become used to the bewildering array of apps available for our smartphones. There are apps for pretty much everything: social media, banking, games, travel information, maps, shopping, even apps that show you what beers are available at your local beer festival (really, there are!). But how do all these apps actually work? In this blog we explore the different elements that go into making an app.
At the heart of any app is the operating system. The overwhelming majority of smart phones run either Android (developed by Google) or iOS (Apple’s mobile OS). The operating system controls the whole phone, in particular providing access to hardware functions such as the GPS, data network, motion sensors and storage. It also coordinates things like notifications (more on those later). As a general rule, Android is a much more “open” operating system, meaning that it imposes fewer restrictions on what an app can do than iOS does.
The user interface or UI is a combination of what you see when you load and run your app and the way you interact with it (e.g. taps or gestures on the screen, shaking the phone to undo, etc.). The different elements of the UI combine to provide you with (hopefully) a good user experience (or UX). An app’s success is largely down to this combination of UI/UX. There are a lot of guidelines out there for creating UIs, with rules/guidance on where to place action buttons, what colour schemes to use and how best to design elements within the UI.
Most mobile apps require a set of databases running on a central server. Typically these provide things like identity management, data about your usage of the app and any data that can’t be stored locally on your phone (for instance things that depend on your geographic location). More interactive apps, such as the Amazon app, also provide access to the full set of backend services like browsing the store, placing and tracking orders and account management. Typically most mobile apps host their backend servers in the cloud.
APIs (or application programming interfaces) are used in order to facilitate communications between your phone and the backend. Usually for mobile apps these use a specific approach called REST (standing for REpresentational State Transfer). Typically, when you first open your app you will be sent an API key which acts as your temporary identity. For secure apps you may need to login before you receive a key. Once you have a key, your app is able to send requests to the API and will receive responses containing the data it needs (or acknowledging receipt of data you sent). Some apps also make use of third party APIs such as the Google Maps API (which can provide location and mapping services).
As mentioned above, the operating system controls the local hardware resources. Apps are allowed to access these only if you give them permission. On most modern phones there are a huge array of sensors and services that the app could access. These include: GPS for giving your position, accelerometers to track the movement of your phone, the speaker or other audio outputs, the microphone and the camera(s). In part 2 of this blog we’ll explore some of the implications of using these sensors.
One of the key elements of any app is the ability to send you notifications when certain events happen, for instance if you have a new message waiting. These notifications are either local (controlled by your app and delivered when it is in the background) or push which are handled by the operating system itself and can be received when your phone is on standby. Local notifications are extremely flexible, but won’t work in standby. Push notifications are much more limited (typically only allowing a short text string to be sent). However if you give them permission (and have a data connection), push notifications will get to your phone whenever and wherever you are.
In part 2 of this blog, we’ll be going into further detail on app development and looking at some of the implications of opting for free or paid-for apps.