The Uber app takes up over 300 MB of storage, which seems excessive for what appears to be a simple interface, but the size reflects enormous behind-the-scenes complexity across dozens of payment methods, regional variations, business lines, and shared infrastructure — the speaker, a former Uber mobile engineer and manager who worked on payments for over four years, walks through the real reasons the binary is so large.
Payments alone account for 10–15% of the app size
Payments is only a fraction of the overall app, but it required around 20 engineers and involves far more complexity than the simple wallet screen suggests.
Every payment method has its own integration, validation logic, SDKs, and regional variations, and many of these SDKs are bundled into the binary globally even if a user never accesses that feature.
Major payment integrations and their complexity
Credit cards (large complexity): Client-side and server-side validation must handle different card types worldwide (e.g., American Express has different digit counts), BIN number checks, and varying formats — not trivial logic.
Cash (large complexity): Supported across many markets with multiple touchpoints in both the rider and driver apps; has safety implications in countries like Mexico and Brazil that require special handling.
PayPal (medium complexity): Integrated via an SDK that adds to the bundle size; must work across 60+ countries with millions of users.
Paytm (large complexity): One of the biggest payment methods in India; required an SDK and at least 10 native screens including a top-up flow — the speaker recalls it being nearly as complex as credit cards.
Apple Pay / Android Pay (medium complexity): Well-documented but has platform-specific quirks.
Credit cards in India (extra-large complexity): Require second-factor authentication that varies by bank — can be a text message or an online interface — and involved significant debugging and maintenance work.
UPI — Unified Payments Interface (large complexity): Very popular in India; required an SDK bundled into all parts of the app globally, meaning even users in the US or Europe carry that code.
Venmo (medium complexity, potentially large): Integrated via SDK with staged rollouts and backend credits logic that the mobile side must understand.
Brazil combo card (large complexity): A special credit/debit card type in Brazil where, after card entry, the app detects the bank via BIN and prompts the user to select credit or debit; support had to be added per bank, and the BIN list is pushed from the backend and parsed on mobile.
Amex rewards and Mastercard programs (large complexity): Additional screens for rewards balance tracking and program-specific logic on top of standard credit card flows.
Uber Credits (large complexity): Used for appeasements, disputes, and cash-change situations; involves significant business logic and regional variation on both backend and mobile.
Beyond payments: many other complex features add to the size
Airport pickup: Every airport has a different layout, requiring client-side navigation logic and flows before the backend even sends data.
Scheduled rides: Not a simple date picker — involves different UI elements across the app and complex payment integration.
Commuter benefits (US): Business benefit cards with rules about when they can and cannot be used, requiring client-side preliminary checks.
Product type selector: The list of ride and transit options keeps growing, each with special characteristics and client-side configuration.
Uber for Business: A major feature set including corporate credit card management, expensing tool integration, and receipt handling — much of it lives on the client.
Uber for Family: Adding and managing family members with associated flows.
Safety toolkit: Regionally variable — more advanced in parts of the US than in parts of Asia — with client-side integration for emergency numbers that must work offline, meaning data is pre-loaded onto the app for all regions.
Fraud detection touchpoints: Most users never see these, but the app can detect suspicious activity and require photo verification of cards, IDs, or selfies — this code ships worldwide in the binary.
Receipts: Especially important for business users; client-side logic varies by country.
Customer support: In-app messaging between riders and support requires dedicated code.
Lime/Jump bike and scooter integration: Jump is discontinued, but Lime scooter and bike availability still appears in the app in supported areas, requiring client-side code.
Uber Transit: A newer line of business in some cities showing public transit routing from A to B, with client-side logic to support it.
Uber Eats integration: The app is becoming a super-app; Eats ordering is built in with its own substantial codebase.
Shared infrastructure also contributes significantly
Ribs architecture: The architectural framework everything is built on, shared across all teams.
Networking library: Shared code handling offline scenarios and reporting.
Analytics framework: Used by all components to send events back to the backend.
Performance monitoring: Dedicated tooling so engineers can see which parts of app are slow on which devices; Uber has a dedicated team for this.
Experiments framework: Thousands of experiments (the speaker saw around 3,000, some active, some dead) that control which features and UI variants users see — all configurable from the backend but requiring client-side support.
Mobile platform team: A dedicated team of at least 10+ people focused on keeping the app size as small as possible.
Why the size is hard to reduce without tradeoffs
Some size could be reduced by moving logic to the backend, but that would degrade user experience — the app needs to work offline in places like airport pickups and safety features.
The app looks deceptively simple; most engineers underestimate the edge cases across different cities, countries, languages, and regulatory environments.
The driver app is even more complex than the rider app — for example, driver onboarding differs by US state, not to mention every country.
Uber runs multiple apps and multiple lines of business, with a lot of functionality hidden behind the scenes.
The speaker initially didn’t understand why 10+ engineers were needed on payments alone, but once onboard, the team couldn’t keep up with demand and had to defer functionality due to lack of people.
