Ask HN: Why are banking/finance apps so heavy? | Hacker News Reader

Ask HN: Why are banking/finance apps so heavy?

45 pointsgffrd51 comments

I have an iPhone. Of the 10 largest apps on my phone, 4 are bank/finance apps … Robinhood clocks in at 480MB, Chase at 350.

What about these apps demands such a large footprint? (Larger than say Notion, Amazon, messaging, navigation/maps, etc etc)

View on HN

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

8. The app is built by a large consulting company and no-one gives a shit about the package size because the client isn’t paying extra for that (or “we will put it on the backlog”, and then it’s never addressed)

You didnt really give a new reason, you just said why the above reasons might occur.

I guess the reason would be that humans are lazy.

And its not a revenue generator if size is smaller - most customers wouldn't know how to determine the app size and wouldn't know what it means even if they saw its size.

Not necessarily. I was implying that part of the problem was that the applications are made cheaply and quickly, which necessitates the use of huge frameworks and libraries that make this possible. And then, because no one with decision making power cares about the size so much, these are just left in place instead of selectively rewriting or stripping the over-large parts to shrink the package.

This is distinct from any “feature-enabling” type bloat IMO, because it’s more “development style enabler” type bloat instead.

In summary: User Experience.

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.

Thinking exactly the same thing. Plus... banks are already worth billions and have little reason to invest in things that doesn't effect their bottom line when they are already printing money.

That, and quality of the app is not really a decision that drives selection of a bank. I've been told by a certain EU bank marketer that "if we get them before 18, they're ours until death". Which is a bit of an exaggeration, but it's telling about just how sticky the customers for banks are. Switching out accounts and losing those preferred mortgage deals is a big deal.

Yup! Great example you can see it super quickly is SAP... (not a bank but $170B+ value and little incentive to improve the quality)

Such arrogance will not go unpunished. Banks have two ways to differentiate. Better app and better prices. The prices they can offer is based on their degree of automation and the quality of their risk models. In other words, they are tech companies and they better act like it.

This is so true. Long ago I had a telesales warm calling job for a mortgage product. The number of customers who had all their financial services from a single one of the big few (U.K.) banks was telling

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

I agree with you. Let me expand my thoughts: I can't say with certainty, but here's a guess: I've certainly seen this behavior from more junior devs who don't have a senior to coach them and I've also seen this commonly when the software is outsourced to the cheapest 3rd party contractor who has no real skin in the game other than getting the product delivered to the client.

What I've observed is that in both cases the devs will use npm/nuget/yarn/favorite-package-manager with a bias for pulling in lots of packages, which all have lots of dependencies themselves. There ends up being a lot of bloat. Lots of libraries that are either not in use or really aren't needed.

Both scenarios happen frequently to companies that are no tech companies first.

They may also be dealing with old / proprietary tech stacks—due to regulatory, industry, or security realities—that make using modern standards very cumbersome / impossible.

Robinhood is 100% a SV tech company and does not use "the cheapest labor".

Per the manifest, 450MB of the Robinhood app's weight comes from "needless animations"

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.

I'm in the US. Interesting to see such a discrepancy in app sizes … here's what I've got:

Home banking 1: App 382MB | Docs 10MB

Home banking 2: App 346MB | Docs 5MB

Home banking 3: App 302MB | Docs 38MB

Finance 1: App 265MB | Docs 212MB

Finance 2: App 301MB | Docs 16MB

Insurance: App 204MB | 3MB

That brings the average size to 350, or 300 for app only. I know it's not apples to apples, but kind of surprising to see such a wide gap.

Maybe it's all the advanced ML code that banks are running on our devices … </s>

[edit for formatting of list items]

This is honestly very interesting.

Why do you think that’s the case?

Bigger and more complex apps perhaps?

Maybe US banks need more functionalities in their apps?

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.

been hearing lots of praise for Zerodha. Their engineering blog is quite interesting.

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

so 42gb?

    3Mb * 14000 = 44040192000

Yep.

Also, CCR and RAID5^W, with a cluster/page inefficiencies:

    3mb * 14000 * 1.2 * 2 = 105696460800 / 1Gb = 98.43.

A base 7200 FC head in 2014 cost ~$40k for 8x1.2Tb SAS 10k (PROMO, retail was $78k), so

    40000/(7*1200) = $4.76/Gb (RAID5 of 8 disks)

So the cost of just storing a completely unneeded ONE E-MAIL which wasn't even read by 99% of personnel:

    4.76 * 98.43 = $468.52 (at least)

NOT including tape backup costs, satellite transfer links, storage on the local machines, costs of receiving the message on handsets in roaming.

Edit: I don't remember the specs (we had 1 head with 3 JBODs?), but back when I counted I got around $2k for this. I repeat: for storing ONE e-mail.

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.

Good analogy! And that makes logical sense …

My first thought was "I wonder if lockmakers are really protective of their methods / manufacturing process," but realized this information would matter little: the point is that it doesn't matter if people know exactly how the lock is made, because it doesn't make it any faster to open it, and I've only got 2 hands and 24 hours in a day and the time just isn't worth the risk.

What exactly do you think it's "locked" into a mobile app that shows a few web templates and forms? :)

the overhead of not moving too fast or too recklessly

that mentality of totally buffing your RPG character before attempting the final boss

viscosity of decision making

I hope that's too vague and metaphysical

That’s a nice sentiment, but based on what I’ve seen of how this particular sausage is made, I’m willing to bet it’s literally that no-one with the right amount of influence cares enough about shrinking the package size. So it just stays like that.

Ah. Budegtary laziness.

> Like, the reason that a lock is typically big and heavy and takes a little bit of trouble to open and close.

The sad part is that making the lock big and heavy usually only makes the intended uses of the lock inconvenient; the unintended bypasses don't care about those.

I mean more metaphoricaly big and heavy. Like, putting in a password is costly. It has to live somewhere. It requires effort. It takes a moment. You have to memorize something. It causes a moment in the flow of utility.

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

I was thinking earlier: I wonder how different the landscape would look if customers had the freedom to choose their banking "front-end," linked up to their brick-and-mortar.

Insurance is a great example of the same thing: horrible apps that only do 3 things but are 400MB.

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

The client should be considered insecure as it runs on a device the bank does not control, and their backend should be built with that in mind. So why does it matter if the device is jail broken or not?

Yep i agree with you and I don’t know why they do it, but I have run into one bank app that doesn’t let check deposits on a jailbroken phone

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.

In my experience, I like desktop applications the best (perhaps because they are developed with purpose), then the web, and mobile apps the least.

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?

Reply on news.ycombinator.com