Look at a bank app on an Android phone and then on an iPhone. The interface seems like it should be similar, but that’s not always the case. The positioning of buttons may be different. The back swipe can even be different. One version might have a feature that another version has been waiting months to receive.
Differences like that are rarely a mistake. They stem from business decisions made before anybody writes any code.
One app or two?
There are architectural differences concerning Android and iPhone devices. Apps in Android are usually written using Kotlin, whereas an iPhone app is written in Swift. The two operating systems have different ways of rendering menus, managing notifications, and have different expectations for apps to conform to their respective styles.
This means when a company develops an app for both operating systems, they have to make a choice: they can develop two different apps that work independently on each system, or they can create a single app that is meant to be run on both systems.
Developing two apps requires two teams and produces two separate sets of bugs, at roughly twice the cost. Most companies consider that a reasonable return, because users receive an app that looks like it was genuinely designed to run on that specific system. The applications that users describe as polished are generally the ones built this way.
Each shared app is cheaper and lands faster, as not all features have to be implemented individually. The downside is that the app might feel slightly disjointed and foreign, like an improperly translated shop sign.
Flutter draws its own screen
Flutter is targeting the shared-app issue in an unconventional way. Instead of relying on Android and iPhone to provide the controls and menus, Flutter draws everything. Essentially, each app brings its own paintbox.
This is why Flutter apps look almost the same. Same font, buttons, and animations on both a Pixel and an iPhone, and frequently on the web. Companies that enforce strict design standards appreciate this. If the design team spent a year deciding on a specific shade of orange and a specific corner radius for buttons, Flutter will apply that choice to every screen.
You can feel the difference in small things: text selection, scrolling, or the animation when opening a menu. While Flutter imitates the conventions of each platform, those imitations are never quite exact, and many users cannot articulate why an app feels off to them.
Kotlin Multiplatform works as a dial
Kotlin Multiplatform was developed by JetBrains, the company that created the Kotlin language, and Google announced its own support for it at Google I/O 2024. From a functional standpoint, it diverges from Flutter due to one important factor: the degree of shared code. A company can choose to share a little or a lot of code.
Most teams start with the unseen parts of the project: their payment failing logic, data storage, data requests to the server, etc. These components are coded once and then used by both apps. Meanwhile, the buttons and menus are built separately per platform using the components provided by Apple and Android. This is the reason apps created in this manner tend to feel native to each platform.
Teams wanting to share more can use Compose Multiplatform to share even more components. Beyond this point, the app will draw its own screens similar to how Flutter does, and will introduce the same kind of awkwardness that comes with it.
The draw is the dial itself. A company with a large Android team and years of code written in Kotlin can share the invisible portion of the code and leave the rest as it is.
Why Google backs both
Google builds Flutter and also backs a competing method that is outside of its ownership. It is strange, but if you take a look at the two, they address different issues.
A company that wants a single look everywhere and wants it quickly will benefit more from using Flutter. A startup with a team of eleven and no design system will gain a lot from it.
On the other hand, Kotlin Multiplatform is more suitable for a company that already has a large Android team and has years worth of Kotlin code. Sharing the invisible part of the code is a modest change to make, whereas starting over in Flutter is a substantial one.
Both are continuing to ship updates, and no announcement is expected about either one winning. As for those wondering which method will become the standard, time will tell.
Who actually writes all this code
With all the frameworks being discussed, it sounds like every company has a mobile division. Most don’t.
A regional bank may employ a couple hundred people in tech and not a single one of them has ever launched a Swift app. A retailer might have an excellent web team but no one who understands what Apple’s reviewers are looking to reject. The process to hire a senior mobile engineer spans months and the person who gets hired typically wants to work on something more stimulating than a loyalty card screen.
Hence, a considerable portion of the applications found on any phone were developed in whole or in part by people outside the company. Some companies utilize local agencies. Others bring dedicated engineers from companies like Full Scale, who staff US companies with engineers from the Philippines for iOS and Android app development and keep those engineers on the client’s team full time rather than delivering a finished product and disappearing.
This explains a lot of the observations made by phone owners. An app that has been stagnant for eight months and then makes a substantial jump has probably changed development teams. An app that has the Android version lag behind the iPhone version by one or two releases probably has more iPhone developers than Android ones, which is quite common, as for many years the revenue came through the Apple store first.
Implications for the apps on your phone
There is little that phone owners can do other than identify the pattern once they know that it exists.
An app that appears identical on all devices, right down to the fonts and toggle switches, is probably using Flutter or a similar framework. An app that has a clean, polished Android experience with appropriate menus and gesture support has either been built using native Android development or shares only the invisible portion of its code. When a company is obviously biased towards one platform, it usually indicates where the engineers are.
For more than a decade the industry has been debating the correct approach and has failed to reach a consensus. This is the honest reason why two phones in the same household show two very slightly different versions of the same thing.
Frequently asked questions
Is a cross-platform app always going to be worse than a native app?
Not necessarily. A well-designed Flutter application will outperform a poorly designed native application every day of the week. The difference is almost entirely in the details and most users will be unable to articulate what bothers them about it.
Is it possible to tell what approach an app uses?
Not always. If an app appears to be pixel-identical across both Android and iOS systems, including fonts and toggles, then they are most likely cross-platform. Native apps have system-specific controls, which is why you’ll see micro-differences in the two versions.
Why is the Android version often developed later?
It usually comes down to staffing and revenue histories. Teams developed for the Apple store first for years, as that is where the money came from, and this tendency remained long after the reason for it.
The post Why apps behave differently on Android phones and iPhones appeared first on Android Headlines.
​Â
