Mobile banking: expert guide to choosing the right technology

With insights from

Mo Ramezanpoor

There are already plenty of articles on the internet around mobile technology choice on the internet. Our aim with this article is not to re-iterating what’s already out there. Rather, we want to share our insights based on years of experience developing apps for financial service providers.

There are no simple pros and cons tables in this article. We will instead guide you through technical and organisation topics to explore that we think are particularly impactful. We will then share our technology recommendations for a few different use cases.

Why no comparison tables?

If you have already looked at characteristics of mobile technologies, you may have heard statements like these:

native apps are more secure
cross platform apps are faster to implement
hybrid apps let you use the same code on web and mobile

In a general context these statements apply. And their simplicity is valuable as it can give you a flavour of the various technologies very quickly.

The problem is, if we scrutinise these more closely, we should say “it depends”.

It’s very likely not faster to implement a camera app like Halide as cross platform. And if you’re writing a shopping list app then any mobile technology can be secure enough without much effort.

We often see that reliance on these general statements leads to attribution substitution: the question businesses really care about is “which technology is best for us?” But this is not an easy question to answer. Instead, subconsciously they are replaced with easier question like “which technology lets us share more code”, or “which technology has the sleekest UI?”.

That’s why when choosing a technology, we first look at the requirements and then see which technology is a better fit. More specifically, in this article we look at how these requirements affect the comparative Return on Investment (ROI) of different technologies.

How can requirements affect comparative development cost?

The topic at the heart of mobile technology choice is code reuse. When developing an app natively you can be sure to take the most advantage of each platform it runs on. The downside is you have two entirely separate codebases. All cross-platform or hybrid technologies are designed to allow for code reuse (or having “one codebase”).

As long you’re writing “the same code”, shared code will make it more cost-effective. But in some cases you may end up with more code or more complex code.

graphic with 4 sections: upper left side - "native" with "Ios app" and "android app". Upper right "KMM" with: ios App, android app and "shared". lower left: "Flutter" with two native buckets and on the lower right: Hybrid with "Web app", with two web view and native buckets. — Graphic: How different technologies achieve enable sharing. Key question to answer is which option this leads to a codebase that is more efficient to develop and maintain given the requirements.

Using platform API

Unsurprisingly all platform functionality is made available through native tooling. Non-native technologies provide equivalent functionality for common use-cases in which case lack of direct access to the platform API is not an issue.

But no none-native technology has full coverage. If you need a functionality that the framework of choice doesn’t cover, the app must write native code for each platform, plus more code to “bridge” the native functionality for use within the non-native framework.

This not only means you have effectively three codebases instead of one, but is also more complex code that is harder to develop and test as is written in two, or possibly three different languages and should be tested in a variety environments.

As an aside, the same argument also applies when integrating third party services. Some may offer SDKs for popular frameworks like Flutter and React Native, but as a baseline, the SDKs focus on their native API first.

Examples:

Secure storage and biometric APIs should be bridged from native code
Siri and Widget integration on iOS must be in Swift
Web views used by hybrid apps can’t run in background, requiring custom solution

Screenshot einer Netaxept-Zahlungsseite für Norgesbuss Ekspress AS. Der Betrag beträgt 249,00 NOK. Ein Feld für die Eingabe der Kartennummer, des Ablaufdatums (01/2024) und des Sicherheitscodes ist zu sehen. Ein grüner 'Betal'-Button (norwegisch für 'Bezahlen') befindet sich unten. Die URL in der Fußzeile lautet 'epayment.nets.eu'.

Replicating platform functionality

Especially when aiming to have a single codebase for user interfaces, non-native apps may offer something that looks like native UI, but in fact is a replica.

When using Cordova/PhoneGap, it’s entirely up to the app to replicate system UI. Frameworks like Flutter and Ionic provide a UI toolkit for the app use which work in many cases. But just like the above, they don’t cover everything native UI can do so you may still need to write some code for this.

Regardless of whether this code is in the framework or in the code you write, keep in mind that iOS and Android UI change every year, increasing maintenance of the codebase.

Image: A live payment system still replicating old iOS look.

Reconciling platform differences

At the risk of stating the obvious: different platforms have different features. Even similar features may behave differently on each platform.

When writing code dedicated for each platform, it only needs to consider scenarios that may happen on that platform. Shared code instead may be more complex as it caters for all platforms.

Impact of financial services requirements on development cost

We looked at three ways that may change the relative cost of one technology compared to another. We can see that when the requirements in any given area (like security) are relaxed, sharing code has a lot of value. As we get stricter, this advantage tends to diminish. The trick is in detecting the tip-off point where one technology might be more suitable than another.

