Most well known mobile architectures start to work against you after your engineering team grows large. A new architecture paradigm is needed to better support the development of mobile applications with hundreds of mobile enginee

1. Mobile Architecture
at Scale
Why and how we built a new
architecture used by hundreds of
engineers, all in one codebase
18 Jan 2018
Gergely Orosz, Engineering Manager,
Payments, Uber

2. Engineering at Uber

3. Payments Experience
• Rider
• Driver
• Cash
• Platforms
Developer Experience
• Mobile
• Backend
Amsterdam HQ
• ~100 tech (dev,
design, DS, PM, UX)
• ~700 total
Engineering @ Uber
Amsterdam

4. Payments Experience
• Rider
• Driver
• Cash
• Platforms
Developer Experience
• Mobile
• Backend
Engineering @ Uber
Amsterdam

5. Motivation Architecture Scaling an
architecture in
practice

6. Motivation Architecture Scaling an
architecture in
practice

7. ● History
● Architecture growth
● Goals of the rewrite
Motivation

8. Initial Team

9. Team Growth

10. Over 100 mobile engineers?
Request a ride
Fare split
Cash
Uber for Business
Credit card rewards points
Promotions
Promotions
Safety
Over 10 ways to pay
Scheduled
rides
Drive for Uber
Uber Eats, Freight,
Self-driving vehicles...
Experimentation
80 countries,
600 cities
Performance
Cash
Instant payments
Maps & navigation
uberPOOL
Driver incentives
App health
Developer tools
Networking
Feed cards
Driver experience
Driver recognition
Airport pickup
Uber Family
Beacon
Campaigns
Fraud EATS app
Courier experience
Shipper experience
Restaurant experience

11. App Growth

12. App Growth

13. App Growth

14. Let’s just change everything

15. 1. History
2. Architecture growth
3. Goals of the rewrite
Motivation

16. Architecture Growth
LoggedIn
Activity
ProductSelection
Controller
Menu
Controller
Location
Controller
Custom
View
Custom
View
Sub
Controller

17. Architecture Growth: State

18. Architecture Growth: State
LoggedInState
LoggedIn
Activity
ProductSelection
Controller
Menu
Controller
Location
Controller
Custom
View
Custom
View
Sub
Controller

19. Architecture Growth: State
... ...
LoggedInState
LoggedIn
Activity
ProductSelection
Controller
Menu
Controller
Location
Controller
Custom
View
Custom
View
Sub
Controller
LoggedIn
Activity

20. Architecture Growth: State
... ...
LoggedInState
LoggedIn
Activity
ProductSelection
Controller
Menu
Controller
Location
Controller
Custom
View
Custom
View
Sub
Controller
LoggedIn
Activity
LoggedIn
Activity

21. ● Number of engineers
● Understanding how the app works
● Shared state
● Modifying the app
Our Biggest Problems

22. Shared State
class DriverIsOnTheirWayToaster {
var isOnTripAndHasNotBeenNotified:Boolean = false
fun onCreate(stateStream: TripStateStream) {
stateStream
.state()
.subscribe({ (trip, driver) ->
if (trip == TripState.ON_THEIR_WAY) {
isOnTripAndHasNotBeenNotified = true
showToast(driver!!.name)
} else if (trip == TripState.ON_TRIP) {
isOnTripAndHasNotBeenNotified = false
}
})
}
}

23. class DriverIsOnTheirWayToaster {
var isOnTripAndHasNotBeenNotified:Boolean = false
fun onCreate(stateStream: TripStateStream) {
stateStream
.state()
.subscribe({ (trip, driver) ->
if (trip == TripState.ON_THEIR_WAY) {
isOnTripAndHasNotBeenNotified = true
showToast(driver!!.name)
} else if (trip == TripState.ON_TRIP) {
isOnTripAndHasNotBeenNotified = false
}
})
}
}

24. class DriverIsOnTheirWayToaster {
fun onCreate(driver: Driver) {
showToast(driver.name)
}
}

25. Modifying the App
... ...
LoggedInState
LoggedIn
Activity
ProductSelection
Controller
Menu
Controller
Location
Controller
Custom
View
Custom
View
Sub
Controller
LoggedIn
Activity
...
LoggedIn
Activity
......
ProductSelection
Controller
Location
Controller
Menu
Controller

26. 1. History
2. Architecture growth
3. Goals of the rewrite
Motivation

27. ● Constraints
○ Native development
○ Independent iOS & Android™ codebases
● Opportunities
○ Mobile Platform team
○ iOS & Android monorepos
Constraints & Opportunities

28. ● Isolation & testability
● Developer productivity
● Support continued growth for years
● 99.99% reliability of core flows
● Monitoring as a first class citizen
● De-risk experimentation
Rewrite Goals

29. Rewrite Goals
Image by Tsahi Levent-Levi
Android is a trademark of Google LLC.

30. Rewriting the Uber App
January June August November
Core architecture, framework & tooling
Core flow
Everything else

31. RIBs Architecture
What We Built
Application Framework
Scoping
Routing
Business-logic driven
Dependency management
Open source
Monitoring
Components
Code generation
Reactive data flows
Testability
Experimentation
Plugins
Networking
Storage
Location services
Analytics
Logging
UI components

32. Motivation Architecture Scaling an
architecture in
practice

33. ● Application state
● Dependency scopes
● Designing of RIBs
Architecture

34. The state management problem

35. State Tree
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

