social icon social icon social icon social icon social icon

Testing challenges in multi-platform applications (Part 1.)

According to data published by Statista, in the third quarter of 2023, the smartphone market is dominated by two operating systems – Android and iOS. The third position is held by a category labeled “Samsung.” Considering the fluctuations in its popularity over the years, it can be inferred that it actually refers to BadaOS. However, it’s worth noting that the most popular mobile operating system holds over 70% of the market share, the second place accounts for just under 29% of the market share. All other systems combined make up less than 1% of active smartphones.

If we apply a filter on the chart containing the aforementioned data, excluding platforms that have lost developer support and haven’t had any practical use other than hobbyist purposes for years, it will reveal that Android and iOS are the only operating systems worth developing commercial software for.

One might think that such a situation significantly simplifies the process of creation and subsequent testing of applications. Well, it probably does. However, we still contend with multi-platform considerations, which, in turn, come with certain challenges.

How to develop applications for various mobile platforms?

The first challenge developers face is selecting the right tools. Primarily, compiling an application for iOS requires a computer running macOS. At least, that’s the only legally compliant solution according to Apple’s licensing. This means that for teams working on the same program across different platforms, it’s necessary to either have two ecosystems coexisting (one based on Apple hardware and the other composed of PCs running Windows or Linux) or standardize the hardware park. However, neither of these solutions is without its drawbacks.

The next decision developers face is choosing the right programming language. Fortunately, here they can choose from a wider range of options. Is it better to opt for a technology supported by almost all existing platforms (even the forgotten ones) or something dedicated to a specific system?

The native language for iOS is Swift, while for Android, it’s Kotlin and Java. Of course, there are appropriate tools that allow the use of these mentioned technologies in a multiplatform context, but only to a limited extent. The Swift compiler for Android supports only certain processor architectures, and iOS lacks a native Java Virtual Machine. This issue can be partially bypassed by writing code in one of many other languages supported by both systems. However, it’s not as straightforward as it may seem. Applications aren’t standalone; they rely on libraries implemented in the operating system they run on. Even if the program’s logic is written in one of these universal languages, including modules in Swift or Kotlin is necessary to access memory or specific processor instructions. Gone are the days when the entire home computer market was based on the MOS 6502 chip. In the ARM processor world, numerous microarchitectures exist, so the familiar A17 Bionic chip from the iPhone 15 is only partially compatible with the Snapdragon 8 Gen 2 powering the Samsung S23. And that’s just the beginning of the problems.

The application needs to function

I would like to say that in the previous paragraph, we discussed the entire issue of code compatibility between platforms, but that would be untrue. In reality, the topics mentioned above are just the tip of the iceberg. The technical aspect is crucial, but one cannot describe the differences in programming for different platforms without considering the ideological aspect.

Apple places a strong emphasis on optimizing code. They set a good example themselves by removing drivers and procedures from the system that are no longer necessary. As a result, subsequent iterations of iOS, released annually, have relatively minimal backward compatibility baggage. At the same time, this approach somewhat compels developers to leverage new technologies and adapt applications to changes in the system.

The fragmentation of the Android smartphone market is much greater than that of iPhones. In May 2023, as much as 81% of Apple smartphones were using the latest system version at that time, while versions older than two years were present on 6% of active devices. For comparison, the latest version of Android was present on less than 37% of devices in October 2023, and over 42% of smartphones were powered by the green robot in a version older than that from 2021. This high percentage results from the lack of top-down regulations enforcing sufficiently long update cycles. The consequence is the necessity to artificially maintain backward compatibility, which not only complicates app development but also optimization.

It’s essential to note that Google somewhat sheds the responsibility for ensuring the stable operation of their product, which is inevitable given such a vast number of configurations. Developers must ensure that their created programs function well on low-tier MediaTek SoCs as well as flagship Snapdragons. They need to display correctly regardless of screen proportions or shapes (including curves, holes, and notches). In the case of iPhones, this is somewhat easier as there are currently fewer than 10 display configurations, and programs have several defined ways of displaying interfaces depending on the model.

For me, it works differently.

We’re moving on to the last of the main differences between iOS and Android applications: navigation. Steve Jobs adhered to the principle of ‘one button – or fewer.’ Hence, the iPhone used a single button for navigation, used to summon the home screen. Other actions, such as going back, were initiated in a way defined by the creators. Moreover, usually, it was placed as a touch-sensitive area in the top left corner to maintain consistency within the system. Gestures started to be implemented quite early on as well.

In comparison, Android has always used a dedicated back button. The context menu wasn’t summoned by a gesture or long-press but by clicking the appropriate icon. Moreover, Google’s system implemented widgets much earlier, and to this day, their handling is much more advanced than in iOS. They can do more and are more flexible.

Many differences in usability stem from the history of both systems. Android started as software for digital cameras; initially, it didn’t even have an implemented on-screen keyboard, and buttons were its default way of interaction. On the other hand, the iPhone interface was designed for touchscreen interaction.

How to test applications for such different platforms?

I hope that reading the above article will facilitate understanding the complexities of creating multi-platform mobile applications. Now that you know what to pay attention to when creating a program that works on different mobile operating systems, you can move on to the next stage. Namely, considering the challenges faced by testers of multi-platform applications. Stay tuned for more on this topic soon on our blog!

GDPR Cookie Consent with Real Cookie Banner