I’ve been judged by prospective employers based on reported app size being seen as correlated
to complexity. VC backed startup I worked at for 18 months with a 12 megabyte app size due to efficient design choices? Must be a joke
So now I just add a 150 megabyte dummy file at everyone else’s expense
I’m sure there is a lot of that going on given how long some job roles were open, I have to imagine that every mobile developer on the market may have passed through and made the same conclusion!
> I’ve been judged by prospective employers based on reported app size being seen as correlated to complexity.
This judges the prospective employer more than it judges the candidate, doesn't it?
This is actually nothing new. Back when I was at uni some students claimed to do the same, adding code that served no purpose to inflate the resulting program executable size.
And if my memory serves me well, at this time when windows was still young and software was swapped around on floppies, software sizes started to skyrocket and I've heard then that the secret reason for this lack of care was that size was the easiest way to impress users and the tech press (all while making piracy more inconvenient).
> This judges the prospective employer more than it judges the candidate, doesn't it?
Easy to say, rhetorically suggesting that its revealing a toxic mangement environment, but no, not really. My experience has been overwhelmingly positive with great teammates and great managers, and a hiring decision maker that was otherwise completely hands off of what I was doing for the rest of the project. A hiring decision maker that probably left within 3 - 6 months of me joining, or who was randomly called to do an interview last minute and had arbitrary evaluation metrics. Maybe that is what you mean, but it had nothing to do with the day to day experience, once on board I found every place to be very similar with the mobile team pretty much on autopilot, which is the desired experience. Even quicker paths to leadership roles and higher compensation.
They all have interesting-enough projects at the time, or fulfilled some other interest of mine, or money without being a bad environment. Interview gaffs really don't carry as much weight as people think, it requires a special kind of privilege to think it matters that not all of us have or had.
Yes, binary size, deployment size, deployment time, LoC, source code zipped size, number of directories in GitHub, number of repositories in GitHub. I have heard all kind of VC metrics to increase ‘success’ of being believable by partners, clients and VCs. Small and lean is something ‘they’ generally do not believe anymore.
In a rather successful business I had, I had a product of a few 100kb which installed easily on servers; just ./install.sh. Someone told me that this was really not smart. The script downloaded it’s dependencies (just rpm install; nothing proprietary) and then it copied the binary to /use/local/bin. I figured I could fix 2 issues at once; people running other distros complained that it did (obviously) not work; in our target audience, well over 90% ran rpm based distros, mostly centos. This was before Docker etc so I changed the install to apt-get and included a zipped chrooted Debian with everything already installed in it. Suddenly install.sh was over 100s of mbs and worked on any x86 Linux. It indeed made sales jump with people saying in forums that ours was bigger than even the largest competitor install download so it must be better. It is lame but true; especially when people pay for stuff, they want to get bang for their buck.
Yeah, the same concept applies to airline and hotel sites and apps
Their server returns results instantly but found that if they showed a loading animation (even fancy ones like an animated svg or gif of a cartoon passenger in an airplane) that people trusted the results more
Well it may not be correlated to complexity but it certainly is correlated to end user satisfaction. If their device prompts a "device cleanup" operation and your app is near the top of the list that doesn't do much good for retention.
Not to mention the billions of devices in the world which are running old OS versions with scant memory capacity.
If your app is too fast you should also make sure to add a sleep() to it so the customer knows that its 'working.' I read a humorous story about a contractor who did that to satisfy a customers complaint that it was too fast.
And then there's me. I somehow manage to squeeze quite a lot of Android app into several megabytes of an apk — and that's with proguard turned off. Some people's minds get blown by this, but for me it's just sensible engineering decisions.
But for most employers they just need presence, almost nobody was breaking even on apps they just needed the presence on the app stores. Big waste of money for most, and for most projects I was pitched
But that's entirely fair: of course caching data uses up storage. But it's my choice - I can pay for what I use. The crucial part is that I don't need to download an app which is hundreds of megabytes large just in order to hypothetically support caching.
No one can tell me that our species can write 1K ZX Chess (https://en.wikipedia.org/wiki/1K_ZX_Chess) – an entire chess game with intelligent opponents which only takes up 672 bytes – and yet we can't write an email client which isn't a million times that size.
I agree if cached data was actually proportional to usage.
But a lot of these webview kind of apps just download the whole thing anyways, so it's literally just a matter of if the bytes are classified under "application size" or "cache" by the OS.
(Precisely so they have the whole thing available for when you need to use it offline)
It's often the high-res assets (images, videos, sounds, animations etc.) which take up most of the space, not the code itself.
When it comes to the code, the reason that they are bigger is how apps are distributed and have isolated runtimes. There are several commonly used sdks and libraries but because of how mobile app distribution works, these common libraries have to be bundled with each app and are not installed as a reusable library (like you can do with Linux, for example).
> and yet we can't write an email client which isn't a million times that size.
The issue is that the Gmail app isn’t just an email client, it does way more than that. That doesn’t excuse the abusive behavior, but it does explain it.
To add some context, Gmail also includes a lot of the core workspace apps(chat, meetings, etc) if you do have a workspace account, which most users will likely never see.
All of that isn't needed on regular accounts, I guess, but it's probably easier for them to ship it as one app because people might get confused/are able to switch between their workspace and regular accounts in the app. Gmail is also supposed to be the "hub" to workspace on their new Desktop UI.
Gmail being a "hub app" makes some sense, actually (unless you're not using Chat or Meet, of course).
What annoys me much more than that is that Docs, Sheets and Presentations all are multi-hundred megabyte standalone apps, of which I'm guessing 80%-90% of the code is identical/pulled in from some non-shared library.
I suspect it's a hard issue for the App Store model.
You don't want a situation where someone updates App A, it updates a lib, then App B breaks because it hasn't been checked against the new library. I know you are a good developer who would check that, use major / minor library versions correctly etc. but there are lots of developers on the App Store. Or the fun case of updating App A, it updates a lib and then magical new features appear in App B that Apple doesn't like.
You'd probably have to use some sort of strict library versioning system where every app version is tied to a very specific library version. Are developers in general going to be disciplined enough to actually keep their apps all in sync on a specific version so older versions of the libraries can be removed? Or does this just mean every app from a developer will end up having its own slightly different revision of the lib tied to them? If it's the latter its probably not worth Apple's time adding all the complexity to manage the libraries to the App Store system.
And given that’s a new approach in a Unix-like environment, let’s call it Nix, and the content-addressed download location should probably be called the binary cache :)
[Not really, Nix integrates a build system into the process, and there was prior work I can’t remember that was binary-only and so closer, but the essence of the idea is very similar.]
And introduce a well known problem, not so well solved by OS makers and their developers outside Linux (somewhat). Windows and its developer community kept failing, it has improved in the recent years though, Apple decided long ago they would rather sacrifice space to guarantee a package will execute as intended. (even so, sometimes still fails as native libraries do change and aren't packaged). And upsell larger storage as highly profitable addons.
Maybe there is a dep linking pattern I'm unfamiliar with then. Afaik static linking, or packaging dependencies along with the main binary and dynamic linking or depending on libraries present on the system (with or without the integrated feature of conditionally fetching those prior to install/execution of that main binary) are the two battle tested approaches to distribute apps. The first duplicates stuff, the second leads to compatibility surprises when developers think version 12.1.6 of one of the hundreds of dependencies is compatible but in fact only tested with 12.1.3 and assumes semver is always honored, then poor user user on that just one dependency update is left with an app that crashes.
If you don't mind explaining what splitting a package and de duplicating the download is, and how it prevents the issue I mention that would make me learn something :)
You're thinking of a system that's too clever for its own good. Go dumber.
Start with a setup where you're packaging all dependencies with your binary, dynamically linked.
Then, instead of a single zip file, put each dependency in its own zip, or even each file in its own zip. But each release is still a full set of specific files. You never refer to a dependency by name or version. That's too clever and fragile.
If two releases of two separate programs happen to share the same exact file, then you only need to download it once.
Words like "compatible" and "semver" have no meaning to this system, because you only deduplicate the exact same file. You save space if a developer reuses code correctly, but otherwise there are no visible side effects and no bugs.
Does it make sense? Every time I click a link in GMail it opens some weirdly broken browser imitation instead of opening it in my chosen browser. This is supremely weird.
Yea I am definitely one of those people who hates all that crap in my email app - I have workspace at work and normal gmail for home use and even on desktop it just annoys me. I like having a big fat separate chat window for all the people I'm annoying
They also have an authentication option they are building in (ie, sign in with the app to web properties). I've noticed a bunch of stuff seems to be migrating into gmail.
My own view is they burnt people out install allo, hangouts etc, and people DO install gmail / have gmail accounts -> so they are going to try to leverage that for distribution a bit more.
That sounds like a reasonable point of view. But it could be that they are just trying to up sale their other services and can more easily do so if it’s bundled in an already used app.
They've shoved all that functionality into the Gmail app. I actually uninstalled Gmail because it became the default app to open Google Meet video calls, even with Google Meet installed. I don't need my email app asking me for video and microphone permissions...
This specific case is more of an artifact of iOS's inability to handle multiple apps declaring the same URI launch scheme cleanly than a problem with Gmail on iOS, in my opinion.
Picking a default handler for a given scheme seems like a problem best solved at the OS level, and I don't even know how an app developer would be able to fix that.
As Apple has been steering people away from custom URI schemes, I doubt they will ever support platform-level dialogs for the user to select an app or a system wide 'open in' default.
Coincidentally, the methods used for this today in macOS (in apps that prompt to set themselves as the defaults, or populate a drop-down) are deprecated.
....which I said I did but still could not opens video chat links in their dedicated video chat app because it open Gmail anyways, which then just crashes with an error that it doesn't have permissions
Used Emerge Tools size analysis to analyze the binaries, here's some quick findings to answer some questions:
[0] Fastmail: smallest of the apps but still could have room for improvement, could save almost 20% of the app size by optimizing their audio files. 71% of the app is the binary. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[3] Hey: could save about 15% of the size of the app just by removing duplicates and optimizing their images. 45% of the app is binary, 27% of the app is assets, this is definitely higher than it should be. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
Unfortunately this is a very common problem as many teams don't have any monitoring in place. Here's another example of a popular email app Spark, automated insights show over 100 MB of easy savings: https://www.emergetools.com/app/example/spark?buildContent=i...
For pretty much every app here, Emerge's insights found at least 20% in easy size reduction. FYI, in the X-ray visualizations, red indicates duplicates and we can breakdown apps even further using builds with dSYMS!
For some reason it's really funny to see how much room Fastmail's notification sound takes up. Your analysis for Spark also has a send sound bundled but it's one of the stock Apple ones (Blow). Is there a reason why they have to include their own copy instead of relying on a system sound file?
We've seen this happen with system fonts as well, apps sometimes bundle the San Francisco font with an app instead of relying on a system font. There may be some reasons to include the font or sound file, such as if it changes in different versions of the OS. Of course that would make the app inconsistent with the rest of the OS, which may not be the best behavior. We discuss some other tradeoffs with bundling these system resources on our blog post which covers the Spark app: https://www.emergetools.com/blog/posts/7AppsThatCouldSaveYou...
Thanks! This is very interesting to see all the low hanging fruit. Out of curiosity, could you run Emerge on a few other common apps: the United app as well as Yelp, Twitter and TikTok?
Those seem to be the biggest consumer of storage for me.
I tried it out with Yelp and Twitter, both had a lot of bloat due to not stripping binaries. You can see this in the large "String Table" in both screenshots.
Yelp also has a large exports section for the main app binary, that's usually a sign of a problem because the main binary doesn't need to export any symbols, only frameworks do that.
Twitter has a handful of 4MB images, much bigger than images you'd expect in an app. I took a look at a few of these and they are just gradient background images that could have been drawn with something like core graphics to completely eliminate the need for an image.
They're probably shipping their org chat. Artists and engineers are on separate teams, and when the artists want to redesign the look of the app it is easiest to photoshop a bunch of images.
I'm not sure whether to find it amusing or concerning that 20MB now qualifies as a reasonable size for an email client. My first PC that ran Linux had only 8MB of RAM and an 850MB disk, and it felt like a lot at the time.
I was thinking the same thing. What happened? I started programming on machines with 16K of memory or less. It was a point of pride for developers to make programs that did the most with less, like the whole demoscene movement. It's like the contest changed from who can make the leanest code to who can get away with packaging the most bloat in one app without causing the device to break. We went from shaving off individual machine instructions to packaging entire browsers with super-simple apps.
I don’t think that’s entirely it. All of our programs got significantly more powerful at the same time. Your email program, for example, can handle email in hundreds of encodings plus several varieties of Unicode. Properly handling Unicode text requires detailed information about each character. Just the Unicode data tables are multiple megabytes, though the exact size will vary depending on exactly which properties you need. Figure on at least a megabyte just to handle bidirectional text rendering, and add a bit more so that you can distinguish between word characters and punctuation well enough that double–clicking can reliably select a whole word. And then there are emoji!
Most people just see text, and not the complexity that supporting all of that text requires. Most computers from 20 years ago could barely handle it, and you can forget about doing it on the computers from 40 years ago.
There are plenty of other features that have invisible complexity too.
The article we’re all discussing talks about the symbols as if they are completely unnecessary, but that may not entirely be true. They are certainly unnecessary to _run_ the app, but it is probable that all of the error reporting and logging done by the app uses those symbols to explain where the errors and log messages came from. This makes it possible for the developers to actually fix problems. Granted, they could strip those symbols from the distributed app while still keeping them available to developers, but unfortunately that’s easier said than done.
One of the few ways that developing on Windows is better than on other platforms is that MSVC makes it very, very easy to build a symbol server that collects all of the symbols from all of the applications you have released. If you get a minidump from one of your programs crashing, it will automatically load the correct symbols from the symbol server, as well as the correct version of the source code. It will even download symbols for Windows itself, to make those dump files as easy to debug as possible. Linux is only very gradually gaining similar features. and I have no idea about Android or ios.
Developers have always been lazy. I think some of the best developers are the laziest developers, the ones who are motivated enough to find innovative ways to do less work.
When I was programming for DOS, if I wanted to write to the screen in color I had a few options. I could use Borland's conio.h, I could invoke INT 21h and rely on ANSI.SYS to render my color, I could use INT 10h to write a character at a time in the color I want, or I could write directly to screen memory. Writing directly was really the only way to get the performance I needed, but it added complexity, since I needed knowledge of the hardware I was running on (not all video adapters map character cells to segment B800h).
Today, for a similar "text mode" application, I can use ncurses, or I can write CSI codes directly to the terminal. I can write in C or Python or even Javascript. There are more moving parts, but it would be less work to dust off my old 386SX than it would be to get those moving parts out of the way.
No matter what, I'm always going to do the minimal amount of work I need to get the desired result. If someone comes up with a way to do less work and get better performance, that's the ticket to high speed.
Its less about minimal amount of work and more about what you can get away with. You now tolerate less performant and lazier solutions because hardware is so much faster and you can now get away with it in front of your users. For example, microsoft excel feels no faster or more special or does anything more really than the version I was using in 1995 which was served on cd rom or even floppies, compared to a couple GB over the air download for an application that today still takes time to open up on modern hardware. MS gets away with this because users expect the same features as 30 years ago and also expect excel to remain as slow as it felt 30 years ago. You could be lazy back in the day, but you still had to ensure your program was small enough to actually ship on physical media, and could actually run on this hardware thats several orders of magnitude slower than what developers expect users to be running today. So you can definitely get away with being even more lazy, less optimized, less performant, and still have a job shipping 'functional' software today, than what the constraints were decades ago.
I’ve built a full android IRC client in 4.1MiB. Most UI elements are custom, no web view for anything, lots of custom libraries etc. That’s > 200kLOC. I can’t fathom what you’d have to do to get to 100x that.
Quassel+Quasseldroid is actually a bouncer and a bouncer-specific client, so Quasseldroid handles none of the IRC parsing and state management parts.
Actually, over time I’ve split out a lot of code into libraries, so the app itself is down to ~70kLOC. Which is a normal amount of complexity for something like this. It has to handle notifications, chat formatting, avatar parsing and display, a ton of different UIs for configuring all the different options, etc.
· ~15kLOC bouncer internal protocol code
· ~1kLOC local caching + persistence
· ~40kLOC state handling and UI
· ~13kLOC fixing android bugs and compatibility with older versions
With the split, that moves 24kLOC into the internal protocol lib. Another ~100kLOC are now generated at build time through ksp (a type of macro preprocessor for kotlin).
Why should it? Android supports vector assets, I ship everything as vector drawables. 98 vector assets, full text of 11 licenses and translations for 9 languages are > 90% of the 4.1MiB
That said, what assets does an email client need beyond what I use as well?
C and Go are at a very similar level of portability. Statically link your C binary with musl and it will run everywhere the Go binary (built on the same system) would. Neither Go nor C will run outside their architecture or OS, but both can cross compile.
Go makes both processes more user friendly. Statically linking with musl is simple in C (musl-gcc), but cross compiling is a bit of a pain the ass to set up (building your toolchain from the ground up). Not too bad, and if you're messing with building portable executable this kind of knowledge is assumed.
I haven’t analyzed their binaries or anything like that, but I’d wager that a significant chunk of the heft of the Gmail and Outlook iOS apps are Google/Microsoft’s custom UI frameworks.
The sizes mean different things in different platforms. Google reports the download size, Apple reports the size that the app will consume on your device. Both have their uses but you shouldn't compare the two.
Outlook makes sense because they use React Native in their app. If you look at their License sections they are using a ton of libraries which is common.
What I also find very annoying is that the Outlook app even embeds a whole browser (with GUI; is it Edge?). It makes me furious to be forced to use the embedded browser when opening links in emails instead of a preferred, already installed browser. I mean... what advantage has it to use an embedded browser? I lose my cookies/sessions, browser extensions, passwords, and the usability is worse than of my preferred browser.
I had a financial app bloat up to 800MB+ due to some botched incremental updates.
I firmly believe in 2022 those who care about bundle sizes are in minority. I personally come from an embedded dev world so I got accustomed to fighting for bytes as I learned to program.
Nowadays if I suggest something to save space, I usually get a blank stare.
Do they have comparable functionality; in particular, are they all actual genuine native apps with offline capability; vs a glorified hyperlink to their web interface?
They don't; the Fastmail app is just a web view. It's completely non-functional when there's no internet connection. Really glad to find this out now, and not when I'm in an airport or something somewhere with no internet connection and really need to look at an email related to my travel arrangements.
K-9 Mail doesn't include a calendar, but it does come in at around 20 MB or less (for the app itself, mail storage not included) and it definitively works offline.
I've heard that some of them include their own network stack so that only they can track your data. I think that was in reference to Facebook's app originally but I wouldn't be surprised.
- Gmail (397MB) [1]
- Outlook (328MB) [2]
- Hey (69MB) [3]
- Protonmail (128MB) [4]
[0] https://apps.apple.com/us/app/fastmail-email-calendar/id9313...
[1] https://apps.apple.com/us/app/gmail-email-by-google/id422689...
[2] https://apps.apple.com/us/app/microsoft-outlook/id951937596
[3] https://apps.apple.com/us/app/hey-email/id1506603805
[4] https://apps.apple.com/us/app/protonmail-encrypted-email/id9...