Some of us love Androids, some definitely don’t. Yet even for those who love it, this system is far from flawless.

Still the most popular operative system, mostly due to its richness and flexibilty, it loses some appeal when compared to more agile competitors as iOS.
We talked to our Android developers trying to understand what are the major limitations they encounter in their daily work. These are the main flaws they listed.


Android is, and must be, compatible with an infinite number of different hardware configurations. Sadly, that is the very reason it is problematic as well. As much as everyone likes to have an operating system that works well even on entry level devices, this never ending cycle of correction to solve compatibility problems, especially when dealing with very old APIs, is a burden to the workflow of developers, who cannot still guarantee true quality for the customer.

Managing interfaces all times, having to insert infinite checks to ensure compatibility and the exhausting management of the UI are all elements that work against the general compatibility of the system, instead of facilitating it.
Android continues to have a minimal functional support system, which limits the ability to intervene wheere there are compatibility and UI problems.

A system not as open as we wish it were:

In theory, we have a system that can be easily modified by developers, with beta versions of each app and quite a deal of freedom in modifying apps. The reality is quite different: to create a complete app, it is not enough to rely on open source code, but we need to consider also a long series of proprietary codes.
To be able to publish the app in the store, we must accept the entire protocol of the Google package, and consequently the access and their purchase is regulated by Google. The code is open if we consider the compatibility part, but from a development standpoint it’s a pretty duplicitous game.

The Kotlin experience:

It is the Android-specific programming language. In the beginning, Java was used, which was very practical since widely taught at the university, while Kotlin’s learning is left more to the initiative of the individual. Since Oracle sued Google, claiming they stole Java as their programming language, Google develops 85% of their work using Kotlin, (intentionally) poorly supporting Java. It came to the point the latest versions are totally incompatible with those currently supported (we are talking about Java 8 against Java 15).
Kotlin also greatly limits the professionalism of the individual developer, as it is too specific a language that “forces” you to work exclusively with Android. Our people all agree that supporting Java would have been a more functional, and perhaps even more honest, way to go.


Unlike what happens with IoS, in the Android environment the emulator totally “virtualizes” the machine. The problem is that being the emulator rooted in the very same hardware, it suffers the limitations of the very system in which the operation is performed.
With a poor support system, constant crashes and stability that is greatly reduced even with the addition of extra features, the whole thing is not worth the trouble.


The team sees them as lame and generally as a store-copy of the iOS environment tools. Google has spent an infinite amount of time and energy creating features that a senior developer is unlikely to use. Having to spend almost all the time looking for the most useful option between different menus is an unnecessary time and energy consuming process. It is often much easier to write all the codes personally.

User experience:

There is no need to switch operating systems to feel lost. It is enough to switch from an Android phone to another, and we will often have to relearn from scratch how to use our new device. As if that weren’t enough, the aforementioned lack of serious and systematic updates often makes the use of Android frustrating.
Although many OEMs are working to improve the update system, the compatibility of the old phones is extremely low compared to the iOS equivalents, which affects also the resale value of the devices or their recovery. The fact that there are so many versions of Android prevents even the most skilled of developers from having an overview to correct this “malfunction”.

Device’s flaws:

The devices are not lacking in major flaws. First of all, the average lifespan of the very same, is quite lower than the equivalent of iOS devices. The battery is the sore point that creates the most problems, often further shortening the life of the smartphone. Planned obsolescence, poor optimization at the operational level, and problems caused by a scarcely fluid management of updates, very often cause an Android phone to issue good performance for just over two years.
Updates, when they occur, not only cause microdamages that accumulate over time, but make often the OS slow and incomplete. However, being Android an open source system, the continuous changes and variations between all versions force companies to continually revise the operating system to keep up with the times, and this extends the release times of new versions to never.
Last, but not least, is the interaction between the hardware and software components is tricky to say the least. It often happens that there are versions of android that are not optimally supported by the devices themselves. Google does not control the production and integration of hardware and software like Apple does. This is noticeable when you try to insert apps that stress the smartphone’s capabilities the most.

Waving quality:

As it is relatively simple to upload an app to the store (each app can be approved in less than 24 hours), safety and quality standards are often not too effective. It’s easy for quality apps to get lost among thousands of poor versions of them with the same features, and even worse, it makes it easy for unsafe or corrupt apps to be listed in the store. Greater quality control, similar to that operated by Apple, would greatly reduce the risks for the customer and improve the overall quality of the store.

A special thanks to our Android team: Francesco Fornasini (Lead), Marco Mardegan, Alessandro Persiano, Domenico Savino, Davide Pagin, Alessandro Sisto for their contibute to the discussion.

Photo by TheAverageTechGuy from Unsplash.