How do I choose mobile App hosting?

How do I choose mobile App hosting

The mobile industry is constantly evolving, attracting businesses from everywhere. The explosive popularity of mobile apps has made app developers quite in-demand professionals.

So what is it about mobile apps that people keep talking about? What benefits do mobile apps bring to businesses? These are very frequent questions asked by many people. To answer these and many other questions about mobile hosting, read this article.

To choose hosting, we need to understand the needs of a mobile app, which means we will have to look in detail at the process of creating it and the technology stack used in doing so.

Gaming apps

Gaming applications can be referred to the first group because of their specifics: performance requirements, interactive animation capabilities and technologies used. The main difference between game applications lies in the network protocols used. For example, when an application has an interactive mode (for example, real-time combat mode) the protocol based on UDP network stack can be used. In other cases, protocols over the TCP/IP stack are used to communicate with the server side.

Besides this we can single out one more difference of game applications – the technology stack used for the client part implementation. In most cases game applications are written in languages different from those used for creation of usual mobile programs. Here we can distinguish the use of engines Unity (C#), Unreal Engine and less common, such as Cocos2dx (C++). Of course, for some game genres, native platform languages are also used. It is worth remembering all the well-known 2048, but it is rather an exception to the rule.

This group of applications is quite specific and involves higher requirements to bandwidth, hardware and the level of the developer in general. The development of the server part for gaming applications is a topic for a separate article, so we are not going to discuss it here.

Common applications

The second group consists of office and entertainment applications, productivity tools and so on.


The classic option is to use native languages and their variations, such as Java, Kotlin, Objective-C and Swift. The advantages of using native languages include a very fast execution speed and a relatively small binary size, but the size of the assemblies (images, fonts, etc.) should also be taken into account.

Since knowledge of native languages is a basic requirement for a mobile application developer, the positive factor here is the availability of specialists. The only disadvantage is that you will have to rewrite the code for each platform in its specific language.


A very popular trend – the use of the Flutter framework – solves the problem. It reduces development costs through a single code base for Android and iOS, and has more opportunities for interactive animation. In addition, with the Block design pattern, you can use the code for web implementation as well. Flutter uses the Dart language and is built on top of the Skia graphics library with an extensive C++ codebase.

Rendering in Skia is done by the GPU, which makes the application more responsive. In addition to program animation, Flutter has the ability to play Lottie animations that can be created in Adobe After Effects.

The advantages of using Flutter to develop a mobile app include fairly low cost, high app performance, and animation capabilities. I can’t find any disadvantages other than a slight increase in application size due to Flutter runtime.


Another common option is web-based development. This is where React Native leads the way. To be honest, I’m not a big fan of React, but I’ll try not to be biased in my evaluation of its use. The indisputable advantage is the availability of programmers proficient in this technology and the ability to use in-house web developers to create a mobile application. That’s why most of the time they make an MVP (minimum viable product) on React Native.

If you have full-stack developers, you will most likely prefer to use Node.js for the server side. React Native also supports animations quite well, including Lottie animations. Unfortunately, the same undeniable disadvantage is the very poor performance of the application. From my experience, I have to rewrite products with a different technology stack for this very reason.


PWA (progressive web app) can be considered as a separate category. They are not mobile apps in the usual sense. These are progressive web apps running in an integrated browser. PWAs are created using languages such as JavaScript, TypeScript and Dart. They are a good enough choice to create an MVP, or perhaps a final application.

The network stack of a mobile app

To evaluate the network requirements of a mobile app, let’s take the online store as an example.
The basic states of the app:

  • The user is logged into the app.
  • The user is on the home page of the app.
  • The user selects an item.
  • The user adds the product to the cart.
  • The user makes a purchase.

For each of these states, the application only needs to make one request to the server side, get a response, and display the data. This is actually a standard Rest API over HTTPS. Now let’s try to add to our application the ability to communicate with the store’s consultant:

  • Sending a message to the server.
  • Receiving a message from the server.

Sending can be done using the familiar Rest API, but what are the options for getting a message from the server?

Of course, we can use Push Notification and we have to use this technology anyway to receive messages offline. However, using Push Notification for online messages is impractical because of the delivery delay.


This option implies regular requests to the server at regular intervals. As ambiguous as this solution may seem, it has a right to exist. For example, this is how the client application of the social network VK works. The advantages include the fact that we do not keep a constant connection to the server and its memory requirements will be lower. Of the disadvantages we can mention the increased battery consumption of the mobile device.


Good old longpoll came before HTML5: it differs from ping-pong in that the connection is not initiated by the client or the server. It stays open, and you can send data to it until the time to live (TTL) of the connection is up. The TTL settings are set on the server side. When the connection is closed, the client application can re-establish it immediately or after a certain period of time.

This allows to slightly reduce the power consumption on the client side of the application, while the use of pauses between requests reduces the memory requirements of the server. The disadvantages are the same server-side connection maintenance requirements, as well as connection failures.


After the release of the HTML5 standard and the possibility of using WebSocket I was in indescribable delight and used this protocol very aggressively. WebSocket involves two-way communication between the client and server side, and everything seemed to be going great.
If you think about it, WebSocket keeps an open channel for writing and reading on both the server side and the client side at all times. The percentage of resource usage during the session leaves a lot to be desired. For the client application this is not as critical as for the server one. In addition, the client application should include logic to check the availability of the connection in an idle state.


The main difference between the HTTP/2 protocol and HTTP was to reduce latency by providing full multiplexing of requests and responses, minimizing protocol overhead by compressing the HTTP header fields, and adding support for prioritizing requests and sending to the server. This protocol had another innovation – support for the sub-protocol Server Socket Events.
The new protocol partially corrected the shortcomings of WebSocket. First of all, the lack of a two-way communication allowed for a significant increase in the number of open connections, due to the fact that each connection required far fewer resources.

Unlike WebSocket, it only supports data exchange in text format. This limitation arose from the purpose of the protocol, since most of the needs were related to the delivery of text notifications, similar to Push Notification. This allowed to simplify the protocol of data exchange, for the other tasks you can use WebSocket. When using SSE for feedback we still can and will work with our usual Rest API to send requests to the server.

In my opinion, this is the best way to do client-server communication at the moment and also works over HTTP/2. Server Socket Events provides an optimal balance between resource requirements and performance by providing asymmetric two-way communication capabilities.