Why are banking/finance apps so heavy?

Having worked on a couple of iOS banking apps there’s a few reasons:

1. Additional security frameworks to help with anti-tampering, often from 3rd parties who have little desire to decrease their frameworks size. Surprising amount require frameworks for mapping/location, photos, camera, bluetooth etc due to anti-fraud and fingerprinting checks

2. Many bank apps obfuscate their binaries/code which increases size

3. Many have huge backwards compatibility requirements so end up always having older frameworks or multiple versions in some cases

4. Often large number of devices need to be supported as such they may have interface files and image assets for say iPhone and iPad, these can and should be stripped out but often aren’t

5. Many banks also have single codebases supporting multiple brands of their banks and subsidiaries, or for their business vs personal vs premier/VIP/platinum customers, they use asset catalogs etc to reskin each but theres often bloat from the overlap

6. Lots and lots of legacy code which often never gets removed. Many still have Objective-C code/dependencies for example

7. There’s often a surprising amount of functionality in banking apps that goes amiss by most users who only really use it to check their balances, eg Cheque scanning/OCR, biometrics (beyond Face ID / Touch ID), receipt management, business or premier customers may have chat or video facilities with their relationship manager etc

Pretty much all of those apps will use cross-platform frameworks to save costs and bundle bunch of extremely bloated proprietary (paid) libraries. It's not strange to see those whole apps written in web stack and bundling whole Chromium and bunch of large native libraries claiming they "detect unsecure phones" (while mostly just crashing when they see something like Android 13 or iOS 16).

Almost all of them are outsourced as well, so you get the cheapest solution done by cheapest developers combined with box ticking compliance.

Cause they are not tech companies. They use the cheapest labour which gets the job done.

I'll add this just as a reference point. 3 Banking/Insurance apps on my phone:

Home Banking 1: - App Size 129MB - Docs & Data 19MB

Home Banking 2: - App Size 98MB - Docs & Data 8MB

Insurance: - App Size 102MB - Docs & Data 12MB

< 150MB seems somewhat reasonable to me

And since you mentioned other apps: Telegram is 98MB, Airbnb 218MB, Spotify 143MB, 1Password 128MB just to name a few I have on my phone right now. So Around 150 seems about normal.

All three the apps I mentioned are for Italian based companies, not sure if the situation is different in other countries.

They are designed essentially by a committee. What others said about security,anti-*,obfuscation can apply to lighter apps as well.

These apps reflect the complexities of the organization. Each sub feature can have an entirely different stakeholder and not being a tech-first company means outsourcing to a an army of devs that will pile on code for more profit or internal devs who will pile on code upon code back and forth because the stakeholder's vision is rarely is communicated accurately or efficiently to whoever writes the code. And then that work has to go through security, qa,marketing,etc.... back and forth. Essentially, it will probably feel like a miracle that they managed to make a functioning app if you're used to tech-first companies.

It's not only the bundle size for me: the runtime is slow.

Not "React Native with redux rerendering" slow, but "like a slow webpage disguised as app with lagging frames after tapping simple buttons for basic actions" slow.

One data point: I made a banking app (Creator Cash) and it's 37.1 MB on the App Store.

- Used React Native

- More features than you'd expect from a typical bank (card issuing/ management, sending payments, invoicing, CRM of contacts to pay/invoice, push debit to fund your Creator Cash account from your brick and mortar without having to send from the brick and mortar, data viz for earnings by platform, earned wage access aka cash advances, and more)

- Uses Stripe Treasury for BaaS

I could speculate, but I'm not really sure what causes that much bloat in other banking apps.

Zerodha Kite is an outlier. Really lightweight, fast and feature rich app. Has all the bells and whistles, never slowed me down.

Just checked, the app is 34 MB on my Galaxy S10.

Requirements for a banking app (or even a retail app) is not like you might expect on a FANG-type app. Focus would be on functionality, stability, possibly ease of use (but way down the line), and security. I'm guessing management is not too bothered about app size and banking mgmt won't be overly technically focused.

Incidentally I was maintaining a cross platform mobile app for a major UK company. Between Android versions of the fairly ancient framework the app size grew 2 or 3 fold. There were a couple of issues, one was js minification was failing before it was wrapped into a native app by the framework, I think I fixed that in the build file. Also both the ARM and x86 libraries were being included in the APK even though we were only targeting one particular device series. Removing one of these almost halved the file size. It was only really the guy managing the devices and device builds that cared about this, the business wouldn't have noticed.

I also have the Chase app and can confirm it's heavy.

The Chase customer service though, had been excellent. Just thought I'd mention that.

Somwwhere around 2014 the PR dept sent a mail allempoyee@... incuding a 3Mb image.

I don't remember how much we shelled out for our 3PAR SAN, which hosted Exchange data in a CCR cluster, but it wasn't a pocket change AND we had 14000 mailboxes at that time.

"Don't attribute to malice..."

My intuition tells me it's mostly, if not all, security based decisions. Like, the reason that a lock is typically big and heavy and takes a little bit of trouble to open and close.

A similar dynamic seems to play out for apps of health insurance companies, where the typical user with employer-provided insurance doesn’t get to choose the provider

Everything I've read so far has overlooked something.

Assets, and the ability to update them. banking apps are typically pretty simple, where you're essentially wrapping all of the 'core' behavior in another API, and that API is doing all the heavy lifting, and sending JSON like they all do.

I think the real reason is around asset templates, and transpiling

It feels like atleast some of them use the same company or UI framework to build the app. So bloated for one company means bloated for others. Also from what I can see they have lot of third party libraries included for security purposes like detecting jailbroken phones and gathering location based intelligence etc

Many of them bundle with heavy graphing libraries and OCR libraries for reading receipts or credit cards and what not, so they already start off pretty heavy. Then they are often cross platform, making them even bigger. Then add every tracking software under the sun.

The web gets its share of criticism and sometimes its deserved, but it runs on every device, on every screen size and never comes close to the size of an app.

90% of it is anti-root or tracking code

Making small apps requires talent.

Very few banks I've worked with have much in the development department.

what do you expect from a hiring process that prioritizes leetcode over actual experience?