Live data from Hacker News

I shaved 187MB off United Airlines' 439MB iOS app

telkins.dev

431–440 of 452 posts

Re: I shaved 187MB off United Airlines' 439MB iOS app

#431

Earlier quoted context omitted.

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 b…

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.

The caching on works on the download, you still need a connection for verification. So it wouldn't work.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#432
post #304

Earlier quoted context omitted.

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.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#433

Earlier quoted context omitted.

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.

Apple content caching is built into MacOS. A Mac mini connected to the in-plane wifi would likely do the trick. https://support.apple.com/guide/mac-help/what-is-content-cac... https://support.apple.com/en-us/HT204675

You still need an initial internet connection before the caching though.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#434
post #65

You know what also have huge app sizes, it's various iOS email app. Fastmail is the only email/calendar app with a reasonable size (just 20MB) [0]. - 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/…

> Fastmail is the only email/calendar app with a reasonable size (just 20MB) It's because it doesn't contain anything. You can't even see any UI, let alone emails without being connected to the internet.

Thunderbird for desktop is ~50mb though. There is plenty of space to include UI.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#435
post #248

Earlier quoted context omitted.

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.

Is there any reason Apple couldn't just strip the code binaries themselves?

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

Re: I shaved 187MB off United Airlines' 439MB iOS app

#436

Earlier quoted context omitted.

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.

200KLOC for IRC client? Where does the majority of code come from?

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

Further breakdown of the UI part:

· ~7kLOC XML layouts

· ~7kLOC included default settings

· ~7kLOC Chat UI Code

· ~5kLOC Settings UI Code

· ~3kLOC Setup and initial configuration wizard

· ~10kLOC background processes, notifications, protocol handlers, etc

Re: I shaved 187MB off United Airlines' 439MB iOS app

#437
post #5

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 t…

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.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#438
post #128

Earlier quoted context omitted.

It's ridiculous. The complete size of Mario 64 with all assets is 6MB.

And the whole 9front weights less than those apps. When I was a Windows user, a video player install of more than 80MB would be slightly bloated. Today my OpenBSD install uses less than 3GB and it has far more stuff than a phone install. Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.

> Golang binaries are like 5-15x the size of a dinamically linked C binary, yes, but at least they provide everything and run everywhere.

I once ported a shoddily written (by me) Python script to Go. About 400 LOC in Go. The compiled executable size was a whopping 7 mb!

This was more than I expected.

It turns out there's a reason for large executable sizes in Go [1], and apparently it can be made smaller.

[1] https://go.dev/doc/faq#Why_is_my_trivial_program_such_a_larg...

Re: I shaved 187MB off United Airlines' 439MB iOS app

#439

Earlier quoted context omitted.

Also the only way to order adult beverages

Wait you can't order alcohol without their beast of an app? I haven't flown anythign but SW in a while (rewards card)

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.

Re: I shaved 187MB off United Airlines' 439MB iOS app

#440

Earlier quoted context omitted.

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 sto…

You don't need to introduce any problems. Splitting a package and deduplicating the downloads doesn't imply mixing versions.

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 :)

Post reply on HN