It could just be simply about a bad build system that does not efficiently trim out unused dependencies, or people are using unnecessary dependencies in the first place. Which happens all the time everywhere.
And to be honest, I can totally see why this is happening. Santander does not have a lot of incentive to improve this. The distribution of the app package is done by Apple, and they don't charge you by what your file size is or how much bandwidth this uses. They charge you a developer fee and 30% IAP. If there is no (direct) extra cost, and trimming the file size could mean additional work on the developers and may cause things to break if not handled well, someone could be blamed for it. So why take the risk.
And actually, it is possible that nobody internally at Santander ever looked into this problem.
How do I know? The build system at my company sucks -- tons of waste of build time, memory use, disk space, debugging time, communication etc. I myself have brought up many of the issues. Nothing happened. Why? Because things are working, and nobody wants to do something when there is only risk but little benefit (to them).
As of why people aren't being rewarded for saving CI costs, I'll leave that as an exercise for the reader.
IMO Apple is partially responsible for that - in that linked twitter thread the mentions:
"We've outlined this before in previous tweets, explaining that these binary symbols used to be automatically optimized by bitcode, which has since been deprecated by Xcode 14 ",
"Xcode 14 deprecated bitcode by default, which we've detailed a few times.
Basically, bitcode optimizes production builds, partly by stripping away unneeded metadata (binary symbols)."
Something tells me Apple is quite happy with that - easier to sell iCloud subscription or upsell iPhone with bigger storage and also easier to scream to EU that running infrastructure for AppStore is very expensive with those heavy apps so they deserve their 30% cut.
Similar story is with Photos storage - so hard to recompress them to smaller - lots of very shady apps in app store. I really think Apple do this on purpose to sell more iCloud
Photos wouldn’t be a very good photo storage service if it was wrecking my photos by compressing them. I want more detail, not less. Also, you can choose photo quality very easily. Settings > camera > formats > photo mode
There's no need to wonder what it "could" be about, it's all explained at the link. :)
I reported this size issue to them during beta test, and they ignored it. At the time I was on a limited cellular plan with no home wifi, so 600MB was a huge bullet. BTW, the old app was ~180MB and the one before that was ~50MB.
It wouldn't take much engineering effort to address the size issue, but somebody in a position of power would need to care about it.
> Santander does not have a lot of incentive to improve this.
There is some incentive. A not-insignificant percentage of users won't be able to immediately install it without going through the hassle of finding something else to delete first to free up storage space, adding onboarding friction.
It's ridiculous, and many websites are just as bloated.
Not for the first time, I blame CSS, and the marketing-driven economic incentives that popularized it. Too much graphic design turned the web from something resembling a living book to something resembling a glossy magazine, along with the ads and the promotion of sensation over substance. I sometimes find myself missing TUIs and being able to meaningfully customize your user experience.
But this was always unavoidable, because it turns out non-HN users like glossy magazines. So the internet will always either be niche and text-only or glossy and popular
On the plus side, my latest app (a browser for multiple Japanese shopping websites with unified search, and an icon!) is just 200KB (400KB installed). I use zero frameworks to achieve this. I also target iOS 15 just for kicks.
Which iPhone has microSD support? Macbooks only recently (starting from from m1) have sd card slot and only most expensive macbooks pro. 1-2 years ago they were still selling macbook pro starting with 128GB ssd and of course they are soldered. At one point when buying iphone they allowed you to choose one with 64GB or ... 256GB even if I wanted 128GB.
And for me its no problem - I sync photos with my macbook photos and remove from phone. But not everybody has Macbook. Support for syncing on windows used to be totally terrible - there was no syncing just download all photos with arbitrary names and folder names.
On top of that when syncing iphone with macbook by accident you forgot to check on this small box "delete synced medias from iphone" you will have to delete all photos one by one selecting... there is not option like delete all photos - ridiculous.
If you're using a device which allows storage extension using microSD cards - i.e. if you're using Android - that is a solution but Apple iOS devices do not offer such options. You get to buy the same storage for a far higher price without the possibility of extending it later on, better bite the sour apple and pay that ridiculous price for the 512GB or 1TB version now because you know you'll be even more sorry if you didn't later on.
I feel like it’s either this, or some super optimized app that weighs in at <10 MB and does what it should perfectly. I really wish there was a middle ground.
Google Docs/Sheets/Slides are particularly infuriating. I’m pretty sure they all contain 90% identical code and assets.
The Affinity apps (Photo, Designer, Publisher) are all 95% the same, too. They are basically the same shared frameworks with a slightly different UI. They can all open the same documents, for example. Whilst you can only create a table in Publisher you can edit it in any of the apps. Ridiculous. But then they get to sell you the "same" app three times.
I am old enough to remember times when 100 computer science students did their exercises on a VAX 11/750 with 4 MB of main memory. Admittedly it was a bit laggy when all 15 terminals were in use during peak hours. I don't remember disk sizes.
Now main memory is a different story than application size. But in most cases your main memory must be significantly bigger than size of a single application. So for that 4 MB VAX running a 2 MB application might be suitable. Let's reduce the 15 users to one, that's progress over 4 decades...
Now the question: What can that 2 MB VAX banking application not do, that the 613 MB iOS application can?
* Cryptographic operations have developed. But I am not aware that those used by a banking application are particularly memory hungry.
* The screen resolution is different, but banking on 80x25 characters would work just fine at least outside of CJK.
* The touch input might be problematic, so we would need to use a Blackberry or Nokia Communicator with physical keyboard. That would not only be a disadvantage IMHO.
(The last 2 items are largely influenced by the operating system. But of course that would need to be very different to run on a 4 MB computer.)
What else am I missing in this thought experiment? Honest question.
1. Image recognition: many banking apps offer support for transfers via QR codes.
2. I18n: the app may not speak your language, but you may set the display names of your savings accounts in Unicode.
3. Branding: text doesn’t offer much there, high resolution GUIs can offer a lot, not just a logo or colors, but also custom fonts, icons, images, interaction scenarios etc.
4. Telemetry: well, that’s just a lot of extra logging code.
5. A/B testing support: code for running experiments as well as code and assets for A and B variants.
6. Just a lot of business functionality that is much cheaper to develop today, including things like onboarding flows, chat with customer support etc etc.
That’s what comes to my mind immediately. Probably there’s plenty of other things.
> 1. Image recognition: many banking apps offer support for transfers via QR codes.
Accepted.
> I18n:
Outside of CJK, every new language takes a couple of kilobytes. You cannot explain megabytes with that.
CJK I already mentioned, it might be beyond reach? But actually in 1986 I saw the first IBM PC with a Kanji UI. I have no idea how much memory it had. But I might guess that might still have been hardware where 640 kilos(!) is more than anybody would ever need? Not sure.
> 3. Branding
I couldn't care less as a customer. The bank should offer good rates and flexible service. They can keep their branding.
> 4. Telemetry
Everything the user can do on their qwerty can be logged with kilobytes of code.
> 5. A/B testing support
Same here. Remember our interface is 80x25. Many variants of that fit into just kilobytes.
> chat with customer support
I started to use IRC in 1990. Don't remember how big the clients were and cannot quickly find a reference. I would guess 100 KB max, probably less. Using a camera would not be possible, we had that already under QR.
Living in a country where checks have been abandoned some 30 years ago, I can only shake my head about the irony. Scanning checks with an alleged high-tech device...
> All the bells and whistles of that UI come at a large cost - memory.
I’m not sure that’s true. If they tried they could have made an app with loads of bells and whistles that’s 10x smaller (unless we’re talking about a lot of media content). It’s just not something many developers care about due to various reasons
You had me until the "users don't care". I'm a user and reported this issue which resulted in the post we're discussing. Bank management/developers don't care is the issue.
What else am I missing in this thought experiment? Honest question.
Even though I/O was slower on the VAX, with the smaller number of bytes going back-and-forth, it would probably be snapper than a modern app.
I remember when computers were advertised as supporting eight concurrent users running spreadsheets at the same time on a single machine with 64K of RAM. Often off of two or four floppy disks. No Winchester drives.
64K of RAM was stupid expensive at the time. I always wondered if they made it up selling terminals.
I also remember a high school keeping all of its records on several thousand students on two Commodore PETs hooked into a single 8050 (two 512K floppy drives) through a device called a MUPPET ("Multiple PETs").
And why is this relevant when flash storage costs $.10 per gigabyte at retail prices?
Seriously, my microSD card I just bought was $52 for 512GB of space.
On a typical 5G connection you can download a 600MB application in under a minute.
It’s really neat that we grew up with computers that had intense resource restrictions and we got by. But that is basically just trivia. Sure, some bureaucratic banking company out there doesn’t care to prune their app libraries, and I couldn’t care less, personally.
Ask the relatives of the 134 who not too long ago died in a flooding in Germany [1] whether buying electronics for cents or reverting exploitation of the planet are more important.
Probably there are 10s if not 100s of thousands of victims more in Africa, South America, South-East Asia that we in the Western world forget shortly after reading the headlines.
Myself, a European, I have traveled across the USA before mobile phones existed or internet was available to private households. Believe me, the experience was better than traveling today where you have seen everything on Streetview before even getting there and using GPS to get to the next restaurant. (Yes, getting there by plane was not climate-smart act and I would not do it again after having seen it more than once.)
This is all a pitch to run Emerge tools in the CI/CD process.
So from Santander’s side:
Introduce a third party dependency
* that has to go through the appropriate auditing
* that adds a supply chain attack vector
* that likely slows down internal development by adding an extra step to the build process (no you can’t just do it on release builds that would be crazy)
* with an added cost
All for something most likely no customer (or statistically no customer) ever complains about.
But they can fix the issues that are bloating the app without those tools now that they know about them. Plus, it would be possible to figure most of this out just by looking casually at the size and structure of the IPA they're uploading for distribution.
> Plus, it would be possible to figure most of this out just by looking casually at the size and structure of the IPA they're uploading for distribution.
Which they'd probably do if a statistically significant number of people cared.
Santander doesn't think you care that their app is so big.
Are they right?
Personally although I find this wasteful and sloppy, if Santander have better interest rates or branches close by, or basically anything else going for them then I'll happily ignore the size of their app. So at least in my case they'd have been right to assume that I don't care.
I agree with this. The two banking apps I have installed are ~250MB and ~180MB (Chase and Capitol One), but I had no idea about either until I just checked. As far as satisfying me as a user is concerned, any effort spent optimizing for storage is wasted.
Size is meaningless by itself but it's a decent proxy for quality.
I know publicly benchmarking DBs is mostly illegal, but I wonder if public analysis of common consumer apps for consumers' informed benefit would fall into similar gray areas.
I feel like the only apps incentivized to change this are the ones that people don’t have to use (to use their bank account, because their employer makes them etc.) and that have competition installed in the same phone.
At least I sometimes prune my app list by size every once in a while (when I run out of space); I rarely need to get past the top 15, but everything in there gets a very close look.
I’d never delete my primary bank’s app, but the 10th food delivery service app I’ve only installed for a promotion? Gone without a second thought.
In that sense, Santander is probably extremely safe, given how infrequently people change banks. (That’s also why they can get away with poor app experiences.)
To be exact, that's what they call the X-Ray in their product speech, the breakdown is also there if you click around. But very nice data!
Do you know how these examples are made? Is there a way for free uploads of apps or at least browsing those they have? My Web search found https://www.emergetools.com/app/example/android/bumble for Android which I am more interested in.
No, I am not an app developer. Not considering buying a license just out of general engineering curiosity.
I'm a victim of the Santander app in another country and it's not only "large", lot of functionalities are there but when you try to use them it just says "this function is only available on our website".
Also it super slow and I have to kill the app a couple of times a week.
Except if I have to do a wire transfer I always use another app from a Fintech company.
This isn't a surprise at all. Most iOS apps have 4 or 5 analytics frameworks included that are probably at least 50mb each. Airship (maybe the defacto standard framework for push notifications) is over 100mb.
Throw in a few pictures and videos and you're very quickly at 613mb.
Then maybe this is a problem with Santander in general, because my own Santander app for Mexico eats over 460MB despite only modest use and I see no reason why it should. I suspect a mountain of bullshit consume tracking bloat and other related nonsense while they offer you their "service" in the background.
lets be fair. It says: 35% of it does nothing -for the user-
Maybe if does something for the bank then. An app can have different tasks and not all must be related with communicating with the users. Machines need communicate with other machines, or send data, or store a database of legal texts or exception handling cases.
90% of the instruction manuals of appliances just are spent saying the same in twenty different languages that I will never use. Is this outrageous? Maybe. Maybe not
Or maybe this apps are just mining crypto in the background and sucking battery. Who knows?
the thread literally says that 35% of the app bundle is taken by "binary symbol tables". binary symbol tables is a mapping of a memory address to function and variable names. it's use is to debug an app locally. >99% users won't even know what a debugger is and just report the error once the os prompts them to. the remaining <1% of curious developers owning a mac with XCode and knowing what debugger and debugging symbols are may play with them, but without knowledge of how the source code is organized it won't be useful to them anyway. the submitted report will contain the memory addresses but won't contain the symbols, the developer will have to load them externally from the company's build server. it's literally useless to anyone for anything.
Very helpful for anyone who wants to crack or reverse engineer that app. Not sure why anybody would want to do that. But there could be people with criminal minds having some creative idea.
Not trying to say that stripping symbols is the ultimate security measure. But at least I cannot see a reason to keep them, as the parent commenter wrote. Appears as an utterly incompetent software delivery process.
It could just be simply about a bad build system that does not efficiently trim out unused dependencies, or people are using unnecessary dependencies in the first place. Which happens all the time everywhere.
And to be honest, I can totally see why this is happening. Santander does not have a lot of incentive to improve this. The distribution of the app package is done by Apple, and they don't charge you by what your file size is or how much bandwidth this uses. They charge you a developer fee and 30% IAP. If there is no (direct) extra cost, and trimming the file size could mean additional work on the developers and may cause things to break if not handled well, someone could be blamed for it. So why take the risk.
And actually, it is possible that nobody internally at Santander ever looked into this problem.
How do I know? The build system at my company sucks -- tons of waste of build time, memory use, disk space, debugging time, communication etc. I myself have brought up many of the issues. Nothing happened. Why? Because things are working, and nobody wants to do something when there is only risk but little benefit (to them).
As of why people aren't being rewarded for saving CI costs, I'll leave that as an exercise for the reader.
IMO Apple is partially responsible for that - in that linked twitter thread the mentions:
"We've outlined this before in previous tweets, explaining that these binary symbols used to be automatically optimized by bitcode, which has since been deprecated by Xcode 14 ",
"Xcode 14 deprecated bitcode by default, which we've detailed a few times. Basically, bitcode optimizes production builds, partly by stripping away unneeded metadata (binary symbols)."
Something tells me Apple is quite happy with that - easier to sell iCloud subscription or upsell iPhone with bigger storage and also easier to scream to EU that running infrastructure for AppStore is very expensive with those heavy apps so they deserve their 30% cut.
Similar story is with Photos storage - so hard to recompress them to smaller - lots of very shady apps in app store. I really think Apple do this on purpose to sell more iCloud
Bitcode was there for support of multiple architectures. It’s not needed anymore and won’t provide any benefits moving forward.
https://arbyswift.com/why-does-xcode-14-deprecate-bitcode
Photos wouldn’t be a very good photo storage service if it was wrecking my photos by compressing them. I want more detail, not less. Also, you can choose photo quality very easily. Settings > camera > formats > photo mode
4 replies →
There's no need to wonder what it "could" be about, it's all explained at the link. :)
I reported this size issue to them during beta test, and they ignored it. At the time I was on a limited cellular plan with no home wifi, so 600MB was a huge bullet. BTW, the old app was ~180MB and the one before that was ~50MB.
It wouldn't take much engineering effort to address the size issue, but somebody in a position of power would need to care about it.
> Santander does not have a lot of incentive to improve this.
There is some incentive. A not-insignificant percentage of users won't be able to immediately install it without going through the hassle of finding something else to delete first to free up storage space, adding onboarding friction.
This is funny: the idea that banks have the same concerns about “onboarding friction” as high growth startup companies.
You know who big banks don’t care about serving? People who are too poor to have free storage space on their phone.
3 replies →
I encourage everyone to go to app store -> profile -> swipe refresh, and see how heavy all those apps updates on iOS are few examples:
Gmail: 570 MB
Facebook: 345 MB
Booking.com: 260 MB
AirAsia: 510 MB
Reddit: 330 MB
Slack: 400 MB
X: 290 MB
Google Translate: 180 MB
Uber: 480 MB
Speedtest: 150 MB
It's horrible how heavy all those apps are. I barely can find app update that is less 100 MB.
Yes it's one of the thing i noticed when I switched from android to iPhone, ios apps are so much bigger.
For instance, Gmail android app bundle (2 app, arm64-v8a + armeabi-v7a) is 59mb.
Ios doesn't even have to care about armeabi yet it's 20 times bigger. What's going on ?
Material design components maybe?
And to think I was mildly concerned when our app inflated out to 36.8MB recently
Our app has ~20K MAU and download size is around 3.5 MB, it was 3.2 MB before though.
1 reply →
Well done, keep it up! I also strive to keep my apps small and lean.
It's ridiculous, and many websites are just as bloated.
Not for the first time, I blame CSS, and the marketing-driven economic incentives that popularized it. Too much graphic design turned the web from something resembling a living book to something resembling a glossy magazine, along with the ads and the promotion of sensation over substance. I sometimes find myself missing TUIs and being able to meaningfully customize your user experience.
But this was always unavoidable, because it turns out non-HN users like glossy magazines. So the internet will always either be niche and text-only or glossy and popular
On the plus side, my latest app (a browser for multiple Japanese shopping websites with unified search, and an icon!) is just 200KB (400KB installed). I use zero frameworks to achieve this. I also target iOS 15 just for kicks.
Is it horrible? I recently bought a 512 GB microSD card for $52.
I could fit over 1000 of these apps on that card with no problem.
Which iPhone has microSD support? Macbooks only recently (starting from from m1) have sd card slot and only most expensive macbooks pro. 1-2 years ago they were still selling macbook pro starting with 128GB ssd and of course they are soldered. At one point when buying iphone they allowed you to choose one with 64GB or ... 256GB even if I wanted 128GB.
And for me its no problem - I sync photos with my macbook photos and remove from phone. But not everybody has Macbook. Support for syncing on windows used to be totally terrible - there was no syncing just download all photos with arbitrary names and folder names.
On top of that when syncing iphone with macbook by accident you forgot to check on this small box "delete synced medias from iphone" you will have to delete all photos one by one selecting... there is not option like delete all photos - ridiculous.
3 replies →
If you're using a device which allows storage extension using microSD cards - i.e. if you're using Android - that is a solution but Apple iOS devices do not offer such options. You get to buy the same storage for a far higher price without the possibility of extending it later on, better bite the sour apple and pay that ridiculous price for the 512GB or 1TB version now because you know you'll be even more sorry if you didn't later on.
I feel like it’s either this, or some super optimized app that weighs in at <10 MB and does what it should perfectly. I really wish there was a middle ground.
Google Docs/Sheets/Slides are particularly infuriating. I’m pretty sure they all contain 90% identical code and assets.
The Affinity apps (Photo, Designer, Publisher) are all 95% the same, too. They are basically the same shared frameworks with a slightly different UI. They can all open the same documents, for example. Whilst you can only create a table in Publisher you can edit it in any of the apps. Ridiculous. But then they get to sell you the "same" app three times.
I like this for simple mobile projects:
https://quasar.dev/
In some cases, going with an SVG icon pack etc. can save a bit of space. =3
I am old enough to remember times when 100 computer science students did their exercises on a VAX 11/750 with 4 MB of main memory. Admittedly it was a bit laggy when all 15 terminals were in use during peak hours. I don't remember disk sizes.
Now main memory is a different story than application size. But in most cases your main memory must be significantly bigger than size of a single application. So for that 4 MB VAX running a 2 MB application might be suitable. Let's reduce the 15 users to one, that's progress over 4 decades...
Now the question: What can that 2 MB VAX banking application not do, that the 613 MB iOS application can?
* Cryptographic operations have developed. But I am not aware that those used by a banking application are particularly memory hungry.
* The screen resolution is different, but banking on 80x25 characters would work just fine at least outside of CJK.
* The touch input might be problematic, so we would need to use a Blackberry or Nokia Communicator with physical keyboard. That would not only be a disadvantage IMHO.
(The last 2 items are largely influenced by the operating system. But of course that would need to be very different to run on a 4 MB computer.)
What else am I missing in this thought experiment? Honest question.
1. Image recognition: many banking apps offer support for transfers via QR codes.
2. I18n: the app may not speak your language, but you may set the display names of your savings accounts in Unicode.
3. Branding: text doesn’t offer much there, high resolution GUIs can offer a lot, not just a logo or colors, but also custom fonts, icons, images, interaction scenarios etc.
4. Telemetry: well, that’s just a lot of extra logging code.
5. A/B testing support: code for running experiments as well as code and assets for A and B variants.
6. Just a lot of business functionality that is much cheaper to develop today, including things like onboarding flows, chat with customer support etc etc.
That’s what comes to my mind immediately. Probably there’s plenty of other things.
> 1. Image recognition: many banking apps offer support for transfers via QR codes.
Accepted.
> I18n:
Outside of CJK, every new language takes a couple of kilobytes. You cannot explain megabytes with that.
CJK I already mentioned, it might be beyond reach? But actually in 1986 I saw the first IBM PC with a Kanji UI. I have no idea how much memory it had. But I might guess that might still have been hardware where 640 kilos(!) is more than anybody would ever need? Not sure.
> 3. Branding
I couldn't care less as a customer. The bank should offer good rates and flexible service. They can keep their branding.
> 4. Telemetry
Everything the user can do on their qwerty can be logged with kilobytes of code.
> 5. A/B testing support
Same here. Remember our interface is 80x25. Many variants of that fit into just kilobytes.
> chat with customer support
I started to use IRC in 1990. Don't remember how big the clients were and cannot quickly find a reference. I would guess 100 KB max, probably less. Using a camera would not be possible, we had that already under QR.
1 reply →
> 1. Image recognition: many banking apps offer support for transfers via QR codes.
The nice link https://www.emergetools.com/app/example/ios/examp_fCeiq7Z6xe... given elsewhere in this discussion reveals another functionality: Check scanning.
Living in a country where checks have been abandoned some 30 years ago, I can only shake my head about the irony. Scanning checks with an alleged high-tech device...
1 reply →
> Now the question: What can that 2 MB VAX banking application not do, that the 613 MB iOS application can?
Work on your iPhone?
All the bells and whistles of that UI come at a large cost - memory.
And why not?
The iPhone's got it.
A better question might be: why does App A on the iPhone take up about ~10x as much space as the same app on Android?
And the answer is probably because iPhone users don't care...
If they did, Apple would probably do something about it...
> And why not?
> The iPhone's got it.
And why not?
Let's ruin the planet, we've got it.
Apple is more unethical in their resource waste than Google. But Google is very very far from innocent.
7 replies →
> All the bells and whistles of that UI come at a large cost - memory.
I’m not sure that’s true. If they tried they could have made an app with loads of bells and whistles that’s 10x smaller (unless we’re talking about a lot of media content). It’s just not something many developers care about due to various reasons
You had me until the "users don't care". I'm a user and reported this issue which resulted in the post we're discussing. Bank management/developers don't care is the issue.
What else am I missing in this thought experiment? Honest question.
Even though I/O was slower on the VAX, with the smaller number of bytes going back-and-forth, it would probably be snapper than a modern app.
I remember when computers were advertised as supporting eight concurrent users running spreadsheets at the same time on a single machine with 64K of RAM. Often off of two or four floppy disks. No Winchester drives.
64K of RAM was stupid expensive at the time. I always wondered if they made it up selling terminals.
I also remember a high school keeping all of its records on several thousand students on two Commodore PETs hooked into a single 8050 (two 512K floppy drives) through a device called a MUPPET ("Multiple PETs").
And why is this relevant when flash storage costs $.10 per gigabyte at retail prices?
Seriously, my microSD card I just bought was $52 for 512GB of space.
On a typical 5G connection you can download a 600MB application in under a minute.
It’s really neat that we grew up with computers that had intense resource restrictions and we got by. But that is basically just trivia. Sure, some bureaucratic banking company out there doesn’t care to prune their app libraries, and I couldn’t care less, personally.
Ask the relatives of the 134 who not too long ago died in a flooding in Germany [1] whether buying electronics for cents or reverting exploitation of the planet are more important.
Probably there are 10s if not 100s of thousands of victims more in Africa, South America, South-East Asia that we in the Western world forget shortly after reading the headlines.
Myself, a European, I have traveled across the USA before mobile phones existed or internet was available to private households. Believe me, the experience was better than traveling today where you have seen everything on Streetview before even getting there and using GPS to get to the next restaurant. (Yes, getting there by plane was not climate-smart act and I would not do it again after having seen it more than once.)
[1] https://www.deutschland.de/en/topic/environment/catastrophic...
2 replies →
https://nitter.poast.org/emergetools/status/1831772650685018...
This is all a pitch to run Emerge tools in the CI/CD process.
So from Santander’s side:
Introduce a third party dependency
* that has to go through the appropriate auditing
* that adds a supply chain attack vector
* that likely slows down internal development by adding an extra step to the build process (no you can’t just do it on release builds that would be crazy)
* with an added cost
All for something most likely no customer (or statistically no customer) ever complains about.
Yes, the thing that people who ship 600 MiB apps have in common is an extreme attention to detail in their "software supply chain".
Yes, that is the sort of thing you have to care about in banking.
But they can fix the issues that are bloating the app without those tools now that they know about them. Plus, it would be possible to figure most of this out just by looking casually at the size and structure of the IPA they're uploading for distribution.
> Plus, it would be possible to figure most of this out just by looking casually at the size and structure of the IPA they're uploading for distribution.
Which they'd probably do if a statistically significant number of people cared.
> This is all a pitch to run Emerge tools in the CI/CD process.
True. But still very educational about the current state of computing.
Santander doesn't think you care that their app is so big.
Are they right?
Personally although I find this wasteful and sloppy, if Santander have better interest rates or branches close by, or basically anything else going for them then I'll happily ignore the size of their app. So at least in my case they'd have been right to assume that I don't care.
I agree with this. The two banking apps I have installed are ~250MB and ~180MB (Chase and Capitol One), but I had no idea about either until I just checked. As far as satisfying me as a user is concerned, any effort spent optimizing for storage is wasted.
Size is meaningless by itself but it's a decent proxy for quality.
I know publicly benchmarking DBs is mostly illegal, but I wonder if public analysis of common consumer apps for consumers' informed benefit would fall into similar gray areas.
4 replies →
I feel like the only apps incentivized to change this are the ones that people don’t have to use (to use their bank account, because their employer makes them etc.) and that have competition installed in the same phone.
At least I sometimes prune my app list by size every once in a while (when I run out of space); I rarely need to get past the top 15, but everything in there gets a very close look.
I’d never delete my primary bank’s app, but the 10th food delivery service app I’ve only installed for a promotion? Gone without a second thought.
In that sense, Santander is probably extremely safe, given how infrequently people change banks. (That’s also why they can get away with poor app experiences.)
Bad practice is bad practice, It's costing them bottom line somewhere.
But on the contrary, introducing tooling to fix it might cost more
1 reply →
Breakdown of the app is available here: https://www.emergetools.com/app/example/ios/examp_fCeiq7Z6xe...
To be exact, that's what they call the X-Ray in their product speech, the breakdown is also there if you click around. But very nice data!
Do you know how these examples are made? Is there a way for free uploads of apps or at least browsing those they have? My Web search found https://www.emergetools.com/app/example/android/bumble for Android which I am more interested in.
No, I am not an app developer. Not considering buying a license just out of general engineering curiosity.
At this point I’m just assuming that the developers of such apps receive a large gift basket from Apple each Christmas…
I’ve definitely upgraded storage sizes for this reason alone at least once.
here's the unroll: https://threadreaderapp.com/thread/1831772650685018352.html
I'm a victim of the Santander app in another country and it's not only "large", lot of functionalities are there but when you try to use them it just says "this function is only available on our website".
Also it super slow and I have to kill the app a couple of times a week.
Except if I have to do a wire transfer I always use another app from a Fintech company.
This isn't a surprise at all. Most iOS apps have 4 or 5 analytics frameworks included that are probably at least 50mb each. Airship (maybe the defacto standard framework for push notifications) is over 100mb.
Throw in a few pictures and videos and you're very quickly at 613mb.
But that's not what is taking up 613MB here, the details are at the link.
Hmm. I must have missed the link. I'm just seeing a single tweet with no details.
Doesn't surprise me. It's probably something generic they bought in and customised.
But they're all crud apps, on a system that already has a webview! Why do any need to be over 100k?
It's amazing how complicated you can make a CRUD app with a suitable architect and project management team in there!
1 reply →
No need to guess, full details are at the link. Spoiler: it's not something generic they bought in and customised.
Then maybe this is a problem with Santander in general, because my own Santander app for Mexico eats over 460MB despite only modest use and I see no reason why it should. I suspect a mountain of bullshit consume tracking bloat and other related nonsense while they offer you their "service" in the background.
lets be fair. It says: 35% of it does nothing -for the user-
Maybe if does something for the bank then. An app can have different tasks and not all must be related with communicating with the users. Machines need communicate with other machines, or send data, or store a database of legal texts or exception handling cases.
90% of the instruction manuals of appliances just are spent saying the same in twenty different languages that I will never use. Is this outrageous? Maybe. Maybe not
Or maybe this apps are just mining crypto in the background and sucking battery. Who knows?
the thread literally says that 35% of the app bundle is taken by "binary symbol tables". binary symbol tables is a mapping of a memory address to function and variable names. it's use is to debug an app locally. >99% users won't even know what a debugger is and just report the error once the os prompts them to. the remaining <1% of curious developers owning a mac with XCode and knowing what debugger and debugging symbols are may play with them, but without knowledge of how the source code is organized it won't be useful to them anyway. the submitted report will contain the memory addresses but won't contain the symbols, the developer will have to load them externally from the company's build server. it's literally useless to anyone for anything.
> it's literally useless to anyone for anything.
Very helpful for anyone who wants to crack or reverse engineer that app. Not sure why anybody would want to do that. But there could be people with criminal minds having some creative idea.
Not trying to say that stripping symbols is the ultimate security measure. But at least I cannot see a reason to keep them, as the parent commenter wrote. Appears as an utterly incompetent software delivery process.
(poster) I had to trim the title to fit HN submission.
I would argue it does nothing for the user, and nothing in the app given it can be trimmed with no side-effects.