In this section we look at some common requirements in financial services and see how they affect this balance.

Security
Mobile security features often need to access platform API not integrated in non-native development frameworks. This increases both cost and risk of bugs in a sensitive part of the application. Requirements for some FSI apps is not so strenuous to affect technology choice. That’s the case, say, for a portal to show performance of pension funds. But security is critical in banking apps, or apps providing payment service. In this case, a native implementation may have the upper hand.

In Europe, virtually all banking apps must be compliant with PSD2 or an equivalent regulation. PSD2 requirements can be met in different ways, but practically all modern solution designs have three security measures in common:

Runtime security: Using a combination of solutions (like RASP) to secure the environment the app is running on: Can we see signs that the mobile device or the app code is tampered with.

Device binding: During an initial setup, apps create credentials stored on special hardware on mobile phones that can provide cryptographic guarantees that a future request is coming from that particular phone.

User presence check: Apps use biometric checks (like Face ID) to create cryptographic proof of the presence of the user when doing something in the app
While the high-level concept for these is the same on all platforms, the implementation detail varies. Therefore, regardless of the overall technology choice these features will need specific implementation for each platform. Therefore, whilst achieving the same security features is possible in all frameworks, they can be more costly to implement using cross-platform technologies.

When it comes to runtime security, Hybrid apps have a bigger disadvantage as they run interpreted JavaScript code (instead of pre-compiled code) and therefore there are additional attack surfaces. For one of our banking clients that had a hybrid solution we had to develop a comprehensive solution to restrict what the JS code could do and had access to (e.g. the JS code never had access to the raw credentials).

Finally we highlight that Inadequate Supply Chain Security is one of the top mobile security risks. Whilst cross-platform technologies are generally robust and well-maintained, they are sizeable frameworks and may introduce vulnerabilities in a way the development team has not anticipated so the risks should be considered.

More problematic in our opinion is use of third-party code with limited oversight in security-sensitive code. We have found many examples where these either have vulnerabilities or are not as strong as they can be because they aim to be general-purpose. Use of third-party code is not unique to cross-platform technologies, but they are particularly susceptible to it as use of third-party plugins is the often-recommended way to avoid having to implement the native-layer security code we mentioned above.

Local_auth is the most popular solution for using biometrics on Flutter. However, we don’t believe this framework is secure for most use cases that need biometrics—certainly not for banking apps.
Accessibility
Implementing basic accessibility is straightforward in most UI development frameworks. Unfortunately, even the most popular of frameworks that replicate system UI offer all capabilities of the native UI, so their advantage diminishes as the accessibility requirements for a product get stricter. We therefore recommend checking which technology can effectively deliver the level of accessibility for your needs.

From mid-2025, banking and e-commerce services in the EU must comply with the European Accessibility Act. This normally means meeting WCAG AA accessibility requirements. Here are a couple of examples of challenges when using non-native UI:

Resize Text: Apps must provide a way for the font size to be increased. One difficulty on mobile is not all items have the space to increase their size – tab bar would be a typical example of this. iOS has a built-in solution that works with native elements and low-vision users rely on. When using non-native UI, the app must either recreate this effect or rely on a custom solution.
Orientation: Apps must support landscape orientation. Native UI, as well as major cross-platform frameworks have mobile-focused solutions for this. However, fixed viewport layout is not the “standard” way of achieving responsive design on web. Therefore, hybrid apps need significant effort to design UI that fits at home in a mobile app.

Going beyond compliance, mobile platforms, and in particular iOS, have many built-in features such as providing button shapes and labels, preferring crossfade transitions, and Audio Graphs. These features are typically not directly supported in cross-platform frameworks, making it costly to achieve the same level of accessibility. Not all businesses are in a position to aim for this level of accessibility, but it is a trade-off you should be aware of when choosing your app UI technology.

Common app features

Finally, here we list some common features we see as relevant for banking and other financial app. None of these features on their own rule out any technology choice as it is possible to work around the limitations. But taken as a collection, those workarounds add up, can influence the tenor of the engineering needs, and therefore make some technologies less viable.

KYC

Modern banking onboarding journeys take advantage of mobile features to meet Know Your Customer regulation. This includes camera and microphone access, NFR, and on-device imagine recognition. Developing this non-natively can affect both quality of data and user experience. Solutions providers like Onfido develop their core product natively and then provide wrappers for cross-platform frameworks. They recommend against using web journeys in mobile apps.

Wallet

