Mobile System Design Book Bundle

1.3 Common challenges for mobile engineers

1.3.1 Rapidly changing environment

1.7 What this book is not

1.7.1 This book is not a traditional programming book

1.11 How this book works

1.11.1 A strong focus on building the right things

1.12 The chapters

1.12.1 Chapter 1: About This Book

1.12.2 Chapter 2: Turning a Briefing Into a Strong Plan

1.12.3 Chapter 3: Holistic-Driven Development; Turning a Plan Into Code

1.12.4 Chapter 4: Holistic-Driven Development: Strategic Decisions and Integration

1.12.5 Chapter 5: System-Wide Testing; Delivering Higher Quality Apps

1.12.6 Chapter 6: Cross-Domain Testing; Testing More With Less Effort

1.12.7 Chapter 7: Dependency Injection Foundations

1.12.8 Chapter 8: Sane Dependency Injection Without Fancy Frameworks

1.12.9 Chapter 9: Dependency Injection on a Larger Scale

1.12.10 Chapter 10: UI Frameworks, Architectures, and Supporting Multiple Products

1.12.11 Chapter 11: Delivering Reusable Views; The Art of Decomposing a Design

1.12.12 Chapter 12: Reasoning About Views, Components, Screens, and Bindings

1.12.13 Chapter 13: Pragmatically Implementing UI

1.12.14 Chapter 14: Delivering Self-Sufficient Features, Part I: The Art of Staying Nimble

1.12.15 Chapter 15: Delivering Self-Sufficient Features, Part II; Self-Loading Features

1.12.16 Chapter 16: Delivering Self-Sufficient Features, Part III; Making Features Portable

1.12.17 Chapter 17: Taming Complex UI

1.12.18 Chapter 18: Reusing Views Across Flows

1.12.19 Chapter 19: Crafting Robust and Reusable Navigation Flows

1.12.20 Chapter 20: Design System or Not; How a UI Library Lays the Groundwork

1.12.21 Chapter 21: UI Library Fundamentals, Part I: Typography and Colors

1.12.22 Chapter 22: UI Library Fundamentals, Part II: Icons, Spacing, and Shadows

1.12.23 Chapter 23: Migrating from Legacy UI to Semantic UI

1.12.24 Chapter 24: From Semantic UI to Design System

1.12.25 Chapter 25: Design Systems at Scale: Token Workflows Across Platforms and Teams

1.12.26 Chapter 26: Deciding When, What, and How to Modularize

1.12.27 Chapter 27: Module Design and Refinement

1.12.28 Chapter 28: Module Categories and System Structure

1.12.29 Chapter 29: Modular Architecture in Practice

2.1 The briefing

2.1.1 An initial impression

2.2 Evaluating common approaches

2.2.1 Start with UI?

2.2.2 A data-focused approach?

2.2.3 Creating an app-skeleton or flow-skeleton?

2.2.4 Starting by making components or features?

2.2.5 Drawing a diagram?

2.2.6 Decide on an architecture?

2.2.7 A recommended approach

2.3 Sketching out a landscape

2.3.1 Everything is connected to a course

2.3.2 How far do we decompose?

2.5 Working with Designers; Getting secondary features

2.5.1 Whether a design is "the law"

2.5.2 What is “pixel perfect”, really?

2.5.3 Designs often encompass best-case scenarios

2.5.4 Not everything has equal priority

2.5.5 Verify the existence of pre-existing components

2.5.6 Ask general UI questions

2.5.7 Ask functionality-related questions

2.5.8 Talk about error handling

2.5.9 Talk about time-investments and start thinking in a less binary fashion

2.5.10 Giving feedback to the designer

2.5.11 Updating the landscape

2.5.12 A fast app is key

2.5.13 Scheduler

2.5.14 Deep Linking

2.6 Aligning with backend engineers

2.6.1 Align on user sessions, environments, tokens, and timeouts

2.6.2 Align on consolidating network calls

2.6.3 Be on the same page with errors

2.6.4 It’s okay to deviate from backend custom error codes

