By Sibers Mobile Team Leader
When we speak of “mobile apps”, we visualize little bundles of awesomeness with which we love to play, fiddle and interact with. It’s hard to believe then that behind these apps is a complex server-side architecture developed by an experienced team of mobile developers, .NET specialists, PHP or Java coders. By the end of this article, we hope you’ll be more informed about the reasons why certain mobile applications cannot exist without a server‐side component.
There’s a lot of ground to cover on this topic, but for the purpose of this article we’ll limit ourselves to answering the most important questions, such as:
- What does “server‐side” mean when it comes to mobile applications?
- When is server‐side needed, and what apps require it?
- What server types are available, and which one is the “programming language of choice” for each situation?
- How long does it take to build the server‐side part of an application?
- Server‐side as a 3rd‐party service?
- What are the limitations of mobile apps, and what are the differences between iOS and Android-based devices?
Let’s begin by imagining mobile apps like islands: they often appear completely isolated, but most of them have an underwater connection with the mainland — allowing, for example, a constant supply of fresh water. In a similar way, mobile applications need to communicate with a server in order to return complex results to the screen of your (limited — no offense) mobile device.
The server-side of a mobile application
The server‐side of a mobile app is, in short, a software program running on a remote server. The main reasons why a mobile app may need server‐side are:
- To store and ensure users’ access to common data
- To ensure interaction between devices
Generally speaking, the server‐side part of an app performs operations that require access to services, information and functionalities not available in your mobile device. Such data includes, for example, data and image processing, storage, complex calculations, parsing and synchronizing. Server‐side also enables developers to backup data, make an application more secure, and function as the central unit in a network of a number of devices with the same app installed.
Let’s say you want to share a picture with another user. Wifi networks only work within a range of about 100m; Bluetooth devices can be separated by no more than 10 meters; and direct interaction is often impossible due to internet providers’ policies. However, all of these limitations can be bypassed by an application with server‐side backend.
Server-side prevents mobile device overload
When we use server‐side technology, we can improve the performance of a mobile app by moving the most intensive calculations to the server. We’re talking memory and pure processing power: consider, for example, an application that displays a list of restaurants and cafés in your surroundings. A comprehensive database of such places could weigh up to 1500Gb — an amount of space no current mobile device can handle. However, if we move the database to the server, we can shrink the mobile application size to something around 40Mb, which is definitely more acceptable.
Imagine now a stand‐alone mobile application that enables users to discover nearby gas stations. If a new gas station becomes available, the developer has two options: either release an update for each operative system, or simply add the new information to a shared database. After synching with the server, all users will receive info about the new gas station, regardless of their app version.
Research indicates that users update their apps every six months on average — and so with information needing to be refreshed frequently, using server‐side is a no‐brainer.
When do you need server-side?
Server‐side is compulsory for the following application types:
- Apps exchanging data between devices
- Search, booking and reservation systems
- Blogging apps
- Financial tools, organizers, news and information applications, shopping, productivity, social applications
- Coupon and discount apps
- Voice‐recognition apps or apps with other advanced media functionalities
Now, what apps don’t require server‐side? Any of the following, for example:
- Single‐player games
- Editors (audio, video, text or photo)
- Calculators, converters
Server‐side is also recommended when you need to keep data secure, or share it/sync it across multiple devices. Typical examples are fitness, dietary or blood pressure-logging apps.
Choosing the right programming language
Before choosing a language for the server‐side, you should have a clear idea of your app’s functionalities. Each language (PHP, Java, ASP.NET, etc.) has an already‐developed set of components that can make your choice easier: for example, if you’re building an application with CMS functionalities, then server‐side should use PHP because there’s a ready-made range of solutions related to handling CMS with PHP. When dealing with big databases or serious mathematical calculations, it would be better to choose Java or ASP.NET, as these perform better when addressing these types of needs.
How long does it take to deploy server‐side?
Depending on the project, creating server‐side can be a time‐consuming task. If we’re talking about a game that stores simple leaderboards, deployment can be done rather quickly. Conversely, the server‐side for multiplayer experiences often requires many man‐hours. Banking apps are even more taxing; their server‐side might take years to build due to the various measures required for implementation in order to grant secure access.
The fundamental question you need to ask yourself is this: what is my application’s purpose? The more advanced the data operations involved, the longer server‐side deployment will usually take.
Ready‐to‐use 3rd‐party server solutions
Let’s examine the practice of 3rd‐party server‐side providers for mobile apps. The idea behind a 3rd‐party’s “universal solutions” is for you to avoid the pain of building a customized app from scratch. However, there are serious downsides: these solutions only work well if you use them as remote data storage, and flexibility is generally poor. This means no customized design and a bunch of limitations — not to mention non-requested (and potentially annoying) advertisements.
On the other hand, custom servers allow you to build anything your heart desires, with hardly any limitations except for your own app’s innovativeness.
Servers for iOS and Android: what’s the difference?
Are there different requirements for the server‐side of iOS and Android? The short answer is “yes”. For example, one of Apple’s requirements relates to video streaming bit-rate: when streaming any video from a server, a low‐def 64 Kb/s video stream for slow internet connections must be provided. However, Google does not have a similar requirement for Android. Bear in mind that each platform — including Windows Phone and Blackberry — has its own specificities, and these must be accounted for when designing an app.
We hope this article has broadened your understanding of why developers insist on server‐side deployment. Getting it perfect is often essential for world‐class applications: hidden from view, servers perform most of the “dirty work” on behalf of your application, promptly returning the updated results requested by the user. And at the end of the day, that’s the difference between a happy, engaged user and a frustrated (ex) customer.