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’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.
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?
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.
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.
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
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.
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.
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).
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.
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.
> pushing code into frameworks has been a best practice for a while