2.6.5 You might be the backend guinea-pig

2.6.6 Read code from other client implementations

2.6.7 Consider push notifications

2.6.8 Feature-specific questions

2.6.9 Updating the landscape with backend requirements

3.3 What to prioritize

3.3.1 We are deferring UI

3.3.2 The `CourseUI' domain doesn't care about `Course' internals

3.4 Implementing the Course domain

3.4.1 Retrieving a course

3.4.2 The `Course' data model

3.4.3 Using placeholders

3.4.4 The `Tutor' data model

3.4.5 Solving a modeling problem

3.4.6 Modeling `TodoItem'

3.4.7 Creating `TodoItem'

3.4.8 Modeling a course's schedule

3.4.9 Modeling `CalendarEvent'

3.4.10 Deferring `==' lazy?

3.6 Designing a `Store' Component

3.6.1 Starting from the call-site again

3.6.2 The `Store' implementation

3.6.3 Designing the `get()' method signature

3.6.4 Implementing the `get()' method

3.6.5 `Store' is implemented naively on purpose

3.6.6 Placeholder implementations lower priorities

3.8 The end result

3.8.1 Testing our implementation

4.1 Focusing on UI versus other implementations

4.1.1 Focusing on UI

4.1.2 Going deeper

4.1.3 Prioritize backend integration

4.2 Working downwards

4.2.1 Finishing `CourseService'

4.2.2 Defining new types

4.2.3 Continuing the process

4.2.4 End result

4.2.5 The backend should also use placeholders

4.4 Reflecting on Holistic-Driven Development

4.4.1 Holistic-Driven Development brings confidence to move forward

4.4.2 Lightweight restructuring

4.4.3 Context switching and delegation

4.4.4 Top-down versus bottom-up

4.4.5 We delay writing tests

4.4.6 Why we don't design with interfaces instead

5.2 Damage control and damage prevention

5.2.1 Damage control

5.3 Mocking higher in the stack

5.3.1 Defining the dependency hierarchy

5.3.2 Isolating `VideoClient'

5.3.3 Introducing mocks

5.3.4 Setting up a testing environment

5.3.5 Downsides of mocking higher in the stack

5.4 Mocking lower in the stack

5.4.1 Finding the smallest surface to mock out

5.4.2 Setting up the NetworkClient dependency

5.4.3 Setting up `VideoClient' for testing

5.4.4 Trade-offs

5.5 Mocking expensive operations

5.5.1 Accepting a closure as a dependency

5.5.2 The result

5.6 Making system-wide testing smoother

5.6.1 Dealing with boilerplate

5.6.2 Reducing boilerplate in production code

5.6.3 Reducing boilerplate in tests

5.6.4 Dealing with slower-running tests

5.6.5 Consider using file systems in your tests

5.6.6 Dealing with untestable code

5.6.7 Distance between tests and code

6.7 Domains in a larger app

6.7.1 When we are working in the "highest" domain

6.7.2 Domains are only responsible for their own functionality

7.1 Vanilla code versus third-party frameworks

7.1.1 The cost of third-party solutions

7.3 Testing and mocking

7.3.1 Dependency injection, testing, and interfaces

7.3.2 The purpose of an interface isn't instantly clear

7.5 Singletons, or "What if there's only one instance of something?"

7.5.1 Setting up a singleton

7.5.2 Singletons are often abused as shortcuts

7.5.3 Solving problems for the future

7.5.4 Singletons hinder modularization

7.5.5 Passing values across modules instead

7.5.6 Singletons, thread safety, and global state

7.5.7 A thread-safe singleton is not enough

7.5.8 Removing a singleton dependency

7.5.9 Use cases for singletons

7.5.10 Passing values pays off

8.3 Flipping the hierarchy inside out

8.3.1 Setting up the hierarchy in code