Apple and Google Pay integration needs a separate solution for each platform. They are less affected by the technology used to render the app UI (compared to KYC or Widgets) but need access to native API. Solutions such as Visa’s In-app provisioning only provide native SDKs.

Open banking

Open Banking authorization journeys can be an attack vector if not secured properly. They rely on platform-specific details such as how the app is associated with the bank’s website. They solution be implemented in any technology, but needs good platform knowledge in the team.

In-app chat

Chat features normally rely on push notifications and background processing. These can be used in frameworks like Flutter and React Native using “plugins” but require good platform knowledge to design correctly. Hybrid apps would need a custom solution as their web apps can’t run in background.

Widgets

Widgets on both iOS and Android need to be defined natively. They can delegate work to cross-platform SDKs, but they are both less efficient and more work to implement than a native solution. Hybrid apps would need a custom solution as their web apps can’t run in background.

Assistants and intelligence

Increasingly, mobile platforms offer non-visual interfaces for the apps, like shortcuts, automations, and integration in voice assistants. Like with Widgets, native apps are at an advantage when it comes to using these capabilities.

Organisational considerations

In a previous article we discussed how a fit-for-purpose architecture also takes the team and organisation’s need into account. Similarly, which technology is the right choice can depend on the organisation.

Organisational considerations are more nuanced than we can properly do justice in this article. But to help demonstrate how it affects the technology, we look at two ends of a spectrum:

A small startup that wants to offer a new and innovative “bank-like” service using prepaid or credit cards.
An established bank with existing user base, mobile app, and online banking. They want to modernise their app.

Budgeting landscape
For the small company, likely the total budget for app development is a key concern and supersedes developing “nice to haves” or speculative engineering to prepare for growth. It therefore makes sense for them to maximise code reuse to reduce cost as much as possible and deliver as fast as they can.

The Established bank on the hand, has more scope to consider return on investment and long-term safety of investment. For them, it may be important to be fully accessible and localised from day one to match their brand and corporate values. Indeed, this can increase their market by attracting customers who may otherwise bank elsewhere.

We’ve had clients in the past that try to combine the best of both worlds: they’ve used lower cost solutions to reach an MVP product faster, and then re-platform to a native app with stricter cross-functional requirements.
Organisation size and complexity
The startup is lean. The app development team has the normal roles like product owner and designer, but the decision-making circle is smaller and organisational rules are more relaxed.

The team at the established bank, on the other hand, has a more challenging task. The product should be reviewed by branding, legal and compliance. Architectural designs need to be presented to architectural governance board and approved by the IT Sec team. The engineers need to rely on central teams at the bank for their tooling and infrastructure more often.

In addition to this, the tech landscape is more complex as the app needs to interface with many backend systems that themselves may be evolving as part of other programmes. On the mobile side, the team needs to find a solution to migrate the users from the old codebase to the new codebase – be it in the same user-facing “app” or a new one.

For a complex organisation, frontend engineering is a smaller fraction of the app development cost. Not only that, but investing in technology can help reduce overhead and overall cost of the project.

We can see these difference in cost in our projects. For a small app development project frontend engineering can be around 30-40% of the overall cost. For an app developed in a big organisation this falls to around 10-15%.
Discover Our Software Solutions for NHS Complexity

Our recommendations

When it comes to choosing a mobile technology, as we said from the beginning, “it depends”. But if you allow a bit of generalisation, we can share what we recommend based on our experience.

Banking apps

We recommend banks to develop a native app, or at least keep a minimum core of the app as native. They have many different touch points with native APIs which can be both risky and expensive to manage through framework plugins.

It is still possible to reuse code whilst maintaining a native core:

The native core is responsible for security and overall app coordination
App logic can be shared using a technology like Kotlin Multiplatform
Sharing UI code is still possible by using web technology or Compose Multiplatform – though you must establish a clear strategy on where and how these should be used. Currently we recommend considering these as a stepping-stone towards fully native apps whilst reducing initial cost and time-to-market.

For banks that are migrating from a different technology, the native core gives the best opportunity to manage risk of migration and make it as incremental as possible.

80% of top UK banking apps are written natively. This applies to both established and new banks. The remainder use React Native or Hybrid technologies.

Other financial apps

For apps that don’t have the complexity of a full banking app, and that don’t need to comply to stricter regulations of a payment service provider, the range of options is wider.

If you provide an app-only service, or if you expect clients to use your app frequently, cross-platform frameworks like Flutter or React Native may be a good fit.

If you also have a web portal, a hybrid solution might work well for you – especially if you expect interactions to be infrequent or lightweight.