36. State transitions
RIBs
Root
LoggedOut
Backend
LoggedIn
Login request
Session response
LoggedOut

37. State Tree
State tree drives the views
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

38. Request
Home
LoggedOut
State Tree
State tree drives the views
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

39. ● Application state
● Dependency scopes
● Designing of RIBs
Architecture

40. Dependency Scopes
Application driven by business logic
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...
LoggedOut

41. Dependency Scopes
Application driven by business logic
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

42. Dependency Scopes
Application driven by business logic
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

43. ● Application state
● Dependency scopes
● Designing RIBs
Architecture

44. ● MVC, MVP, MVI, MVVM
● VIPER, (B)VIPER
Popular Mobile Architectures

45. MV*
Model
Controller
View
Model
Presenter
View
Model
ViewModel
View
Model
Intent
View
Input
Input
Input
Input
MVC
MVI
MVP
MVVM

46. VIPER
Interactor
Business logic
Router
Route between screens
View(Controller)
Layout & animation
Presenter
UI logic & respond to
user inputs
Entity

47. ● View tree drives the app hierarchy
● Business logic & view trees are tightly coupled
● Deep scope hierarchies supported only based
on view nesting
MVC, MVP, MVVM, MVI & VIPER

48. (B)VIPER
Making VIPER components reusable
Interactor
Business logic
Router
Route between screens
View(Controller)
Layout & animation
Presenter
UI logic & respond to
user inputs
EntityModule Builder
Creates VIPER classes

49. RIBs
Interactor
Business logic of the app
(aka “the brain”)
Router
Routes between RIBs
View(Controller)
Layout & Animation
Presenter
(Optional)
Translation Logic
View model
UI event
Data model
Business logic calls
Routing calls
Builder
Creates RIB units

50. Router Interactor Builder
RIBs
Presenter View

51. Request
Home
LoggedOut
State Tree
State tree drives the views
Root
LoggedInLoggedOut
Onboarding Menu Request
Home
ShortcutsFeedCard
Location
Editor
OnTrip
...

52. Demo

54. Data flow with RIBs

55. RIBs
Interactor
Router
View(Controller
)
Presenter
(Optional)
Builder
Interactor
Router View(Controller)Presenter
EntityModule Builder
RIBs
(B)VIPER

56. Data flow with RIBs
ServiceModel Stream Pushes state onto
Service callsData model
Non-state modifying
responses
Logic calls
The Internets
Interactor
Router
View(Controller)Presenter
UI event
View model
Push/pull
Data model
Routing calls

57. Viewless RIBs

58. Viewless RIBs
ServiceModel Stream Pushes state onto
Service callsData model
Non-state modifying
responses
Logic calls
The Internets
Interactor
Router
View(Controller)Presenter
UI event
View model
Push/pull
Data model
Routing calls
Attach / detach child RIBs

59. Demo

60. Viewless RIBs - demo

61. Motivation Architecture Scaling an
architecture in
practice

62. ● Adopting a framework with
a large team
● Why RIBs worked
● Summary
Scaling an architecture in practice

63. Adopting a framework with a large team

64. ● Code generation
● Onboarding
● Enforcing (architecture)
patterns
Adopting a framework with a large team

65. Rails for architecture & code
Code Generation
Android (IntelliJ, Android Studio) iOS (XCode)
Open sourced

66. Onboarding
● How long does it
really take to learn?
● Documentation
● Tutorials
● Encourage
contribution
Open sourced

67. ● Lint rules
Enforcing (architecture) patterns
● (Blocking) code
reviews

69. Enforcing (architecture) patterns
● Process for change suggestions (RFC)
● Lint rules
● (Blocking) code
reviews

70. ● Code generation
● Onboarding
● Enforcing (architecture)
patterns
Adopting a framework with a large team
● Have a clear owner

71. ● Adopting a framework at scale
● Why RIBs worked
● Summary
Scaling an architecture in practice

72. ● 3 apps, more than 200 developers
● More than 600 RIBs, reused within & across apps
● Less than 300 lines of code / class for most RIBs
● All business logic well unit tested
● Open sourced
How RIBs worked out

73. ● Long dependency injection chains
● Too much (boilerplate) code
● [iOS] RIBs incompatible with plain Views
Feedback from engineers after a year’s usage

74. ● Does your app have lots of non-visual state?
● Do you have a (fast) growing iOS & Android app/team?
● Do you have the bandwidth to invest in a new architecture?
Is RIBs for you?

75. ● Adopting a framework at scale
● Why RIBs worked
● Summary
RIBs in practice

76. Motivation Architecture Scaling an
architecture in
practice

77. Gergely Orosz
Engineering Manager, Uber Amsterdam
@GergelyOrosz
eng.uber.com
Thank you
uber.github.io

78. Proprietary and confidential © 2017 Uber Technologies, Inc. All rights reserved. No part of this
document may be reproduced or utilized in any form or by any means, electronic or mechanical,
including photocopying, recording, or by any information storage or retrieval systems, without
permission in writing from Uber. This document is intended only for the use of the individual or entity
to whom it is addressed and contains information that is privileged, confidential or otherwise exempt
from disclosure under applicable law. All recipients of this document are notified that the information
contained herein includes proprietary and confidential information of Uber, and recipient may not
make use of, disseminate, or in any way disclose this document or any of the enclosed information
to any person other than employees of addressee to the extent necessary for consultations with
authorized personnel of Uber.