8.3.2 Updating `CourseService'

8.6 The secret sauce

8.6.1 Breaking the ABC rule

8.7 Growing the app

8.7.1 Extending the graph with more classes

8.7.2 Flipping the graph

8.7.3 A larger ABC problem in code

8.8 When dependencies aren't available

8.8.1 A payment flow

8.8.2 Optional dependencies

8.9 Lazy dependencies

8.9.1 Expressing a factory in code

8.9.2 Using the factory

9.2 Breaking up larger trees

9.2.1 Settings becomes a dependency hub

9.2.2 Why this approach works

9.2.3 The complete picture

9.2.4 When to create setup boundaries

9.3 Dependencies across an entire app

9.3.1 Lazy instantiation through hubs

9.4 Downsides of our approach

9.4.1 More verbose than shortcuts

9.4.2 Setup method discovery

9.5 Passing dependencies across a modular app

9.5.1 A modular app

9.5.2 A spider in the web

9.6 Reducing tight coupling between modules

9.6.1 Expressing a solution in code

9.6.2 The ABC problem appears again

9.6.3 Solving the ABC problem across module bounds

9.6.4 A cleaner graph

9.8 Conclusion

9.8.1 Trade-offs

10.2 UI Principle 2: UI architectures come and go

10.2.1 Consider UI architectures as alignment tools

10.2.2 There is no "perfect" UI architecture

10.2.3 UI Architectures and trends

10.2.4 Architectures can be formed over time

10.3 UI Principle 3: Imagine your feature as a command-line tool

10.3.1 A feature on the command line

10.3.2 Flexibility by disconnecting the business logic

10.3.3 Fat business domain, lean UI domain

10.4 UI Principle 4: The UI does /not/ dictate architectures in business domains

10.4.1 Bridging to React Native

10.4.2 Supporting SwiftUI

10.4.3 An alternative approach

11.1 UI Principle 5: Name a view after what it /is/, not how you use it

11.1.1 Making a reusable view

11.1.2 Type name versus instance name

11.1.3 Expressing reusable views in code

11.1.4 View primitives

11.1.5 The road of becoming too specific

11.2 Introducing abstractions without introducing new types

11.2.1 Abstractions via aliasing

11.2.2 Making an extension

11.4 UI Principle 6: Don't name a view after its styling

11.4.1 Alternative names

11.5 UI Principle 7: Favor composition over smart views

11.5.1 Breaking apart the view

11.5.2 Decomposing the todo list

11.5.3 Domain naming versus view naming

11.5.4 Handling inconsistent UI

11.5.5 Breaking a view down into smaller views

11.5.6 Avoid delivering for hypothetical scenarios

11.5.7 Button views

11.6 The end result

11.6.1 The views we defined

12.1 UI Principle 8: View components contain logic and/or bindings

12.1.1 Distinguishing view primitives from view components

12.4 Deciding when to make reusable components

12.4.1 A heuristic for making reusable components

12.8 Bindings can come in many forms

12.8.1 The classic viewmodel

12.8.2 A separation of concerns

12.8.3 Deciding if you need more layers of indirection

12.8.4 When viewmodels make sense

12.8.5 Imperative considerations

12.8.6 Making imperative code leaner

12.9 UI Principle 12: Feature views aren't always full-screen

12.9.1 Not every screen is necessarily a feature

13.2 Considering various approaches

13.2.1 A top-down approach

13.2.2 A bottom-up approach

13.2.3 A holistic approach

13.2.4 A mixed approach

13.7 Implementing SelectionView

13.7.1 Defining SelectionView

13.7.2 Compile-time versus runtime

13.7.3 Implementing SelectionItemView

13.9 Implementing view primitives

13.9.1 View primitives in the UI Library

14.1 The problem of dependent features

14.1.1 Error handling

14.1.2 Handle errors more gracefully

14.1.3 Multiple simultaneous errors

14.3 Connecting data-loading to a feature

14.3.1 Extending to add functionality

14.3.2 Supporting optional data

14.4 Composition instead of extension

14.4.1 Nesting views

14.4.2 Swapping the names for consistency

14.5 Dependencies and self-sufficient features

14.5.1 Modularity and encapsulation

15.3 Implementing the new CourseView

15.3.1 Three states

15.4 A self-sufficient feature in practice

15.4.1 A deep linking example

15.5 Increasing flexibility by removing dependencies

15.5.1 Replacing a property with a closure

15.5.2 `CourseView' using a closure

