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.
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.
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.
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.
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.
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?
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!
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.
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’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.
> 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.
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?
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.
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.
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.
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?
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).
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.
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.
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.
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.
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.
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.
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...
> 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.
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.
>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?
> 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.
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?
> 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.
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 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.
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.
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.
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.
"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.
> 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.
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.
> 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?
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
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).
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.
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.
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"
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.
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.
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 just good practice, it's default with Xcode. Someone must have messed up some configuration/flags while they were breaking the frameworks up maybe?
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.
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.
> 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.
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.
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.
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".
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.
> 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"
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.
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).
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?
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.
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 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.
451 comments
[ 0.20 ms ] story [ 266 ms ] threadI'm a real "dependency skeptic." Doesn't make me too many friends, hereabouts.
I'm also not a fan of running Web code on the phone, like a lot of PWAs and hybrid systems. Again, doesn't make me popular, in this crowd.
If the main app runs afoul of stripping symbols, then the App Store inspection can flag it. If, however, it's a dependency, then I could see them tossing out boatloads of apps, simply because they include piggy frameworks. There's really no automated way for Apple to realize the framework is really just the developer's aggregated code, or from another source, over which the developer has no control.
What really needs to happen, is that the developer has their own inspection regimen, before submitting something that could cause brand damage, to the App Store.
Again, suggesting stuff like this, is tantamount to heresy, in today's "Move fast and break things" tech world.
This is Apple's industry, we're just allowed to play in it.
I really wonder what some of these apps are doing with this space. My banking app clocks in at 400 MB as well.
I'm not entirely convinced value-per-byte is a measure of software quality that a lot of users care about, but it undeniably trends down every year.
All of that happens online.
At least the airlines I've worked with prefer native code and UIs for any flow that's either revenue-producing, or likely to create issues on day-of-travel. They tend to use webviews only for things that don't have to be working to sell a ticket or board the aircraft.
I’m the first to say that this utter bloat is terrible, but most people aren’t really bothered by it. And I can only imagine that they outsourced their app development completely and like to keep costs low.
From that perspective, it’s probably much more pragmatic to fix the problem at the root(s): Apple may want to mandate stripped binaries (I think this is also what RPM does by default, just strip everything), and/or god forbid these Electron-type frameworks should make things more efficient.
For a 5-screen 50MB app, sure. For a 5-screen 500MB app that falls pretty flat.
[edit] You could fit all of Tony Hawk's Pro Skater 2 or Final Fantasy VII for PS2 in the same amount of space.
A candy bar which is 5% packaging and 95% candy by mass is alright. A candy bar which is 50% packaging and 50% candy is horrifying.
https://www.sugarfina.com/valentines-day-mini-candy-trunk
An emulator and Mario 64, Zelda OOT, ISS and 40 games more could be placed under a CD and yet you could fit a good bunch of MP3's in between.
The problem is that purchases would no longer be subject to Apple's 10x industry standard (30% instead of 3%) captive credit card payment processing service (for apps), so no web notifications in MobileSafari that might undermine platform control and payment processing monopoly. Apple, of course, will say this is about protecting users from notification spam, and sidestep the inconvenient facts that it protects an Apple cash cow and locks developers and users into a closed and proprietary platform.
Even apps without notifications are still apps, because they can take additional data from users, sometimes even location and the whole address book.
Look at sites like reddit for exmaple, which purpusefully cripple the mobile web experience to get the user to install the app.
In theory, this is true. In practice, it's just hit or miss. I think it's just hard to maintain web across all the different platform and screen sizes. It's probably due to the fact that an iOS developer specializes in one platform and most web development shops will have to support all platforms.
"If Apple would allow web notifications"
I do not use apps because of notifications. I use apps because in general, the performance and experience is much better.
For example, you can create "app" that is just a link to browser. There are plenty of action you don't want random web-apps to perform due to security/sandboxing issues, but if you can grant explicit permissions that issue goes away. It is one of the reasons think like election exist. But could apple/goog provide a better electron that was built into the OS?
Increase developer productivity at the expense of hardware.
In this case, engineering is more expensive than hardware (because hardware is at the cost of the user).
The smallest iPhone starts at 128 GB. This means the application takes 500/128000 blocks: 0.4% of the total device storage.
Over time, the iPhones are going to have more and more storage. So, if app size is a problem, and over time, the problem is fixed by itself, why would you invest engineering resources into that ?
You have X engineers with Y amount of working hours, and tons of important things to do. Yes, probably fixing a problem that brings a low amount of complains from end users at the cost of productivity isn't high on the list for them.
EDIT: Possibly interesting source: https://www.androidauthority.com/average-smartphone-storage-...
The smallest iPhone sold now is 128 GB. The iPhone 5C, sold in 2015, had 8 GB internal storage with no expansion options. 439 MiB is a full 5% of the total storage capacity of the iPhone 5C, completely ignoring the amount reserved for the OS that's completely unusable to the user.
The logic used here hurts lower-income people and contributes to climate change by encouraging poor use of device resources -> shorter device lifetimes -> more e-waste and wasted energy.
Edit: why the downvotes? You can get flights for 50 bucks to go to different countries in Europe.
The cheapest flight I can see on SouthWest.com is $60, for a 1 hour journey from Atlanta to South Carolina.
The cheapest flight with Ryanair from Copenhagen is $9, though it doesn't include checked luggage. It's also an hour.
An even cheaper one is Kraków to Eindhoven, 2 hours, $6. There are fewer dates for this price though.
They look very much in the style of Ryanair with the garish website. $22 for three hours (Boston-Miami) is priced between the two Ryanair flights, so I expect the "service" is similar.
I'm sure the average distance of a flight within Europe is lower than in the USA, since the USA is a bit empty in the middle and Europe has more water in the way, but routes like Scandinavia to the Mediterranean (Stockholm to Zagreb is 3½ hours and $14), or Britain to eastern Europe (London - Cluj, 3 hours $13) aren't far off, and the budget airlines also have flights to tourist destinations in Egypt, Israel, Jordan etc, which are as long as a US coast-to-coast flight.
While I enjoyed camping and seeing bits of the US that foreigners like me don’t normally see, it’s not entirely clear that the difference between that and flying makes flying the luxury.
Overall, choosing Amtrak or flying is perfectly reasonable in different situations. Amtrak could definitely be improved a lot though!
[1] For reference, I live near Miami (technically, I live in Boca Raton, but Miami is "close enough" at this scale). The company I work for is based in Seattle. I refuse to fly anymore for a variety of reasons.
[2] Riding in a private rail car really spoiled travel for me: http://boston.conman.org/2015/08/05.4 But way out of my pay grade.
(But maintaining the track to this quality would be even more expensive if there was as much freight on it as tracks in the USA carry.)
Not being an American I have no reason to even be a UA customer let alone install the app, and therefore I don’t know if they’ve achieved this or not.
Requirements are often above average in some dimensions and below average in others.
If we optimize for people who are wealthy, always in high bandwidth areas with new phones, etc etc soon we will have left most people behind.
Leaving people behind is the entire concept of selling luxury stuff though, so I still don't think that the companies will care much.
More than half of American smartphones in 2021 were iPhones. The iPhone is price-comparable to its Android contemporaries. The Android downmarket in the U.S. is a minority by a wide margin.
But 5c is most unloved device so not a good sample. It was released at the same time as 5s that introduced ARMv8 by A7. It was the worst time to release it with old chip.
I'd pick iPhone SE 16GB in 2017 that's still in support.
A significant fraction of that 32GB is taken by system crap, so a GB makes a difference.
I've often thought that they either need to cache the app locally on the plane itself or provide a special free passthrough on the in-flight wifi, but so far they haven't provided either. In any case, app size is crucially important for the key use case that many (most?) people use the United App.
It's not that simple, but it makes total sense to cache a 500MB app when they have a couple TB (?) of videos on the plan.
Maybe we as an industry should start doing the boring parts instead of jumping into shiny tasks that take 10x, 100x, 1000x the time it would take to solve the original issue...
Only this is almost never true.
If it's possible to do something unnecessarily complicated, someone will inevitably do it. Maintenance costs are often greater as complexity and bloat goes up.
Longer compile times and generally greater development cycle latency also tends to decrease developer productivity more than the small time differences might suggest.
A friend of mine told me their company is trying to downsize their flash storage in order to come back to the unit prices of before the shortages.
This is not a contrarian opinion. This is the default attitude in web, cloud hosted, and mobile app development.
>looks like a rational trade-off that the engineers have done
What are your back-of-the-envelope numbers? Or are you just shrugging and assuming that performance has zero impact on the development loop, so therefore no development effort should be expended on it?
It may depend on the app, but Uber noticed that the bigger the app, the fewer people install it, unsurprisingly.
I also had friends who wouldn't install Signal because they don't have any space left on the device, and they stick to Whatsapp/Messenger which they already have.
https://eng.uber.com/how-uber-deals-with-large-ios-app-size/
> App-download-size restriction means first-time users cannot download the app ... when they are not on Wi-Fi.
> We established a correlation between the Uber Rider app size and customer engagement — when the app size crosses the download size limit, and it leads to a 10% reduction in app installations, 12% reduction in sign-ups, and 20% reduction in first-time bookings, resulting in revenue loss.
> Over the past three years, the Uber Rider app’s size has often approached the App store’s over-the-air download limit, and staying below it is a clear priority.
You are assuming apps won't scale larger over time. The old addage about software expanding to consume all available resources comes to mind. I remember thinking I'd never be able to fill my first 1 GB hard drive with software. And now it takes half that for the simplest things. As the bytes get cheaper we ration them less.
This is not a case of "I have plenty of water so let the kids splash some in the playground to have fun", this is a case of "I have plenty of water so I will load 10000 liters in a truck and drive 1000 kilometers and back just to dump them in the desert for no fucking reason".
Seriously, 5 minutes? I spend more than that in the bathroom. How many 5-minutes is a "Scrum standup"? a "progress meeting" ? a <insert bullshit corporate activity here>? Do all of those things not waste the engineers' time?
I'm trying to imagine the world if every profession and craft tried to justify this disgustingly irresponsible mindset :
" - This combustion engine uses an inferior injection mechanism that wastes 40% more fuel compared to latest...
= Don't waste my time!!! I have more important things to worry about.
-.... It would take 5 minutes to fix
= Customers don't notice the fuel consumption anyway, so that means robbing them out of money with inferior engineering is okay. Now hurry up, we'll miss the daily 3-hours progress meeting. "
If only Donald Knuth knew what " Forget about the small efficiencies" would be used to justify.
The idea isn't that nobody ever tries, it's that the typical amount of trying is really bad.
While it would be nice if everything was optimized, it's really not comparable to a meal tasting good, since that's basically the main reason to have a meal in the first place. Most people don't care about bundle size, especially when it's tens of megabytes versus gigabytes.
> the typical amount of trying is really bad
Again, we really have no way of measuring just how bad it could be. IMO it feels like everything could be way, way worse.
This much space is a pretty big cost. It represents wasted dollars, or shuffling data, or not getting it downloaded in time, or not having room for the pictures you want, etc.
> Again, we really have no way of measuring just how bad it could be.
If five minutes did this much, and this is within a couple orders of magnitude of typical, then we can conclude that the typical effort is really bad.
How much worse it could be might be an interesting thought experiment, but doesn't affect the above conclusion.
It could probably get almost infinitely bad if there was zero cleanup effort. But that's the difference between 1/10 effort and 2/10 effort. If I'm demanding 6/10 effort for a professional product, the difference between 1/10 and 2/10 doesn't matter to me.
You can buy a brand new, unlocked iPhone 12 from Apple. It starts at 64GB for $729
https://www.apple.com/shop/buy-iphone/iphone-12
Taking the shortest path to achieve a goal often seems like the good idea, but it leads to bloat and inefficiency. It'd take longer to "do it right" so you never do it right.
But you ignore the fact that all that bloat actually costs you to maintain it. "Not fixing it" is always faster and will always be the shortest path to the next feature... but that next feature gets harder and harder to achieve as the bloat grows. The bloat makes the fastest thing slower and slower while the fastest thing is always ignoring the bloat.
When you appropriately choose when to fix, when to focus on efficiency, everything becomes faster.
The concept is slowing down to move faster.
There's avoiding premature optimization and then there's ignoring optimization forever except for extreme emergencies.
Other than that, there’s unlikely to be a reason.
From my experience being on a mobile development team for a competitor. Last time I checked like most major airlines their team is in house and I’d be in shock if that changed.
Or are they trade-offs?
Do these 'bad decisions' actually impact their business or are they manageable, allowing them to achieve their mission, focusing on other things that are more important?
I can think of how bad decisions could negatively impact their mission and focus:
- App is slow and buggy, pressuring users to choose a different service altogether
- A much larger support staff is required to handle customer issues
- Bugs are painful to address and require weeks or months to resolve
- Developers spend more time fixing bugs and less time working on features, resulting in delayed features and an increased team size to allow more parallel development
* Far too many hands in the pot: My rough calculation is at any given time, there are around 1000 contributors to this app, across various teams. This itself is not a problem, but leads to issues.
* Tech Debt Racks up Quick: Again because there are so many hands in the pot, tech debt racks up unbelievably quickly. And furthermore it's almost impossible to address because it cuts accross so many teams and orgs.
* The Solution? More Hands in the Pot!: With tech debt racking up quick and not being resolved, productivity grinds to a halt. App has constant errors, crashes, and things like hot reloading are just totally broken because of all the underlying issues. So what do you do when faced with this problem? More engineers! Rather than addressing the problems that face developers, they just throw more labor at the problem, compounding the previous issues.
* Code Duplication: With so many folks working on the project but not talking to one another, code duplication becomes a MAJOR issue. Say you have a "Button" component that needs to be modified. Well, modifying that component means going through 5+ teams to get approval. So to sidestep you create "Button2", and the next guys creates "Button3". The result is you pull up the fuzzy finder and search "Button", only to get 15 results with subtle differences.
This is just my experience. Currently this app is top 20 in healthcare on the Apple Appstore. The company also has a number of other apps and when I was leaving the company, there were talks to merge all the apps into the "main" app (good fucking luck).
That said, I don't think the difference between a 40MB app and a 400MB app is all that critical these days. Optimizing for development speed and user experience over an absolutely minimal download size is a reasonable choice.
It's tempting to think about the United app as something very simple:
- Search for flights
- Run through the booking flow for flights
- Look up existing bookings
- Change existing bookings
But this ignores a lot of scope that's actually critical for a company whose products are very complicated:
- ID verification for international travel
- Custom functionality for large institutional cu stomers (government, corporate)
- Functionality for ancillary services: in-air streaming entertainment, in-airport services like lounges and baggage checks, loyalty program, loyalty-tier-specific functionality like priority connections.
- ... etc.
In this case the lack of stripping symbols seems like a very easy win and definitely is an example of sloppiness, but the idea that the binary should definitively be < 100MB seems to ignore a lot of scope.
But please still make them available separately!
AA's comes to mind as possibly the worst airline app out there.
> pushing code into frameworks has been a best practice for a while
This would have really pissed me off if I had to download it over my cell plan. I have one phone with minimum apps on it which I use for day-to-day, and then another with all the scummy bloated apps on it, but the data plan on that phone is small and 500MB would be a huge chunk out of my monthly quota.
https://bjango.com/articles/svgassetcatalogs/
It's my understanding, as a designer, that it was auto-generating 2x and 3x PNGs as from your vector assets, and that's what actually got bundled in the final app—and that PNG compression was not good compared to what I could get by going through ImageOptim.
I would be quite happy to be wrong about that. It would save me a lot of time.
Not really, but it's also actively suppressed. If they can make as much money with a 439MB app as they can with a 10MB app, why would they waste any time or effort trying to save you a few minutes of download time? If anything, I expect this to get worse, as management is constantly pushing for adoption of frameworks that (in their imagination) speed up time-to-market.
I wonder how crazy it would be to cache the iOS app… like maybe they run a caching transparent proxy on the plane… or some crazy relationship with a CDN that treats each plane as an edge node.
I dunno, it would probably be pretty be way to expensive to set up something like that to be worthwhile.
https://support.apple.com/guide/mac-help/what-is-content-cac...
https://support.apple.com/en-us/HT204675
United really wants that download to be fast, so customers can get the app before getting on the plane. Otherwise you end up with a bunch of grumpy people your that your flight attendants have to deal with.
I've been on a few budget carrier flights that have skipped the headrest display for an airline app. They haven't had external Internet access, as it's just served over a local WiFi connection from an onboard server, so you must install the app before you take off.
If I'd perhaps been connecting from a different country with United flights, there's no way I'd download it over roaming data "Welcome to Jamaica ... data is €3.05/MB".
It costs consumer time waiting for a large app to download, and it wastes consumer money by burning up quota on metered connections. It costs the business because apps have a size limit, and hitting those limits means no more features until you can reduce that size.
Yes? Have you actually seen this space?
There are tons of shops that get this stuff outsourced to them.
They have executives who gleefully cackle at the idea of hiring the bottom of the barrel developers who wouldn't even know to strip symbols, and cackle at the idea of cracking whips at them so that even if they did know they wouldn't have the bandwidth to do it. All while charging hundreds of dollars per billable hour.
> Wow! I honestly wasn’t expecting that much of an improvement. We shaved 187MB off the app size in five minutes by stripping framework symbols.
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"
The video player does give me problems sometimes though
There was an HN thread about it, too, but I can’t find it.
I think that it's unreasonable to expect a Lambo (or even a Yugo) to accommodate a 300Kg man.
But no comments, and no votes, so it must have been another thread, thereabouts. It was quite some years ago.
https://drive.google.com/file/d/16lDaCfEjT7Z72EEDFBo5r3lTDCV...
I'm not sure what I just read though.
2015 (scale) - https://news.ycombinator.com/item?id=10271586 https://news.ycombinator.com/item?id=10066338
2018 (491MB) - https://news.ycombinator.com/item?id=17995954
2020 (Messenger) - https://news.ycombinator.com/item?id=22466462
2020 (SDK) - https://news.ycombinator.com/item?id=23790207
The original version was 18MB. The official Facebook-written version was nearly 300MB, with the bonus that it disabled the old app.
I wrote about it then: https://medium.com/hackernoon/how-not-to-transition-an-app-b...
You can strip the main executable but stripping frameworks is a VERY VERY bad idea.
439Mb? That's horrific.
If I was cynical, I'd say it's in Apple's interests to have bloaty apps, so they can sell more expensive phones with more storage and memory.
But that would be cynical.
It feels like a failure at every step in the tool chain if a binary comes out at that size.
But, make your builds reproducible and/or save your debug symbols as part of your release process, it will be something you wish you did otherwise when you're not quite sure if the stack trace you have is correct.
I would imagine this is basically an Electron for iOS and Android? If that is case I am not surprised at the file size.
Electron and web developers, take note.
Which one do you think Apple cares more about?
1. Faster update downloaded to devices compared to before & to Google/Android. That's a big PR win.
2. Most badly behaving apps have tons of unnecessary process & their binaries. Also storage is taken up by UI assets. If these are streamlined & reusable, the footprint goes down. That means less RAM can still do fine.
But it wouldn't move the sales needle. Nobody is going to switch from Android because they were waiting for smaller download sizes.
> less RAM can still do fine
That's bad for Apple because it discourages upgrading.
Size and RAM (and indirectly a modest battery life gain) will be a win for whoever uses, regardless of our personal views on this matter. When developers throw in big frameworks mindlessly, they assume best case use. Minimalist and efficient coding will actually win across the board whichever way you look.
As far as Apple devices go, they are getting support way longer than Android flagships. Apple is devious possibly in many ways, but they don't get to win by 'planned obsolescence'. Much rather the opposite: as new generations of devices come in with newer hardware, they don't have to crazily support a lot of firmware and instruction sets. Only the ones which satisfies the newer frameworks. If they did, they will turn out as another Intel (which famously supported a lot of opcodes all the way back to 386). Their fanbase has some (valid) strength based on a lot of older generation devices still getting OS upgrades which they might normally wouldn't have.