Back in the days of ARPANET mailing lists, there used to be an "educational" mailing list called "please-remove-me", that was for people who asked an entire mailing list to remove them, instead of removing themselves, or sending email to the administrative "-request" address.

So when somebody asked an entire mailing list to remove them, somebody else would add them to the "please-remove-me" mailing list, and they would start getting hundreds of "please remove me" requests from other people, so they could discuss the topic of being removed from mailing lists with people with similar interests, without bothering people on mailing lists whose topics weren't about being removed from mailing lists.

It worked so well that it was a victim of its own success: Eventually the "please-remove-me" mailing list was so popular that it got too big and had to be shut down...

...Then there was Jordan Hubbard's infamous "rwall incident" in 1987:

http://everything2.com/title/Jordan+K.+Hubbard

Former Uber engineer/EM here: I worked on the Rider app.

The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city.

The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or just not relevant to the type if user - like business traveler use cases).

Uber builds and experiments with custom features all the time. An experimental screen built for London, UK would be part of the app. Multiply this by the 40-50 product teams building various features and experiments outside the core flows you are talking about (which core flows are slightly different per region as well).

I worked on payments, and this is what screens and components are in the Uber app:

- Credit cards (yes, this is only a a few screens)

- Apple Pay / Google Pay on respective platforms

- PayPal (SDK)

- Venmo (SDK)

- PayTM (15+ screens)

- Special screens for India credit cards and 2FA, EU credit cards and SCA, Brazil combo cards and custom logic

- Cash (several touch points)

- AMEX rewards and other credit card rewards (several screens)

- Uber credits & top-ups (several screens)

- UPI SDK (India)

- We used to have Campus Cards (10 screens), Airtel Money (5), Alipay (a few more), Google Wallet (a few) and I other payment methods I forget about. All with native screens. Still with me? This was just payments. The part where most people assume “oh, it’s just a credit card screen”. Or people in India assume “oh it’s just UPI and PayTM”. Or people in Mexico “oh, it’s just cash”. And so on.

Then you have other features that have their own business logic and similar depths behind the scenes when you need to make them work for 60 countries: - Airport pickup (lots of specific rules per region)

- Scheduled rides

- Commmuter card functionality

- Product types (there are SO many of these with special UI, from disabled vehicles, vans, mass transport in a few regions etc)

- Uber for Business (LOTS of touchpoints)

- On-trip experience business logic

- Pickup special cases

- Safety toolkit (have you seen it? Very neat features!)

- Receipts

- Custom fraud features for certain regions

- Customer support flows

- Regional business logic: growth features for the like of India, Brazil and other regions.

- Uber Eats touchpoints

- Uber Family

- Jump / Lime integrations (you can get bikes / scooters through the app)

- Transit functionality (seen it?)

- A bunch of others I won’t know about.

Much of the app “bloat” has to do with how business logic and screens need to be bundled in the binary, even if they are for another region. E.g. the UPI and PayTM SDKs were part of the app, despite only being used for India. Uber Transit was in a city or two when it launched, but it also shipped worldwide.

And then you have the binary size bloat with Swift that OP takes about.