15.5.3 The closure in action

15.5.4 Trade-offs when using a closure

15.5.5 Restoring API stability

16.1 Where we left off

16.1.1 Why the Course feature currently isn't portable

16.1.2 Why we currently can't unit-test Course as a system

16.2 Pushing the logic out of the UI domain

16.2.1 Introducing a source of truth model

16.2.2 Moving logic to the model domain

16.2.3 Implementing `CourseSession'

16.2.4 Simplifying `CourseView'

16.3 Verifying our new implementation

16.3.1 Detaching a feature from a screen

16.3.2 Supporting other platforms and patterns

16.3.3 Maturing syncing logic

16.3.4 Unit tests instead of manual UI checks

17.1 Use case #1: Pagination

17.1.1 Postponing can positively impact development

17.1.2 The technical design

17.1.3 Self-sufficient features pay off

17.2 Use case #2: Bento-Box UI

17.2.1 A flat hierarchy

17.2.2 Showcasing complexity

17.2.3 Pushing out responsibilities

17.2.4 Disconnected features

17.2.5 A deeper hierarchy

17.3 Evaluating our approach

17.3.1 A bug occurs

17.3.2 Transforming a complex screen problem into a simpler dependency problem

17.3.3 When feature views need to interoperate

17.3.4 Syncing model changes

17.4 Use case #3: Simple UI, complex functionality

17.4.1 A tutor's settings

17.4.2 A naive approach

17.4.3 Creating a hierarchy, again

17.4.4 Disconnecting UI from the functionality

17.4.5 Fewer dependencies

17.4.6 More granularity

18.1 Common problems

18.1.1 A smarter, yet still problematic, approach

18.1.2 The view decides what the parent should be

18.1.3 The child orders a parent around

18.2 Preparing for a solution

18.2.1 What we need to support

18.5 A closure implementation

18.5.1 When a parent is a coordinator

18.5.2 Cleaning up the call-site

18.5.3 Gluing everything together

18.5.4 Inside CourseView

18.5.5 Inside CourseUI

18.5.6 Cleaning up CourseUI

18.5.7 Trade-offs when using closures

18.6 Passing a navigation type

18.6.1 A navigation interface

18.6.2 The problem of passing a navigation type

18.6.3 The name sets expectations

18.7 Dealing with optionality

18.7.1 Designing a declarative solution

18.7.2 Reasoning about optionality

18.7.3 Embracing optionality

18.8 Implementing a declarative API

18.8.1 Gluing actions to new instances

18.8.2 Implementing all declarative methods

18.8.3 Connecting to CourseUI

18.8.4 Chaining forever

19.1 An authorization flow

19.1.1 A flow is born

19.1.2 Defining the Authorization domain

19.2 Gathering requirements: deceptively complex

19.2.1 List of requirements

19.2.2 First attempt at handling complexities

19.4 Why do we need navigation flows, anyway?

19.4.1 The role of views

19.4.2 Views rarely are features

19.4.3 Views in flows

19.4.4 Navigation flows are often features

19.5 A navigation flow is like a story

19.5.1 Many flows can be reduced to a story

19.5.2 Purpose matters; the rest is extra

19.6 Designing the API

19.6.1 Re-adding complexities

19.6.2 Defining internal types

19.6.3 Adding dependencies

19.6.4 Adding configurations

20.3 Differences between design systems and UI libraries

20.3.1 Ownership in UI libraries

20.3.2 Shared ownership in design systems

20.4 Why a design system matters to developers

20.4.1 A better working culture

20.4.2 Unspoken decisions aren’t always in the design

20.4.3 Developers gain autonomy

20.4.4 Adapting features from other platforms

20.4.5 Experienced developers and design systems

20.4.6 Design systems help new and onboarding developers

20.5 Challenges when introducing a design system

20.5.1 Migrating to a design system is challenging

20.6 Gradually building a design system

