Live data from Hacker News

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

telkins.dev

391–400 of 452 posts

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

#391

Earlier quoted context omitted.

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

Yeah those images need to go, I found them earlier when using assetutil ;)

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

#392

Earlier quoted context omitted.

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…

That article was a wild ride, thanks for writing it.

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

#393
post #384

Earlier quoted context omitted.

OP showed up five minutes late, not fifteen minutes early.

op was more than fifteen minutes early to the departure time. boarding time is irrelevant to the clause in the coc.

Oh! I should read more carefully.

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

#394

Earlier quoted context omitted.

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

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.

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

#395

Earlier quoted context omitted.

That would mean they did the 3 minute cleanup and then declared their work done. That's not a sufficient amount of trying.

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

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

#396

Earlier quoted context omitted.

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

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.

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.

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

#397
post #51

Earlier quoted context omitted.

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…

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

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.

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

#398

Earlier quoted context omitted.

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

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

#399

Earlier quoted context omitted.

I can imagine that in case of app crashes, having debug symbols makes debugging them much easier. Other than that, there’s unlikely to be a reason.

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.

Symbols are good to ship so that your users can see what is going on as well, FWIW. They just shouldn’t be 200 MB…

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

#400

Earlier quoted context omitted.

One could argue that maybe the developers of the app were optimizing for the right things. Usability, performance, etc., as opposed to disk space.

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.

> Stripping symbols of shipped binaries is standard good practice.

But please still make them available separately!

Post reply on HN