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.
But even the stripped version is way way too much for an app like this. I can imagine it's layers upon layers of poor, bad and terrible architectural and organizational decisions.
I’d like to approach this differently, and think about what it would have cost United Airlines to do it “the right way”, versus what value it brings them.
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.
Contrarian opinion here; I understand their logic. It looks like a rational trade-off that the engineers have done.
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.
This bizarre reasoning puzzles and infuriates me so much. The linked post shaves more than 40% of an app's size in 5 minutes, by doing nothing but being curious about the half-gigabyte app and knowing how to use a couple of tools.
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.
I share your feeling. Day by day I feel more guilty of belonging to that industry because of the laziness, sloppiness, negligence, acceptance of spying, of dark patterns, etc, and I do not disclose what I'm doing for a living more readily than I would if I worked for some mafia.
There’s a parable about a mechanic that spends a couple minutes finding a screw to tighten and charges a large sum once they’re done. It was a few minutes of work for them, yes, but it took a lifetime for them to get to the point where it’s a few minutes of work. Of course, the situation here is not quite that extreme, but acquiring the skills needed to know where problems are is uncommon and nontrivial.
There’s probably an observability bias here. It could be that the app sizes would be 3x worse, if no one ever tried. You would never know, because you only see the app sizes after people have done the work.
This is in response to someone who’s clearly infuriated by a wide variety of inefficiencies they see. The point is, no one is praising the people who do optimize their <whatever> because you would never know it was even an issue that got solved.
Oh, nobody is praising the other apps? That's true but these are very basic expectations. If you're a chef and you burn every tenth meal then either you or your management are making very bad decisions, even if the other 90% are fine. And app and website bloat seems to be significantly more widespread than that.
The idea isn't that nobody ever tries, it's that the typical amount of trying is really bad.
When eating a meal, how the meal tastes (burnt) is at least #2 on my top priorities (just below whether it will lead to illness). When consuming an app though, bundle size has got to be at least #5, far below something like "Does the app do what I want?" and "Is it performant" etc.
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.
> When consuming an app though, bundle size has got to be at least #5, far below something like "Does the app do what I want?" and "Is it performant" etc.
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.
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.
And even 2 of those 8 GiB were taken up by the OS. So that leaves just 6 GiB. Now we’re already at 7%. That’s valuable storage that you cannot use to fill with holiday pictures.
Perhaps not but everyone saying this is what kills accessibility for those who need it. This is the same argument made by companies to not support deaf/blind people.
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.
I don't know if you're trying to make a point about global living standards (irrelevant) or the non-necessity of air travel (true, but also irrelevant), but the fact is that budget airlines have existed for decades, and are often comparable in price to a bus trip.
For a lot of trips, Amtrak is about the same as flying. Looking at a round trip from NYC to Chicago, on the arbitrary dates of March 26 to April 9, Amtrak costs $180 while Kayak shows the cheapest flights at $159. Of course, Amtrak takes much longer (20 hours) but is less hassle, and at that price the flight only lets you take one carry-on while Amtrak lets you bring two checked bags and two carry-ons. Adding checked bags will add $60 for the first and $80 for the second. Amtrak is also better for the environment if that matters to you, and the price difference is about the same as the cost of the carbon offset for the flight.
Overall, choosing Amtrak or flying is perfectly reasonable in different situations. Amtrak could definitely be improved a lot though!
NYC to Chicago probably has a decent customer base to support that price point. For amusement, try Miami/Seattle via Amtrak. It's possible, since I looked up the route [1]. One week transit time one way, at $2,000 (I don't recall if the price was round trip or just one way). And trying to work on the train was fun (too "swishy" to use the computer: http://boston.conman.org/2015/08/05.2). Totally not worth it for me. Sadly [2].
[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.
I don't think I kept it, but a couple of years ago I made a video of a £1 coin (as thick as two US pennies) balanced in a shallow groove in the table on a long distance train in Denmark. It was about 30km before it fell over.
(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.)
That's somewhat a different definition than the comment I was replying to. There are plenty of people who may want to fly somewhere who aren't going to upgrade their phone to the latest and greatest every two years (which is what the comment above was implying: that since flying is supposedly a 'luxury' item it can be assumed that the customers have the latest and greatest phones).
Southwest is not really the equivalent of Ryan. Spirit airlines has plenty of $22.22 flights (for two's-day, I guess), glancing at their page today. This includes e.g. Chicago to Tampa, Texas to NJ, and other flights longer than most European flights.
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.
I’ve been on a flight between Berlin and London that cost less than an Amtrak return ticket from Davis to Sacramento, and I’ve also been on a multi-day road trip from Davis to Salt Lake City that, while fun, was only a good financial choice due to four people squeezing into a Prius.
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.
In general flying is more expensive in NA because of less competition and bigger distances. That's what I noticed when I moved from Europe to here. Now you have to take expensive tests to fly international both ways. That's why I consider it a luxury.
Downvotes because you seem to think there is something special about flying in Europe? lol. It is a similar size to the US within a reasonable estimation, let alone the whole of NA, which is probably what 3x as big?
The assumption here is that a luxury-oriented audience would always want the latest phone. I disagree with that. If I'm rich, I might just not care about upgrading because I have better things to do. Or I like this particular 7 year old phone, so I keep it.
The iPhone is not a luxury product; not in America, anyway.
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.
I don't know why this downvoted. Apple dropped latest iOS support for 5c in 2017.
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.
This is not the most relevant tradeoff. The United App is the only way to watch in-flight entertainment on many United Flights (esp. on newer planes without seatback screens). Every time I fly United, they make an announcement that says "Make sure to download the app before we take off because you can't do it once we're in the air!" and then I see everyone whip out their phones and tablets. Usually that's 10m or so before we lose cell reception and it's often not enough time to fully download the app.
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.
Maybe Apple could provide some way to cache apps on a local network without needing a Mac. (macOS has a content caching option in the Sharing prefpane.) They could add the same thing to iOS/tvOS to make it cheaper and more widely available. Ideally there would be a containerized version of the service that could run on any Linux-ish device...can't imagine Apple doing that though.
But this company can't even be bothered to even strip symbols. Having Apple allow caching + putting this in every single airplane is a way more difficult (and certainly more costly than spending 5 minutes stripping symbols and other things).
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...
Most airlines won't let you order adult beverages in economy, certain United flights (SFO to IAD (D.C.)) appear to be an exception. But yes. And you need to re-fill in, manually your flight info and seat number. It's a whole process. This is after connecting to their in-flight wifi, which has it's own hurdles.
> what it would have cost United Airlines to do it “the right way”, versus what value it brings them
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.
> 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.
> Increase developer productivity at the expense of hardware
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.
>Contrarian opinion here; I understand their logic. It looks like a rational trade-off that the engineers have done.
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?
When someone starts looking into why it's so big and they immediately discover a huge dumb mistake (the example in the post), why do you assume that the rest of the app size is because of rational tradeoffs, instead of being more dumb mistakes?
Yep. Airlines are one of the few brand apps where there probably is a significant business case for spending developer time optimising an app for download size, since customers who make the decision to try to download United's app on slow or metered connections at the airport or overseas are probably customers ready to be upsold stuff via the app.
> 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 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.
Here is today's car analogy : well sure, they pollute, but if nobody complains why would car makers invest in cleaner, more efficient motors? Oil is cheap anyway and will be cheaper in the future (that's probably what they thought in the '60). Oh, wait...
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.
you didnt factor in the mobilw bandwidth to download this oversized crap constantly. with 1gb plans in mind how many downloads a month do you get to instagib a plan like that? and for what, no actual patch notes ever?! at least most apps dont hard lock you out when they detect being behind
Yeah no, clearly false, because my iPhone has 8 GB and that ought to be plenty. Hope your web app works on my phone, ‘cause I’m not installing a bullshit app with that much bloat.
> I’d like to approach this differently, and think about what it would have cost United Airlines to do it “the right way”, versus what value it brings them.
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.
Exactly - badness of waste is non-linear. An application that's 4x as large as necessary is more than twice as bad as one that's 2x as large as necessary.
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.
"The Right Way" involves running the strip command before sending the app off to Apple for publishing. It's 5 seconds of effort and saves almost 200MB for literally thousands of users.
I'm willing to bet that the devs who made this app have never worked with a decompiler and have no idea what "symbols" are. Source: I am one of those people (well I have a vague idea, but certainly wouldn't think to check if that was causing bloat in my iOS app).
You’d think the right way would involve Apple refusing your app if it is wasting users storage because you couldn’t be bothered to strip your binaries.
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.
Last time I had to download an airline app was at an airport via the public wifi. You better make it small if your users are people that might be on the road in a foreign country.
This is maybe part of it, but having shipped a macOS app that’s stripped of symbols, crashes can still be debugged as long as I’ve got the dSYM file that was made at build time, so I don’t think it’s a super strong argument. Tools like Sentry will catch the crashes and symbolicate them for you, if you’ve provided them with the dSYM. It can be done on the local machine too.
> And I can only imagine that they outsourced their app development completely and like to keep costs low.
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.
If Apple would allow web notifications, most apps wouldn't need to be apps at all, but could simply be webpages that get bookmarked to the launcher. The UX for the user would be, for most non-game apps, identical.
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.
I strongly suspect the bulk of this 500MB is DRM frameworks for their in-flight video playback that they can't or don't want to support in-browser. Safari kicks video playback over to the United app each time you select something to watch and it does what appears to be a multi-stage hand-off dance.
"The UX for the user would be, for most non-game apps, identical."
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.
It's also hard to maintain two entirely separate apps in two entirely different languages for two entirely different platforms/APIs, all while giving up nearly a third of your CLV to a rentseeking middleman.
What we need is better support "native hybrid" apps.
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?
As a frequent and mostly non-loyal flier, I can say despite all its faults the United app is far and away the best airline app in the US: fast, easy to navigate, powerful, useful and often pleasantly surprising. American is the only other app that compares, I can't stand to use any other airlines' apps.
In this case, shipping symbols with the app is almost certainly an oversight. Stripping symbols of shipped binaries is standard good practice.
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.
Shipping a 40MB app instead of <10 MB is questionable except for large apps; Dolphin on Android emulates an entire GameCube/Wii, yet the APK is only 16 MB (34.7 MB extracted). Shipping a 400MB app is shameful.
Not to mention the surface area of the app is often larger than it appears to a single user, especially for companies this large whose customer bases are this wide.
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.
Not just good practice, it's default with Xcode. Someone must have messed up some configuration/flags while they were breaking the frameworks up maybe?
As a long time united frequent flyer, while I have many gripes, they have consistently made the app better and better without useless "redesigns for the sake for redesigns"
> I can imagine it's layers upon layers of poor, bad and terrible architectural and organizational decisions.
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've worked on one of these apps (healthcare space, just checked and the size sits at 350MB). Here's the problem as I saw it firsthand:
* 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).
Without diving into specifics we'll never know of course. But consider the opposite: would good decisions positively or negatively impact their business? Would they prevent them from achieving their mission or focusing on other things?
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
Just checked the other day: one of my favorite apps this year, Hyperweb, is just 18.2 MB. Granted, it's only a browser extension for adblocking, styling, etc (sort of a replacement for all of the various Firefox addons I wish I could use on iOS), but the competition, AdGuard, clocks in at nearly 500 MB.
I really wonder what some of these apps are doing with this space. My banking app clocks in at 400 MB as well.
Just for some perspective, the entire installer package for the Shareware version Doom took up about 2.39MB of space. This included the EXE and all art assets. The installer for WordPerfect 5.1 (DOS) was about 3.6MB. The full on-disk footprint of Microsoft Office 95 was less than 100MB, including all documentation, Word, Excel, and PowerPoint.
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.
DOOM2.WAD has always been my measuring stick for software size, as I remember how frustrating it was to download such a huge file (15MB!) in the dial-up days. I never did get it to complete - I couldn't justify to my parents that the phone line would be busy for a whole day :)
Keep in mind that even on the free version, you can add (unlimited?) adlists. I've added some of the most popular uBlock Origin default lists to mine to make the ad blocking even better. It is absolutely insane how many apps Hyperweb replaced for me, too!
Strange, the download from the app store (https://apps.apple.com/us/app/adguard-adblock-privacy/id1047...) is 100 MB, but my install somehow crept up to ~400 (logs, maybe?) over a couple of years of use. I don't have it installed any more, but it's wild how much this varies across devices. What phone do you use? I use a 2016 SE, I wonder if there's a bug that's consume extra space on a device as old (and likely untested by AdGuard) as mine?
I don't think the Stripe app is a good comparison. Airline apps have to cover shopping, booking, cancellations, seat selection, loyalty programs, check-in, bar code generation and scanning, and so on. Typically with broad support for different currencies, languages, etc, etc. 439mb is obviously not right, but I would expect the app to be fairly large.
> Airline apps have to cover shopping, booking, cancellations, seat selection, loyalty programs, check-in, bar code generation and scanning, and so on.
That may be true for some airlines (webviews vs native), but it is not true for many. Boarding passes are probably a good example. It's very typical for that functionality to use something like Apple Wallet integration, and also native widgets to upsell cross-sell boarding/seat upgrades, etc.
Passes already in the wallet don't require you to be online. But, what I meant was that there was additional code, thus additional size for all the functionality and ui related to boarding passes, whether or not parts of it don't work offline.
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 think one needs to understand the mentalities of the project managers and programmers/contractors who actually work for those behemoth corporations to understand the quality of their work.
This seems like a huge market opportunity for a service where you upload your "final" binary and some app goes through the thing and shows you all the stupid you are doing and how to fix it.
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.
Couple bad development practices with archaic technology for ticketing and we get the worst of both worlds. I've worked with two airlines and it was fairly frightening to see what type of BS they're working with and against.
I spent the last ten years of my career building iOS apps, all but one you would likely known at the time, and whoever in charge of this app is an idiot. Shipping an app to the general public with symbols intact? Really? If they didn't know/didn't care, it tells me no one there likely cared about any other quality issue either. It's highly likely that any relevant lead person probably screamed about this daily, but higher ups don't give a shit.
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.
> 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
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.
I like what Duffel is doing as far as creating a nice, consistent airline booking API goes: https://duffel.com/
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
Duffel is interesting, I wonder what they use on their back end. I've written airline booking API when I was at an OTA (now sadly gone like so many) on top of our parent company's res system. It can be complex, made more in my case so by the pathetic res system itself and its limitations. In fact at the time we had no way to do test bookings without real money (and mostly un-refundable except for a single route).
I travel on United probably 6 flights a month on average. Overall I think it’s a pretty good app but like anything I use routinely, I could easily come up with a list of 10 complaints, from a UX perspective.
My biggest is the UI only considers one half of a RT “trip” a trip.
It seems like multimillion $ companies everywhere can simultaneously declare widely that mobile is their future, point to stats like 75%+ usage of their services is through the app interface, and then basically their entire dev/maintenance crew is one person stretched across multiple projects already.
I once flew United and, like the author, didn't realise this until I was on the plane for a ten hour flight. Downloaded the app for Android. I opened it. I was immediately ip-blocked for having a rooted phone, which was then kicked off the network and couldn't get an IP address. United cabin crew then started trying to sell me an iPad loan for the duration. I read a book and vowed never to fly with them again.
They managed to board all the other passengers in less than 5 minutes? In my experience boarding takes at least half an hour just for everybody to sit down. Was the flight exceptionally empty?
I mean, you're supposed to be at the gate when boarding starts. For all practical purposes if you miss boarding you've missed your flight even if the plane hasn't left the ground due to safety rules about letting passengers go after the door is considered closed.
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.
Luckily, common air carriers do not run on anarchy and made-up rules. United, like every airline, has a Contract of Carriage, which clearly requires being at the gate only 15 minutes before a scheduled domestic flight:
> 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.
There is a boarding time on every ticket. Anyone who has flown more than once knows this is not optional - closing the gate and departing early is at the airline’s discretion.
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.
There is not a boarding time on any airline ticket; you can book a flight for yourself and look at the issued eTicket. Your ticket will only have a departure (and perhaps arrival) time.
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.
Right, I meant boarding passes. Since as you said, (estimated) boarding time is usually set to 30-40 minutes before departure, and gates usually close 20m-15m before departure, arriving 15m after the announced "boarding time" is obviously risky. Not sure what's up for debate here.
According to what? To me "boarding time" doesn't mean anything other than the time they plan to begin boarding. Is there actually a policy that passengers must be present by that time?
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.
I get that rule. But why does the door close at boarding time and not at the flight time or some predetermined time like 10 minutes before flight time or when boarding completes, whichever is later.
The door closes when it seems like there's no more passengers so they can hurry up and start working on the checklist. They do this so they can potentially get going sooner in case there are delays elsewhere in the many steps that goes from passenger boarding to plane in the air. Theoretically they could be more rigid about having a time for the door closing, but that could potentially mean there are more actual delays as now they no longer have a chance to gain some time in their schedule to make up for potential delays elsewhere.
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.
Sounds like you're describing some impossible system but that is how it works in the rest of the world. There's a time at which the gates close, and if you're at the gate before then then you can go on the flight. If not then they might wait for you for a bit if you've already checked in but nothing is guaranteed.
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.
In that case, every single airline in the US doesn't care about their passengers' time because I can't remember the first time that boarding actually started at boarding time. And when it does, I'm stuck waiting an extra 15 minutes so all the priority and higher class passengers can board first.
I have trouble believing this is the entire story. You're saying you were at the gate thirty-five minutes before the scheduled departure time on the originally scheduled flight and were denied boarding? I could see this happening if there were a delay that was later truncated. In that case the airline does often expedite boarding to make up for the delay.
> 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 doubt it. You can bring a "rooted" linux laptop onto the plane and it works, so banning rooted phones from inflight WiFi would be a little silly.
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.
I hate when apps lock out rooted Android phones for "security purposes" when it's so simple to get around it by just directly accessing the API or spoofing. It's even dumber when the app/website can be accessed through a laptop which is much more permissive than a rooted phone. I've never heard a reason for why companies do this.
I'm surprised there would be that kind of integration between the United app and their on-board WiFi, which appears to be run by Panasonic.
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?
That's also how I read it, which astounds me. Would be technically impressive if it worked like that. And extra vindictive since even if they don't allow rooted devices to play DRM'd video, there's no good reason why they should also be prevented from buying in-flight internet.
(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.)
This is pretty common, as stupid as it is. Snapchat would do this too for jailbroken phones, only they'd also permanently ban your account. It was an arms race between snapchat and tweak developers masking jailbreak detection methods for years at least, maybe still ongoing.
The odd part is tying the airline's app to a wholly separate thing run by Panasonic (the onboard wifi). The United app isn't required, involved, etc, in purchasing and using wifi on the aircraft. No app is required at all...just the browser on the phone. That's why we're confused about the integration that would be needed to accomplish this. The United app would have to be detecting the jailbreak and then sending some unique identifier to the third party via some separate channel.
You could also wreak some havoc by banning the macs of other devices on the plane that want to use the WiFi...so I'm pretty skeptical this cross-service integration is really there.
Not saying it's the right decision, but probably because they don't want the liability if a rooted device allows some 3rd party app to hack theirs. Airlines can be somewhat like a small bank in this respect, as being logged in gives you access to things like accumulated loyalty points, not-flown-tickets that can be exchanged/refunded, past flight credit from earlier refunds that were eligible for credit but not a cash refund, etc.
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.
At that rate why not also ip ban any general purpose compute device from accessing their servers? I can't believe a major airline has programmers who think blocking jailbroken cellphones would do anything at all to thwart a hack. It makes me think twice about flying United certainly if these are the incompetent hands I'm placing my trust in.
Not that I agree with it, but the usual line of reasoning is that they have laxer rules on a native app. Like no captchas, much longer session timeouts, etc. So they aren't comfortable with the looser rules on a rooted phone.
Once again, things that are trivially bypassed by people who are active in this space, and their programmers should know better than using this line of reasoning that must just be ancient procedure at this point, especially considering the cargo they are tasked to ensure is safe.
Not defending the blocking of rooted devices, but I think it's excellent that airlines are relying on people bringing their own hardware. I think you'd struggle to find a single person in an airport who isn't carrying a screen with them today, so seat-back screens feel very redundant to me.
They aren't doing it to be green, they are doing it to save money on chair replacements. I'm surprised how rare it is even to get a seat with power hookups these days. Even in the actual airport itself plugs are still relatively rare and closely guarded, actual functioning plugs rarer still. I remember when economy meant a new set of headphones and the billboard top 20 playing from the arm rest.
As a person who carries a 5.4" iPhone 12 mini, please keep seat-back screens. I wouldn't mind if they were just HDMI-devices I can extend my devices screen to though, that would be amazing!
> it is fair to say this area of app development is complicated to understand.
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.
The size of the app is hurting their on-boarding funnel, they just can't see it. The most likely place you are going to download the United App is in the airport just before your flight, on mediocre free wifi.
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.
That'd probably work a whole lot better if the app wasn't 439MB.
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.
They spend a lot of money trying to offer competitive features on their flights - like maybe watching streaming videos on the plane enabled by the app. To the extent that passengers can't finish a 439MB download of the app just before they board, the app size wastes investments in services of the airline.
Don’t these airplane steaming services have a local copy of all the movies on some storage device inside the plane?
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.
Actively suppressed by whom? Is there some shadowy cabal of executive saboteurs gleefully cackling at the idea of getting away with a bloated app? Because it’s plainly obvious that a bloated app benefits neither the consumer nor the business.
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.
> Is there some shadowy cabal of executive saboteurs gleefully cackling at the idea of getting away with a bloated app?
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.
Looking through the old texts I have from my phone provider, it would cost me €4 to download even 10MB over roaming data if I was in the USA ("Welcome to USA ... data is €0.40/MB"). That might be worthwhile in some cases.
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".
This is awesome to hear! I'm actually one of the founders of Emerge Tools (mentioned in the blog post), we work on helping teams just like United fix problems like this. I had actually tweeted at United in April of last year letting them know about these issues: https://twitter.com/jshchnz/status/1379154466872549377
If anyone at United wants help, happy to chat! josh@emergetools.com
On android, the default Hello World example when you load Android studio takes more that 1MB, and it's a single screen with two words displayed.
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.
I think the most effective way to fix this systemic problem would be for app stores to start charging developers for app size, both for storage and outbound transfer. And for desktop apps downloaded from websites, all hosting providers and CDNs should start charging for egress like the big cloud providers do, in acknowledgement of the fact that bandwidth isn't free. Yes, I recently migrated some of my company's infrastructure off of AWS, in part so we wouldn't have to pay for egress. I now believe the world would be better off if we didn't have that option.
If App sizes go down, its a win for Apple as well:
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.
Regarding PR, it adds ammo to their oft repeated claim of "best mobile OS" (Not that I fully agree)
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.
With the iPhone now ~silently deleting apps you don't use that often, and re-installing on demand I don't think this is as big a push as it used to be.
File size aside, I can confidently say - United hands down has the best app of any major airline in the world. It's better than their website and often-times even better than calling customer service on their 1K (top loyalty status) line. Many ways to make it better, but if we're comparing it to airlines & hotels, it's extremely well done.
Interesting, I've found Delta's app to be usable (above average?). Sort of funny that a usable app is my above average rating but I've found Delta's app just doesn't get in the way. I'm looking forward to trying United.
I've found that true of other everyday things (eg, booking a session my local gym), and find it incredibly depressing. Not only have we devised a world where impersonal, digital communication is the way things get done, but we must also buy a smartphone to even start accessing it.
I find it a great step forward in society, for every Gym in the world to not need to staff someone to sit there and answer phone call questions around (what are your hours? can I book X for Y?). Those are done much faster with robots and lower our costs.
Those are done much better with a web site (for many purposes, a static website with no Javascript is sufficient!) than by downloading a gigantic possibly-insecure app.
You don't need someone sitting next to the phone the entire time to perform that service. Besides, you've swapped that perceived unpleasantness for another - some poor soul in a 3rd-world coding sweatshop has to scrape together some bloated mess of an app so we can enjoy our "hassle-free" gym sessions, etc.
> It’s becoming somewhat of a popular trend in the airline industry to cut costs by having the passenger bring the hardware,
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.
> 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.
I usually fly Air Canada (AC), where these have been more common than the us carriers i've been on for a while. I use it _every time_.
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.
And here I am feeling unsatisfied about the ~20MB size of the app I’m responsible for. I haven’t seriously tried to cut its size down yet, but aspirationally I’d like to cut that in half.
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.
> While the United dev team should have noticed this much earlier
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"
>It’s becoming somewhat of a popular trend in the airline industry to cut costs by having the passenger bring the hardware, and as an added bonus they get to force their way into your coveted list of installed apps.
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.
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.
This is why I always prefer simple mobile web version over installing apps. There's no added value for the app that I cannot get from a simple browser.
I recently bought a 100$ android waiting for my phone to be repaired and the size of modern apps on older hardware render them completely unusable. It's a shame that the amount of bloat creeping into everything in the name of "developer productivity". Do we have to wait until we hit some limitation in storage size before we decide that it's simply dog shit software?
Samsungs "notes" application is almost 100mb in order for me to keep track of a few kb of grocery lists and restaurant suggestions.
It's 78MB on Android (Pixel 6 Pro). That's one of the hidden advantages of Android: much smaller apps. Makes for faster downloads, less storage consumption, and maybe even better caching / performance. It's common for iOS apps to be 4-5x bigger than Android apps.
I wonder what effect stripping has on crash dump reports though. I don’t know enough about how the App Store manages those, like (if a user opts in to “share information with the developer”), does the developer get less nice dumps as a result of stripping? Surely this can be worked around so long as someone has a symbol table (which they likely do), but the infrastructure might not be in place to do that automatically.
A good crash dump doesn't need symbols at all. The symbols come from the stored symbols from when the author originally compiled it. As long as the builds are reproducible you can even produce the symbols at a later date for an old version if you still have the source code.
Even if the builds aren't reproducible, rebuilding on the same machine with the same settings usually gives you something a crash dump will work with.
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.
Debug symbols are stored separately on the developer’s computer (and may be uploaded to Apple, but that’s optional). Including symbols in the App Store binary is practically useless.
No, Apple already modifies uploaded binaries before storing them for distribution. In some cases Apple even compiles the binaries themselves (if the developer chose to include the LLVM "bitcode" when submitting the app).
Until app stores start penalizing apps for their size, there is little incentive for developers to improve. And I guess the phone makers don't mind forcing people to buy new phones - although a shortage of space would also get people to stop buying more apps, so maybe that doesn't play into it as much as a desire to keep developers happy.
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 don't understand why this actually happened, why were the names not stripped? That seems like a terrible thing not just for size but also for insights into the developer's process (in this case). Shouldn't Xcode be doing this automatically? The author even points out that Swift doesn't need them, so why are they there?
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.
So does optimization and efficiency. Apple can add this in at some point and say they reduced App sizes by X% across the entire App Store at WWDC and get lots of oohs and aahs.
You joke, but really, if anyone can change the economics of development to dissuade app cruft, only Apple can. Apple routinely achieves with a wave of the hand things that years or decades of concerted effort from industry professionals couldn't do. Things like remove and deprecate DRM from music.
This is Apple's industry, we're just allowed to play in it.
Small app size is one of the KPIs that I track for the app I develop.
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.
Apple should have never allowed these "non-compiled" applications. An LTO like pass/etc would rip out tons of size too simply by removing all the unused code.
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.
I really thought that app size would be a hinderance because of the cellular download limits (at least because I only remember to download these apps while at the airport). So I had to look it up and it appears there isn't a size limit anymore from Apple as of 2019, just a popup asking you to allow a download over 200MB.
Maybe Apple wants you to use up all your space with fat Apps so you have to upgrade to a bigger iPhone. ;-)
(Tim, if you’re reading this, I’m just kidding. Please don’t delete my iCloud account.)
Ignoring the economy of the development process, vs. just being able to push out an app quickly, I cannot help wonder how small, and fast apps like this could be, without losing features.
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?).
App, OS and other file sizes are big deals in bandwidth-constrained environments. Canada has a number of remote communities with satellite uplinks, so every update means the whole town needs to download them independently.
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.
Out of interest having never been on an airline that forced you to install an app to get what is now a basic customer service, what happens if you don't have a phone that supports their app? Do you get a discount?
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.
In many cases yes, but svg support has been available in xcode since ver. 12 and before that pdf had been available. As a consultant I haven't worked on a project yet where vector assets has been chosen over bitmap
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.
Not that it excuses it, but having worked at a place that did contractual web design for airlines, I'd bet money that the app wasn't developed by any employees at United and instead was developed by the lowest bidding external company they could find.
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.
Apple could and should run this as part of their compression routine. They should also optimise images - it's very common for apps to bundle images that can be shrunk without any quality loss. ImageOptim is a decent tool to throw your images at: https://imageoptim.com/mac
It is possible to shave the remaining 252MB as well by using webassembly, a webview wrapper from a service like Red Goose, and an intrinsic css framework like Toucaan.
187MB of symbols seems like alot! Kind of funny that this bloat could be reduced by X% just by having a shorter path in the CI pipeline and not even stripping, also surprising that xcode doesn't strip swift symbols by default for a release build? Some low hanging fruit right there
Every time I see an article like this, it's another point of evidence that, no, large application sizes are not actually needed for performance/functionality/ease of development - they're just due to sloppy programming.
I wouldn't be surprised that the reason the Netflix app is so much smaller is because the app is Netflix's core business, and UA's app is an afterthought.
(If the Netflix app is too big to fit on the phone, Netflix loses a customer.)
I worked for someone who took an America Airlines contract 5+ years ago. He was working on encryption, and he was like the 3rd or 4th person they brought in to do the job because their codebase was total spaghetti and no one could figure it out.
I worked for someone who took an America Airlines contract years ago. He was working on encryption, and he was like the 3rd or 4th person they brought in to do the job because their codebase was total spaghetti and no one could figure it out.
so that is why they say before every single flight "Make sure you download the United app before takeoff as you will not be able to download it in the air".
When you build the app, you can set aside the symbols for a given version and, either manually or with tools that allow symbol upload, symbolicate things later for debug purposes.
- 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...