20.6.1 Focusing on a UI library

20.6.2 Matching the current way of working

20.7 The current UI library

20.7.1 What our UI library is lacking

20.7.2 Filling the gaps with UI primitives

21.1 Typography

21.1.1 Using font primitives in code

21.1.2 Semantic text styles

21.1.3 Semantic text styles in code

21.1.4 A look behind the scenes

21.1.5 Considering alternative approaches

21.1.6 The implementation is a detail

21.1.7 Do you always need semantic text styles?

21.2 Colors

21.2.1 How to extract colors

21.2.2 Defining colors in code

21.2.3 A naive use of colors

21.2.4 Semantic colors

21.2.5 Defining semantic colors

21.2.6 Benefits

21.2.7 Upgrading to dynamic colors

21.2.8 Updating a semantic color

21.2.9 A short thought on modern color variations

21.3 Understanding color abstractions

21.3.1 When to use a palette, then?

21.3.2 Escape hatches for colors

21.4 Supporting custom themes

21.4.1 Theming in code

21.4.2 Updating the colors

21.5 Granular color control

21.5.1 Avoiding a migration

21.5.2 Granular control for semantic colors

22.1 Spacing

22.1.1 Defining spacing primitives

22.1.2 Applying spacing primitives

22.1.3 Semantic spacing

22.1.4 Dynamic spacing

22.1.5 Implementing dynamic spacing

22.2 Icons

22.2.1 Semantic icons

22.2.2 Mixing semantic and primitive icons

22.3 Shadows

22.3.1 Defining a custom shadow method

22.3.2 Shadows and dark mode

22.3.3 No primitives needed

22.3.4 Heuristic

23.4 Preparing the team

23.4.1 Educating the team

23.4.2 Be approachable and helpful

23.5 Ensuring new code uses new UI

23.5.1 Using a linter

23.5.2 Soft rollout

23.5.3 Lint UI rules for new code only

23.5.4 Preventing regressions

23.6 Migrating preexisting features

23.6.1 Start by doing some work yourself

23.6.2 Locally lint the legacy files

23.6.3 Migrating to primitives via scripting

23.6.4 When to migrate to primitives vs semantic values

23.6.5 Migrating to semantic UI

23.6.6 Script and undo workflow

23.6.7 Migrating via an intermediate step

23.6.8 Preparing for manual labor

23.7 Turning Migration Into Adoption

23.7.1 Start with migrating components

23.7.2 Status quo bias

23.7.3 New rule: Touch a view? Migrate it.

23.7.4 Loss aversion

23.7.5 Make them take a small step

23.7.6 Social proof

23.7.7 Using Self-Determination Theory to motivate migration

23.7.8 The IKEA effect

23.7.9 Reward & recognize teams that migrate

23.7.10 Helping people want the new system

23.8 App-wide migrations

23.8.1 Component adapters

23.8.2 Match the API

23.8.3 Feature flags

24.2 Transitioning from UI elements to tokens

24.2.1 What is a token?

24.3 Adding tokens to our project

24.3.1 Primitive and semantic tokens

24.3.2 Tokens vs Design System

24.3.3 Naming Tokens Together

24.3.4 Why not start with tokens first?

24.4 Where and how tokens are defined

24.4.1 Tokens live outside a UI library

24.5 Manually syncing tokens for a single platform

24.5.1 Lightweight workflows

24.6 Design as the source of truth, developers sync

24.6.1 What a designer can do to help

24.7 Designer syncs; Code is source of truth

24.7.1 Code tends to be more centralized

24.7.2 Updating the code

24.7.3 A designer doesn’t have to edit code perfectly

24.7.4 Benefits of this approach

24.7.5 Downsides

24.9 Using a handoff system

24.9.1 Token decisions are still shared

25.1 Manually syncing tokens across multiple platforms

25.1.1 Double the handoffs, double the communication

25.2 Introducing a token repository

25.2.1 A token repository workflow

25.2.2 Why do designers both import and export tokens?

25.2.3 Versioning and shared history

25.2.4 What token JSON files look like

