I shaved 187MB off United Airlines' 439MB iOS app
telkins.dev
telkins.dev
- 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...
When I was a Windows user, a video player install of more than 80MB would be slightly bloated.
Today my OpenBSD install uses less than 3GB and it has far more stuff than a phone install.
Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.
That said, what assets does an email client need beyond what I use as well?
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).
Further breakdown of the UI part:
· ~7kLOC XML layouts
· ~7kLOC included default settings
· ~7kLOC Chat UI Code
· ~5kLOC Settings UI Code
· ~3kLOC Setup and initial configuration wizard
· ~10kLOC background processes, notifications, protocol handlers, etc
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 once ported a shoddily written (by me) Python script to Go. About 400 LOC in Go. The compiled executable size was a whopping 7 mb!
This was more than I expected.
It turns out there's a reason for large executable sizes in Go [1], and apparently it can be made smaller.
[1] https://go.dev/doc/faq#Why_is_my_trivial_program_such_a_larg...
[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+...
[1] Gmail: looks like most of their bloat is coming from localizations. Only 60% of the app is binary, while 24% is localization files. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[2] Outlook: could be stripping binary symbols to save significant space. 65% of the app is binary, while 14% is localizations. 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+...
[4] Protonmail: could save almost 30% just from image optimization and duplicate removal. 58% of the app is binary, 14% is assets, and 7% is localizations. 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!
Those seem to be the biggest consumer of storage for me.
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.
Twitter: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
Yelp: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
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.
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.
They do exactly the same thing on Android - Gmail has it all by default, if you want them separate, you can get them from the play store.
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.
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.
You do if it is also your video chat app. If not, decline permissions.
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.
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 :)
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.
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.
[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.]
The iPhone 11 Pro Max, a $1100 phone from late 2019, still had 64gb as base storage...
It's because it doesn't contain anything. You can't even see any UI, let alone emails without being connected to the internet.
EDIT: just realized the app is a web view. Sigh
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.
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).
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)
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.
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!
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
Not to mention the billions of devices in the world which are running old OS versions with scant memory capacity.
are not the rich or loose-walleted people that app sellers and advertisers care about.
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).
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.
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.
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
I wonder why the Gmail app is almost 4x the size on iOS.
https://mobilityarena.com/ios-apps-are-larger-than-android-a...
It supports your claim that iOS app sizes are 3-10x bigger than Android.
I wonder why. The article makes some guesses but still, the magnitude difference is significant.
Even Fastmail, which has the smallest iOS email app, is still 2x bigger on iOS (20MB) vs Android (10MB).
https://play.google.com/store/apps/details?id=com.fastmail.a...
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.
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.
I really wonder what some of these apps are doing with this space. My banking app clocks in at 400 MB as well.
I'm not entirely convinced value-per-byte is a measure of software quality that a lot of users care about, but it undeniably trends down every year.
All of that happens online.
At least the airlines I've worked with prefer native code and UIs for any flow that's either revenue-producing, or likely to create issues on day-of-travel. They tend to use webviews only for things that don't have to be working to sell a ticket or board the aircraft.
I’m the first to say that this utter bloat is terrible, but most people aren’t really bothered by it. And I can only imagine that they outsourced their app development completely and like to keep costs low.
From that perspective, it’s probably much more pragmatic to fix the problem at the root(s): Apple may want to mandate stripped binaries (I think this is also what RPM does by default, just strip everything), and/or god forbid these Electron-type frameworks should make things more efficient.
The problem is that purchases would no longer be subject to Apple's 10x industry standard (30% instead of 3%) captive credit card payment processing service (for apps), so no web notifications in MobileSafari that might undermine platform control and payment processing monopoly. Apple, of course, will say this is about protecting users from notification spam, and sidestep the inconvenient facts that it protects an Apple cash cow and locks developers and users into a closed and proprietary platform.
Even apps without notifications are still apps, because they can take additional data from users, sometimes even location and the whole address book.
Look at sites like reddit for exmaple, which purpusefully cripple the mobile web experience to get the user to install the app.
In theory, this is true. In practice, it's just hit or miss. I think it's just hard to maintain web across all the different platform and screen sizes. It's probably due to the fact that an iOS developer specializes in one platform and most web development shops will have to support all platforms.
"If Apple would allow web notifications"
I do not use apps because of notifications. I use apps because in general, the performance and experience is much better.
For example, you can create "app" that is just a link to browser. There are plenty of action you don't want random web-apps to perform due to security/sandboxing issues, but if you can grant explicit permissions that issue goes away. It is one of the reasons think like election exist. But could apple/goog provide a better electron that was built into the OS?
For a 5-screen 50MB app, sure. For a 5-screen 500MB app that falls pretty flat.
[edit] You could fit all of Tony Hawk's Pro Skater 2 or Final Fantasy VII for PS2 in the same amount of space.
A candy bar which is 5% packaging and 95% candy by mass is alright. A candy bar which is 50% packaging and 50% candy is horrifying.
An emulator and Mario 64, Zelda OOT, ISS and 40 games more could be placed under a CD and yet you could fit a good bunch of MP3's in between.
Increase developer productivity at the expense of hardware.
In this case, engineering is more expensive than hardware (because hardware is at the cost of the user).
The smallest iPhone starts at 128 GB. This means the application takes 500/128000 blocks: 0.4% of the total device storage.
Over time, the iPhones are going to have more and more storage. So, if app size is a problem, and over time, the problem is fixed by itself, why would you invest engineering resources into that ?
You have X engineers with Y amount of working hours, and tons of important things to do. Yes, probably fixing a problem that brings a low amount of complains from end users at the cost of productivity isn't high on the list for them.
EDIT: Possibly interesting source: https://www.androidauthority.com/average-smartphone-storage-...
The smallest iPhone sold now is 128 GB. The iPhone 5C, sold in 2015, had 8 GB internal storage with no expansion options. 439 MiB is a full 5% of the total storage capacity of the iPhone 5C, completely ignoring the amount reserved for the OS that's completely unusable to the user.
The logic used here hurts lower-income people and contributes to climate change by encouraging poor use of device resources -> shorter device lifetimes -> more e-waste and wasted energy.
Edit: why the downvotes? You can get flights for 50 bucks to go to different countries in Europe.
The cheapest flight I can see on SouthWest.com is $60, for a 1 hour journey from Atlanta to South Carolina.
The cheapest flight with Ryanair from Copenhagen is $9, though it doesn't include checked luggage. It's also an hour.
An even cheaper one is Kraków to Eindhoven, 2 hours, $6. There are fewer dates for this price though.
They look very much in the style of Ryanair with the garish website. $22 for three hours (Boston-Miami) is priced between the two Ryanair flights, so I expect the "service" is similar.
I'm sure the average distance of a flight within Europe is lower than in the USA, since the USA is a bit empty in the middle and Europe has more water in the way, but routes like Scandinavia to the Mediterranean (Stockholm to Zagreb is 3½ hours and $14), or Britain to eastern Europe (London - Cluj, 3 hours $13) aren't far off, and the budget airlines also have flights to tourist destinations in Egypt, Israel, Jordan etc, which are as long as a US coast-to-coast flight.
While I enjoyed camping and seeing bits of the US that foreigners like me don’t normally see, it’s not entirely clear that the difference between that and flying makes flying the luxury.
Overall, choosing Amtrak or flying is perfectly reasonable in different situations. Amtrak could definitely be improved a lot though!
[1] For reference, I live near Miami (technically, I live in Boca Raton, but Miami is "close enough" at this scale). The company I work for is based in Seattle. I refuse to fly anymore for a variety of reasons.
[2] Riding in a private rail car really spoiled travel for me: http://boston.conman.org/2015/08/05.4 But way out of my pay grade.
(But maintaining the track to this quality would be even more expensive if there was as much freight on it as tracks in the USA carry.)
Not being an American I have no reason to even be a UA customer let alone install the app, and therefore I don’t know if they’ve achieved this or not.
Requirements are often above average in some dimensions and below average in others.
If we optimize for people who are wealthy, always in high bandwidth areas with new phones, etc etc soon we will have left most people behind.
Leaving people behind is the entire concept of selling luxury stuff though, so I still don't think that the companies will care much.
More than half of American smartphones in 2021 were iPhones. The iPhone is price-comparable to its Android contemporaries. The Android downmarket in the U.S. is a minority by a wide margin.
But 5c is most unloved device so not a good sample. It was released at the same time as 5s that introduced ARMv8 by A7. It was the worst time to release it with old chip.
I'd pick iPhone SE 16GB in 2017 that's still in support.
A significant fraction of that 32GB is taken by system crap, so a GB makes a difference.
I've often thought that they either need to cache the app locally on the plane itself or provide a special free passthrough on the in-flight wifi, but so far they haven't provided either. In any case, app size is crucially important for the key use case that many (most?) people use the United App.
It's not that simple, but it makes total sense to cache a 500MB app when they have a couple TB (?) of videos on the plan.
Maybe we as an industry should start doing the boring parts instead of jumping into shiny tasks that take 10x, 100x, 1000x the time it would take to solve the original issue...
Only this is almost never true.
If it's possible to do something unnecessarily complicated, someone will inevitably do it. Maintenance costs are often greater as complexity and bloat goes up.
Longer compile times and generally greater development cycle latency also tends to decrease developer productivity more than the small time differences might suggest.
A friend of mine told me their company is trying to downsize their flash storage in order to come back to the unit prices of before the shortages.
This is not a contrarian opinion. This is the default attitude in web, cloud hosted, and mobile app development.
>looks like a rational trade-off that the engineers have done
What are your back-of-the-envelope numbers? Or are you just shrugging and assuming that performance has zero impact on the development loop, so therefore no development effort should be expended on it?
It may depend on the app, but Uber noticed that the bigger the app, the fewer people install it, unsurprisingly.
I also had friends who wouldn't install Signal because they don't have any space left on the device, and they stick to Whatsapp/Messenger which they already have.
https://eng.uber.com/how-uber-deals-with-large-ios-app-size/
> App-download-size restriction means first-time users cannot download the app ... when they are not on Wi-Fi.
> We established a correlation between the Uber Rider app size and customer engagement — when the app size crosses the download size limit, and it leads to a 10% reduction in app installations, 12% reduction in sign-ups, and 20% reduction in first-time bookings, resulting in revenue loss.
> Over the past three years, the Uber Rider app’s size has often approached the App store’s over-the-air download limit, and staying below it is a clear priority.
You are assuming apps won't scale larger over time. The old addage about software expanding to consume all available resources comes to mind. I remember thinking I'd never be able to fill my first 1 GB hard drive with software. And now it takes half that for the simplest things. As the bytes get cheaper we ration them less.
This is not a case of "I have plenty of water so let the kids splash some in the playground to have fun", this is a case of "I have plenty of water so I will load 10000 liters in a truck and drive 1000 kilometers and back just to dump them in the desert for no fucking reason".
Seriously, 5 minutes? I spend more than that in the bathroom. How many 5-minutes is a "Scrum standup"? a "progress meeting" ? a <insert bullshit corporate activity here>? Do all of those things not waste the engineers' time?
I'm trying to imagine the world if every profession and craft tried to justify this disgustingly irresponsible mindset :
" - This combustion engine uses an inferior injection mechanism that wastes 40% more fuel compared to latest...
= Don't waste my time!!! I have more important things to worry about.
-.... It would take 5 minutes to fix
= Customers don't notice the fuel consumption anyway, so that means robbing them out of money with inferior engineering is okay. Now hurry up, we'll miss the daily 3-hours progress meeting. "
If only Donald Knuth knew what " Forget about the small efficiencies" would be used to justify.
The idea isn't that nobody ever tries, it's that the typical amount of trying is really bad.
While it would be nice if everything was optimized, it's really not comparable to a meal tasting good, since that's basically the main reason to have a meal in the first place. Most people don't care about bundle size, especially when it's tens of megabytes versus gigabytes.
> the typical amount of trying is really bad
Again, we really have no way of measuring just how bad it could be. IMO it feels like everything could be way, way worse.
This much space is a pretty big cost. It represents wasted dollars, or shuffling data, or not getting it downloaded in time, or not having room for the pictures you want, etc.
> Again, we really have no way of measuring just how bad it could be.
If five minutes did this much, and this is within a couple orders of magnitude of typical, then we can conclude that the typical effort is really bad.
How much worse it could be might be an interesting thought experiment, but doesn't affect the above conclusion.
It could probably get almost infinitely bad if there was zero cleanup effort. But that's the difference between 1/10 effort and 2/10 effort. If I'm demanding 6/10 effort for a professional product, the difference between 1/10 and 2/10 doesn't matter to me.
You can buy a brand new, unlocked iPhone 12 from Apple. It starts at 64GB for $729
Taking the shortest path to achieve a goal often seems like the good idea, but it leads to bloat and inefficiency. It'd take longer to "do it right" so you never do it right.
But you ignore the fact that all that bloat actually costs you to maintain it. "Not fixing it" is always faster and will always be the shortest path to the next feature... but that next feature gets harder and harder to achieve as the bloat grows. The bloat makes the fastest thing slower and slower while the fastest thing is always ignoring the bloat.
When you appropriately choose when to fix, when to focus on efficiency, everything becomes faster.
The concept is slowing down to move faster.
There's avoiding premature optimization and then there's ignoring optimization forever except for extreme emergencies.
Other than that, there’s unlikely to be a reason.
From my experience being on a mobile development team for a competitor. Last time I checked like most major airlines their team is in house and I’d be in shock if that changed.
Or are they trade-offs?
Do these 'bad decisions' actually impact their business or are they manageable, allowing them to achieve their mission, focusing on other things that are more important?
I can think of how bad decisions could negatively impact their mission and focus:
- App is slow and buggy, pressuring users to choose a different service altogether
- A much larger support staff is required to handle customer issues
- Bugs are painful to address and require weeks or months to resolve
- Developers spend more time fixing bugs and less time working on features, resulting in delayed features and an increased team size to allow more parallel development
* Far too many hands in the pot: My rough calculation is at any given time, there are around 1000 contributors to this app, across various teams. This itself is not a problem, but leads to issues.
* Tech Debt Racks up Quick: Again because there are so many hands in the pot, tech debt racks up unbelievably quickly. And furthermore it's almost impossible to address because it cuts accross so many teams and orgs.
* The Solution? More Hands in the Pot!: With tech debt racking up quick and not being resolved, productivity grinds to a halt. App has constant errors, crashes, and things like hot reloading are just totally broken because of all the underlying issues. So what do you do when faced with this problem? More engineers! Rather than addressing the problems that face developers, they just throw more labor at the problem, compounding the previous issues.
* Code Duplication: With so many folks working on the project but not talking to one another, code duplication becomes a MAJOR issue. Say you have a "Button" component that needs to be modified. Well, modifying that component means going through 5+ teams to get approval. So to sidestep you create "Button2", and the next guys creates "Button3". The result is you pull up the fuzzy finder and search "Button", only to get 15 results with subtle differences.
This is just my experience. Currently this app is top 20 in healthcare on the Apple Appstore. The company also has a number of other apps and when I was leaving the company, there were talks to merge all the apps into the "main" app (good fucking luck).
That said, I don't think the difference between a 40MB app and a 400MB app is all that critical these days. Optimizing for development speed and user experience over an absolutely minimal download size is a reasonable choice.
It's tempting to think about the United app as something very simple:
- Search for flights
- Run through the booking flow for flights
- Look up existing bookings
- Change existing bookings
But this ignores a lot of scope that's actually critical for a company whose products are very complicated:
- ID verification for international travel
- Custom functionality for large institutional cu stomers (government, corporate)
- Functionality for ancillary services: in-air streaming entertainment, in-airport services like lounges and baggage checks, loyalty program, loyalty-tier-specific functionality like priority connections.
- ... etc.
In this case the lack of stripping symbols seems like a very easy win and definitely is an example of sloppiness, but the idea that the binary should definitively be < 100MB seems to ignore a lot of scope.
But please still make them available separately!
AA's comes to mind as possibly the worst airline app out there.
> pushing code into frameworks has been a best practice for a while
This would have really pissed me off if I had to download it over my cell plan. I have one phone with minimum apps on it which I use for day-to-day, and then another with all the scummy bloated apps on it, but the data plan on that phone is small and 500MB would be a huge chunk out of my monthly quota.
At my last job our legal team would have had a cow shipping labels. Our apps are gleaned by blogs looking for scoops on upcoming features.
I once interviewed at a major airline (not United) and at the time they had outsourced their entire app and web to some foreign companies, including any and all oversight. Their app was a POS and they had hired someone to write a new one -- the same company. Now they had no idea why it was so delayed so they wanted to hire someone to embed in the other company to spy on what was going on. Of course I wanted nothing to do with this travesty. This was years ago, no idea what happened.
You'd be amazed at how pathetic mobile development can be even at big companies. Mobile doesn't have to be hard, but if management tries hard enough, can make crap at scale.
My biggest is the UI only considers one half of a RT “trip” a trip.
Oh it goes deeper than that. Almost every airline (Southwest is the only exception coming to mins at the moment) also outsources their web design, their pricing structure, and their availability tracking. I've worked with several airlines that legitimately could not give us a list of all their current routes. Some of them actually paid us to scrape their website and tell them where they're currently flying and how much it cost on average.
Maybe some carriers should integrate with Duffel and build their apps on top of the Duffel API instead of shipping all the logic off to accenture or whatever
Last week I came across some unminified JS on United's website[0]. I love the warning it starts with:
/* Minification failed. Returning unminified contents.
(5218,49-69): run-time error JS1300: Strict-mode does not allow assignment to
undefined variables: nearbySearchErrorMsg
*/
[0] https://www.united.com/ual/bundles/js/flightsearchresults
They don’t need symbols to find stuff…
- Flight at 11AM, boarding at 10:20.
- Show up at 10:25, boarding doors are closed.
- "Didn't boarding start 5 minutes ago"
- "Yeah we close the doors once 95% of people show up, sorry, you should show up when boarding starts"
- "Yeah but didn't boarding start 5 minutes ago, how was I to know"
- "You should have known, sorry"
So they are essentially scamming 5% of passengers out of their tickets?
There's a bit of a checklist of things that need to be completed after the door gets closed and the gate pulls away. They're often incentivized to try and speed things up, so if there's nobody at the gate anymore to board they might assume those passengers decided not to go on the flight. Especially with people now checking into flights the day before, the airline may not even know if the passenger is even at the airport and would realistically show up to the gate anytime soon as checking in means pretty much nothing these days.
They're not scamming anyone. Your ticket said you were supposed to be at the gate to board at a certain time. You weren't there, so you missed the flight.
If the door closed at flight time then the plane wouldn't be leaving at flight time, it would be leaving at flight time + the time it takes to go from boarding to getting in the air. Flight time is the time the plane is scheduled to take off, which means the flight time would diverge from the boarding time, and then you'd once again be asking why the boarding time is different from the flight time and why they don't let you board until the flight time, rinse and repeat.
They can still go early if all of the passengers have boarded.
I got to Dublin airport once at the time that the gates were supposed to close and they said they would wait for us if we were fast... Got to the concourse and it was the furthest gate possible - the sign said to allow a 15 minute walk! Had to run all the way but we made it.
And there's a time in the US as well, that's called the boarding time. Those there at the boarding time get on the plane, those aren't there at the boarding time missed their flight. Banking on getting on 5-10 minutes after boarding time is gambling that they're running behind schedule.
> All Passengers must be present at the loading gate for boarding at least 15 minutes prior to scheduled departure.
The OP was clearly involuntarily denied boarding even if it was an international flight, and is eligible for that compensation.
https://www.united.com/en/us/fly/contract-of-carriage.html#r...
Once they started boarding and the queue is empty, they will continue with the procedures for the flight, they have an incentive to keep their on-time stats. It’s not like a train where you can simply step in a minute before it leaves.
Some airlines print a boarding time for their flights onto their boarding passes, or show it in their app. This is often a fake number simply computed by deducting 30 or 40 minutes from your flight's departure time; it's certainly not adhered to very closely or involved in most contract of carriages.
One reason for this is that an airline is usually not involved in issuing all of its boarding passes, and so many boarding passes simply do not have a "boarding time" on them. Air India is perfectly capable of issuing boarding passes for United, but are unlikely to have easy access a "boarding time" from United (since it's not very important).
United makes passenger obligations clear -- arrive 15/30 minutes before a domestic/international departure. Otherwise, it's an IDB.
What the parent quoted seems to be United's actual policy, i.e. that they'll accept any (domestic) passengers who arrive 15+ minutes before departure.
UA's team has access to exactly when the door closed and if it was greater than 15 minutes before the scheduled departure time, they owe the OP.
It sounds like you're saying the United app noticed your phone was rooted, and somehow it notified the on-board WiFi to block your ip/mac? Or am I not reading this right?
(one solution if that's really how it works: rotate your mac address, reconnect, and then never open up the United app again so it can't squeal on you.)
What is wrong with using their app on a rooted phone?
Also, they typically store more personal info than, say, an e-commerce application because some of it is needed for travel. Things like date of birth, known traveler numbers, names/dob/etc of family members, passport numbers, etc.
https://www.cnn.com/2015/05/17/us/fbi-hacker-flight-computer...
> During FBI interviews in February and March, the document says, Roberts told investigators he hacked into in-flight entertainment systems aboard aircraft. He claimed to have done so 15 to 20 times from 2011 to 2014.
> He also said, according to the document, that once he had hacked into the systems and then overwrote code, enabling him to issue a “CLB,” or climb, command.
> “He stated that he thereby caused one of the airplane engines to climb resulting in a lateral or sideways movement of the plane during one of these flights,” the document says.
I am interested in the linked story, but it's very odd that a passenger wifi network would be cross-connected with flight controls.
That the network on a non-wifi seatback entertainment system could be is a little more believable, but I'm still curious how it wouldn't have resulted in an extended grounding of all aircraft of that type if it were true. There was no grounding, or order to modify that system following his twitter posts and subsequent arrest.
Edit: If you search around for what happened after the incident described above, it seems pretty clear he did not send any commands to flight systems. He seems knowledgeable about them, but seems to perhaps have been caught out talking about a theoretical scenario as if it happened. He wasn't charged, and as mentioned, no actions were taken to change anything. I suspect the networks are properly isolated.
Not really, but it's also actively suppressed. If they can make as much money with a 439MB app as they can with a 10MB app, why would they waste any time or effort trying to save you a few minutes of download time? If anything, I expect this to get worse, as management is constantly pushing for adoption of frameworks that (in their imagination) speed up time-to-market.
I wonder how crazy it would be to cache the iOS app… like maybe they run a caching transparent proxy on the plane… or some crazy relationship with a CDN that treats each plane as an edge node.
I dunno, it would probably be pretty be way to expensive to set up something like that to be worthwhile.
https://support.apple.com/guide/mac-help/what-is-content-cac...
United really wants that download to be fast, so customers can get the app before getting on the plane. Otherwise you end up with a bunch of grumpy people your that your flight attendants have to deal with.
I've been on a few budget carrier flights that have skipped the headrest display for an airline app. They haven't had external Internet access, as it's just served over a local WiFi connection from an onboard server, so you must install the app before you take off.
If I'd perhaps been connecting from a different country with United flights, there's no way I'd download it over roaming data "Welcome to Jamaica ... data is €3.05/MB".
It costs consumer time waiting for a large app to download, and it wastes consumer money by burning up quota on metered connections. It costs the business because apps have a size limit, and hitting those limits means no more features until you can reduce that size.
Yes? Have you actually seen this space?
There are tons of shops that get this stuff outsourced to them.
They have executives who gleefully cackle at the idea of hiring the bottom of the barrel developers who wouldn't even know to strip symbols, and cackle at the idea of cracking whips at them so that even if they did know they wouldn't have the bandwidth to do it. All while charging hundreds of dollars per billable hour.
If anyone at United wants help, happy to chat! josh@emergetools.com
There was an HN thread about it, too, but I can’t find it.
I think that it's unreasonable to expect a Lambo (or even a Yugo) to accommodate a 300Kg man.
But no comments, and no votes, so it must have been another thread, thereabouts. It was quite some years ago.
https://drive.google.com/file/d/16lDaCfEjT7Z72EEDFBo5r3lTDCV...
I'm not sure what I just read though.
2015 (scale) - https://news.ycombinator.com/item?id=10271586 https://news.ycombinator.com/item?id=10066338
2018 (491MB) - https://news.ycombinator.com/item?id=17995954
2020 (Messenger) - https://news.ycombinator.com/item?id=22466462
2020 (SDK) - https://news.ycombinator.com/item?id=23790207
The original version was 18MB. The official Facebook-written version was nearly 300MB, with the bonus that it disabled the old app.
I wrote about it then: https://medium.com/hackernoon/how-not-to-transition-an-app-b...
The same ninja-optimized app can be less than 1kb. All the useless space is taken by libraries, features "just in case" like login and assets, and more runtime generic things.
Supposedly all that generic stuff should help for more complex apps, so for a very simple app the ratio used/unused is very high, but for more advanced apps it is low which means that the size of apps should not be linear with complexity
...yet they are, because the more complex an app is the more useless libraries are included.
Which one do you think Apple cares more about?
1. Faster update downloaded to devices compared to before & to Google/Android. That's a big PR win.
2. Most badly behaving apps have tons of unnecessary process & their binaries. Also storage is taken up by UI assets. If these are streamlined & reusable, the footprint goes down. That means less RAM can still do fine.
But it wouldn't move the sales needle. Nobody is going to switch from Android because they were waiting for smaller download sizes.
> less RAM can still do fine
That's bad for Apple because it discourages upgrading.
Size and RAM (and indirectly a modest battery life gain) will be a win for whoever uses, regardless of our personal views on this matter. When developers throw in big frameworks mindlessly, they assume best case use. Minimalist and efficient coding will actually win across the board whichever way you look.
As far as Apple devices go, they are getting support way longer than Android flagships. Apple is devious possibly in many ways, but they don't get to win by 'planned obsolescence'. Much rather the opposite: as new generations of devices come in with newer hardware, they don't have to crazily support a lot of firmware and instruction sets. Only the ones which satisfies the newer frameworks. If they did, they will turn out as another Intel (which famously supported a lot of opcodes all the way back to 386). Their fanbase has some (valid) strength based on a lot of older generation devices still getting OS upgrades which they might normally wouldn't have.
The video player does give me problems sometimes though
I mean, there's virtually no one taking a flight without at least a phone if not a laptop/tablet with them, and most of them probably have a much better screen and headphone support then whatever outdated stuff would be built in to the plane.
The only thing I really miss on flights that don't have the seat backs is the thing that shows the altitude and progress on the map.
But you can get that on their app as well.
I think flights should do-away with in-seat entertainment. I very rarely see anyone using them, and if you are unfortunate enough to be in economy, they actually take up quite a lot of your personal space.
All the screens must weigh a ton as well - bad for the environment.
Do I also have a phone? Sure, but the screen is smaller and I have to hold it. Do I also have a laptop? Sure, but if the person in front of me reclines quickly I don't want to hear a crunch.
In economy I'll use the in-seat thing to watch something, and leave my laptop in my bag. In economy-plus or higher I'll put a movie on the screen and write some code on my laptop.
On the AC flights I've taken I'd estimate something like 80% plus of the folks on the plane are using the in-seat stuff to watch something. The rest are asleep or reading a book.
I got the job.
Probably doesn’t make that much of a difference in the long run, but I have a theory that smaller binary sizes increase chances of any given user being up-to-date, thus increasing the percentage of the userbase that’s running the latest version at any point in time. iOS tends to pull updates while charging, and so an app that’s 10MB is more likely to get updated during a brief charging period than an app 50x as large, especially if the user in question has a slower connection.
It also makes for smoother troubleshooting when the user can pop into the App Store page for your app and have the app updated almost instantly.
I suspect it's more that their devs are either junior and don't know any better, or more likely that they just don't care. I've also met some devs who believe whatever comments they read on HN, like "file/memory size don't matter"
TBH I see this as a positive - less weight on the plane, less fuel consumed, less waste when these screens are junked, etc. I personally always take a ton of videos with me and just watch my own stuff, I would never trust that the in-flight stuff is working (although I admit I overprepare and it's still important to provide this). And when you're flying - having the app installed is a net positive, it has maps of the airports (with great directions, which is super helpful when you're making a connection), can manage your ticket, etc - the videos are a bonus.
For a plane that's negligible.
Tbh, I don't want to sit on a 12hr flight watching a phone screen. I have to hold it on my hand, have nowhere to put it while eating, I have to plug it in to a charger as well (and it's never guaranteed there'll be a plug) + what the OP said about having to download more stuff to my phone I don't want or I might not have space for.
It's a moderate weight saving, there are some details in this article: https://www.fastcompany.com/3034196/airlines-are-tossing-sea...
439Mb? That's horrific.
If I was cynical, I'd say it's in Apple's interests to have bloaty apps, so they can sell more expensive phones with more storage and memory.
But that would be cynical.
It feels like a failure at every step in the tool chain if a binary comes out at that size.
But, make your builds reproducible and/or save your debug symbols as part of your release process, it will be something you wish you did otherwise when you're not quite sure if the stack trace you have is correct.
Notably, the Google Play Store doesn't even show the app size. I bet just showing it below the download button would already create significant pressure to reduce size. Both major stores used to have some form of limit - either a hard one, or a soft one where users would get warnings or the apps would only be downloaded over WiFi - which kept developer madness in check, but that seems to be gone now.
Some banking apps are the worst offenders, because banks know that few people will change their primary bank just because their app was too big so they don't care at all. Revolut is 200 MB (for comparison: Chrome - a complete browser! - is 50 MB), and that isn't the biggest one on my phone.
I'm a real "dependency skeptic." Doesn't make me too many friends, hereabouts.
I'm also not a fan of running Web code on the phone, like a lot of PWAs and hybrid systems. Again, doesn't make me popular, in this crowd.
If the main app runs afoul of stripping symbols, then the App Store inspection can flag it. If, however, it's a dependency, then I could see them tossing out boatloads of apps, simply because they include piggy frameworks. There's really no automated way for Apple to realize the framework is really just the developer's aggregated code, or from another source, over which the developer has no control.
What really needs to happen, is that the developer has their own inspection regimen, before submitting something that could cause brand damage, to the App Store.
Again, suggesting stuff like this, is tantamount to heresy, in today's "Move fast and break things" tech world.
This is Apple's industry, we're just allowed to play in it.
Obviously there are user benefits to smaller apps, but as a developer I feel that the app size is a proxy for app complexity and dependencies. The smaller the app, the less third party dependencies and the less maintenance required to keep it up to date and running on the latest OS releases.
As a comparison, the biggest competitor to my app AdGuard is a 450MB download on the Mac versus a less than 10MB download for my app (Magic Lasso Adblock).
Do most users notice? Not sure but overtime I've actually made my app size smaller simply by replacing unnecessary third party libraries with in-built, simpler functionality and it's become a more pleasant app to maintain.
BTW: The last couple times I've run into this, they say use the app, but there has been a plex/etc like http video server on the onboard Wifi network which can just stream to random browsers/PCs/etc. I've yet to have any DRM/etc issues, although I suspect that might be part of why they want to push people to dedicated apps. A large number of people though just use their locked down work laptops/etc so they will have a problem when they cut off that path.
https://9to5mac.com/2019/06/03/ios-13-removes-200-mb-file-si...
Sure stripping out symbols is a quick thing you can do, but how about eliminating the ad tech stuff (people already bought the ticket, leave them alone). Remove the dependency of 3rd. party libraries and frameworks, utilizing only the built in frameworks (or does that not make difference in iOS applications?).
While some cos have “appliances” that ISPs can install that’ll dramatically reduce back haul bandwidth usage, I’m unaware of any that make any that work for a small community or aircraft. SSL really impacted the use of general-purpose proxies to save bandwidth. Maybe more torrent-based schemes for app stores and others could fill this gap.
> Apple also supports incremental downloads, meaning you can download a “diff” of app binaries in some cases (also amazing!), but this is even harder to measure on an actual device. In my case I was trying to download the United app for the first time on a runway before my flight took off.
What would be interesting is if Apple did this diff between apps, since I’m sure a lot share frameworks and other bits.
You can strip the main executable but stripping frameworks is a VERY VERY bad idea.
Conversely, it may be that only bloated tech will survive, as bloat drives sales, and sales means survival.
In fact it's quite the opposite, as another poster mentioned: they will offer to rent you an airline ipad for the flight so you can enjoy their content at a little extra fee.
I would imagine this is basically an Electron for iOS and Android? If that is case I am not surprised at the file size.
https://bjango.com/articles/svgassetcatalogs/
It's my understanding, as a designer, that it was auto-generating 2x and 3x PNGs as from your vector assets, and that's what actually got bundled in the final app—and that PNG compression was not good compared to what I could get by going through ImageOptim.
I would be quite happy to be wrong about that. It would save me a lot of time.
Based on some of the names of packages I don't recognize (CYFDCTEncoder) and some googling I'm going to guess the company was CYFuture.
Electron and web developers, take note.
(If the Netflix app is too big to fit on the phone, Netflix loses a customer.)
> Wow! I honestly wasn’t expecting that much of an improvement. We shaved 187MB off the app size in five minutes by stripping framework symbols.
It's kinda disgusting really.
WeChat enters the chat...