101–110 of 452 posts
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.
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/…
Earlier quoted context omitted.
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.
You're thinking like an engineer, not a manager. How does this factor into this year's bonus?
Conversely, it may be that only bloated tech will survive, as bloat drives sales, and sales means survival.
Earlier quoted context omitted.
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…
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…
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.
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 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…
It's not that simple, but it makes total sense to cache a 500MB app when they have a couple TB (?) of videos on the plan.
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/…
[0] Fastmail: smallest of the apps but still could have room for improvement, could save almost 20% of the app size by optimizing their audio files. 71% of the app is the binary. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[1] Gmail: looks like most of their bloat is coming from localizations. Only 60% of the app is binary, while 24% is localization files. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[2] Outlook: could be stripping binary symbols to save significant space. 65% of the app is binary, while 14% is localizations. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[3] Hey: could save about 15% of the size of the app just by removing duplicates and optimizing their images. 45% of the app is binary, 27% of the app is assets, this is definitely higher than it should be. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
[4] Protonmail: could save almost 30% just from image optimization and duplicate removal. 58% of the app is binary, 14% is assets, and 7% is localizations. Check out the X-ray here: https://emergeassets.s3.us-west-1.amazonaws.com/Screen+Shot+...
Unfortunately this is a very common problem as many teams don't have any monitoring in place. Here's another example of a popular email app Spark, automated insights show over 100 MB of easy savings: https://www.emergetools.com/app/example/spark?buildContent=i...
For pretty much every app here, Emerge's insights found at least 20% in easy size reduction. FYI, in the X-ray visualizations, red indicates duplicates and we can breakdown apps even further using builds with dSYMS!
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 automaticall…
I got the job.