25.2.5 Token aliasing

25.3 Sharing tokens between platforms

25.3.1 Disconnect token names from values

25.3.2 Platform-specific overrides

25.3.3 Platform-specific extensions

25.4 Introducing documentation

25.4.1 Where the doc lives

25.4.2 Who maintains the documentation?

25.4.3 What to include in token documentation

25.5 Lightweight automation

25.5.1 Starting with lightweight automation

25.5.2 Adding token validation

25.5.3 Generating platform-specific files

25.5.4 Updated workflow

25.5.5 Manual distribution (for now)

25.6 Fully integrated automation

25.6.1 Opening pull requests automatically

25.6.2 Publishing as packages

25.6.3 Documentation as part of the pipeline

25.6.4 The complete automated workflow

25.8 Conclusion

25.8.1 Moving on

26.2 Reviewing when a monolith makes sense

26.2.1 Domain discovery benefits

26.2.2 Avoiding premature architectural decisions

26.3 Counterpoint: When starting with modules makes sense

26.3.1 When domain boundaries are well understood

26.3.2 When team scaling is predictable

26.3.3 When you need to reuse domains from day one

26.4 Team scaling pains: communication and development speed slow down

26.4.1 Unintentional coupling

26.4.2 Merge conflicts become frequent

26.4.3 Build times slow to a crawl

26.4.4 Knowledge silos form accidentally, not intentionally

26.5 Transitioning into modules

26.5.1 What we mean by “module”

26.5.2 Distribution differences

26.6 A naive extraction process

26.6.1 Starting with feature-modules

26.6.2 Breaking the circular dependency

26.6.3 The problem with interfaces

26.6.4 Extracting existing features

26.7 A practical extraction process

26.7.1 Introducing a new feature-module

26.7.2 Extracting an existing feature

27.1 Access Control Limitations

27.1.1 Limited access control

27.1.2 How modules improve access control

27.1.3 APIs are promises

27.2 Shrinking the public API

27.2.1 Layered API design

27.3 Maturing a feature module

27.3.1 Adding a sample app

27.3.2 Benefits

27.3.3 Consider UI Tests

27.3.4 Public APIs and unconventional testing

27.4 Think like an open-source maintainer

27.4.1 Error messages that guide implementers

28.1 The problems of unstructured modules

28.1.1 Blurred priorities

28.1.2 Eroding architecture

28.1.3 In which “box” does code go?

28.1.4 Unbalanced testing

28.1.5 Adding structure

28.2 The Three Categories at a Glance

28.2.1 Feature modules

28.2.2 Foundational modules

28.2.3 Support modules

28.2.4 Why these categories matter

28.3 Feature Modules: User-Facing Autonomy

28.3.1 Design principles

28.3.2 Autonomy and Scaling

28.3.3 Feature modules embrace change

28.4 Support Modules: The Enablers Behind Features

28.4.1 Support vs feature modules

28.4.2 Integration challenges

28.5 Foundational Modules: The Infrastructure Layer

28.5.1 Foundational vs support modules

28.5.2 Change is more planned

28.5.3 A warning on foundational modules

28.5.4 Building for unknown consumers

28.6 API Surface Design

28.6.1 Feature modules

28.6.2 Support modules

28.6.3 Foundational modules

29.1 Dual-role modules

29.1.1 Splitting domains

29.1.2 Splitting a module

29.2 Complex Features: Keep Together or Distribute?

29.2.1 Keeping momentum

29.3 Handling Lateral Dependencies

29.3.1 Lateral dependencies are more problematic with modules

29.3.2 Coordination logic moves up; dependencies flow down

29.3.3 Pushing coordination logic out of an app

29.3.4 Introducing orchestration modules

29.3.5 Where orchestration modules fit

29.3.6 Extracting downward

29.4 Interface Modules: The Hidden Costs of Abstraction

29.4.1 Why teams reach for interface modules

29.4.2 The complexity migration

29.4.3 The public API grows larger

29.4.4 Other problems

29.6 Testing without the overhead

29.6.1 Catching problems earlier