Mobile Banking: A Guide to Technology Choice

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.

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%.