ver8

Combine

Combine: Asynchronous Programming with

Swift
By Scott Gardner, Shai Mishali, Florent Pillet & Marin Todorov

Copyright ©2019 Razeware LLC.

Notice of Rights
All rights reserved. No part of this book or corresponding materials (such as text,
images, or source code) may be reproduced or distributed by any means without prior
written permission of the copyright owner.

Notice of Liability
This book and all corresponding materials (such as source code) are provided on an
“as is” basis, without warranty of any kind, express of implied, including but not
limited to the warranties of merchantability, fitness for a particular purpose, and
noninfringement. In no event shall the authors or copyright holders be liable for any
claim, damages or other liability, whether in action of contract, tort or otherwise,
arising from, out of or in connection with the software or the use of other dealing in
the software.

Trademarks
All trademarks and registered trademarks appearing in this book are the property of
their own respective owners.

raywenderlich.com 2
Combine

Table of Contents: Overview

About the Cover ...................................................................................... 12
What You Need ........................................................................................ 16
Book License ............................................................................................. 17
Book Source Code & Forums ............................................................. 18
Section I: Introduction to Combine .............................. 20
Chapter 1: Hello, Combine! .................................................... 21
Chapter 2: Publishers & Subscribers .................................. 37
Section II: Operators ......................................................... 68
Chapter 3: Transforming Operators ................................... 70
Chapter 4: Filtering Operators ............................................. 90
Chapter 5: Combining Operators ...................................... 113
Chapter 6: Time Manipulation Operators ..................... 139
Chapter 7: Sequence Operators ........................................ 166
Chapter 8: In Practice: Project "Collage"........................ 188
Section III: Combine in Action ..................................... 212
Chapter 9: Networking .......................................................... 214
Chapter 10: Debugging ......................................................... 220
Chapter 11: Timers ................................................................. 225
Chapter 12: Key-Value Observing .................................... 230
Chapter 13: Resource Management ................................ 237
Chapter 14: In Practice: Project "News" ........................ 244

raywenderlich.com 3
Combine

Section IV: Advanced Combine ................................... 263

Chapter 15: In Practice: Combine & SwiftUI ................ 265
Chapter 16: Error Handling ................................................. 295
Chapter 17: Schedulers ......................................................... 322
Chapter 18: Custom Publishers & Handling
Backpressure ............................................................................. 346
Chapter 19: Testing ................................................................. 382
Section V: Building a Complete App .......................... 404
Chapter 20: In Practice: Building a Complete App ..... 405
Conclusion .............................................................................................. 436

raywenderlich.com 4
Combine

Table of Contents: Extended

About the Cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
About the Artist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
What You Need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Book License . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Book Source Code & Forums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Section I: Introduction to Combine . . . . . . . . . . . . . . . . 20
Chapter 1: Hello, Combine! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Asynchronous programming. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Foundation of Combine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Combine basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
What's the benefit of Combine code over "standard" code? . . . . . . . . . 32
App architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Book projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Where to go from here?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Chapter 2: Publishers & Subscribers. . . . . . . . . . . . . . . . . . . . . . . . . 37
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Hello Publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Hello Subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Hello Cancellable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Understanding what’s going on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating a custom subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Hello Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Hello Subject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Dynamically adjusting demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Type erasure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

raywenderlich.com 5
Combine

Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Where to go from here?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Section II: Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Chapter 3: Transforming Operators . . . . . . . . . . . . . . . . . . . . . . . . . 70
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Collecting values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Mapping values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Flattening publishers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Replacing upstream output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Incrementally transforming output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Where to go from here?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Chapter 4: Filtering Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Filtering basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Compacting and ignoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Finding values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Dropping values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Limiting values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Chapter 5: Combining Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Prepending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Appending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Advanced combining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

raywenderlich.com 6
Combine

Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Chapter 6: Time Manipulation Operators . . . . . . . . . . . . . . . . . . 139
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Shifting time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Collecting values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Collecting values (part 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
Holding off on events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Timing out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Measuring time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Chapter 7: Sequence Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Finding values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Querying the publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Chapter 8: In Practice: Project "Collage" . . . . . . . . . . . . . . . . . . . 188
Getting started with "Collage" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Talking to other view controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Wrapping a callback function as a future . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Presenting a view controller as a future. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Sharing subscriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Publishing properties with @Published . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Operators in practice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Section III: Combine in Action . . . . . . . . . . . . . . . . . . . . 212

raywenderlich.com 7
Combine

Chapter 9: Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

URLSession extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Codable support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Publishing network data to multiple subscribers . . . . . . . . . . . . . . . . . . . 216
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Chapter 10: Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Printing events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Acting on events — performing side effects . . . . . . . . . . . . . . . . . . . . . . . . . 222
Using the debugger as a last resort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Chapter 11: Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Using RunLoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Using the Timer class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Using DispatchQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Chapter 12: Key-Value Observing . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Introducing publisher(for:options:) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Preparing and subscribing to your own KVO-compliant properties 231
ObservableObject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Chapter 13: Resource Management . . . . . . . . . . . . . . . . . . . . . . . 237
The share() operator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
The multicast(_:) operator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

raywenderlich.com 8
Combine

Chapter 14: In Practice: Project "News" . . . . . . . . . . . . . . . . . . . 244

Getting started with the Hacker News API . . . . . . . . . . . . . . . . . . . . . . . . . 245
Getting a single story . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Multiple stories via merging publishers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Getting the latest stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Section IV: Advanced Combine . . . . . . . . . . . . . . . . . . . 263

Chapter 15: In Practice: Combine & SwiftUI . . . . . . . . . . . . . . . 265
Hello, SwiftUI! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
Getting started with "News" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
A first taste of managing view state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Fetching the latest stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Using ObservableObject for model types . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Displaying errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
Subscribing to an external publisher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Initializing the app's settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Editing the keywords list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Chapter 16: Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Never . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Dealing with failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Chapter 17: Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
An introduction to schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

raywenderlich.com 9
Combine

Operators for scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324

Scheduler implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 18: Custom Publishers & Handling Backpressure 346
Creating your own publishers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Publishers as extension methods. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
The subscription mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Publishers emitting values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Publishers transforming values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Handling backpressure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Chapter 19: Testing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
Testing Combine operators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Testing production code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403

Section V: Building a Complete App . . . . . . . . . . . . . . 404

Chapter 20: In Practice: Building a Complete App . . . . . . . . . 405
Getting started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Setting goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Implementing JokesViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Wiring JokesViewModel up to the UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Implementing Core Data with Combine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Key points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434

raywenderlich.com 10
Combine

Where to go from here? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

raywenderlich.com 11
A About the Cover

The polar bear, although majestic on land, is also a passionate creature of the sea; its
scientific name, Ursus maritimus, means "sea bear"! Most polar bears spend the
majority of their lives on the edge of sea ice, waiting for a seal to swim by and make a
tasty lunch for the polar bear; for this reason, they are considered a marine mammal,
in the same vein as sea otters, manatees, and whales.

The sight of a polar bear cub instantly evokes that cute squeee feeling in all of us, but
make no mistake — these cuddly little cubs will soon grow into stealthy, patient, and
powerful adult hunters. The Combine framework, as well, is still in its infancy, and
even though there are other powerful competing frameworks like RxSwift, we think
that as Combine grows up, it will soon turn out to be as powerful, efficient and
stealthy as a polar bear — just not quite as cute!

raywenderlich.com 12
Combine About the Cover

Dedications
"To Jenn, for being so supportive and encouraging. To
Charlotte, keep up the great work in school — you motivate
me! To Betty, my best l’il friend for all her 18 years."

— Scott Gardner

"For my wife Elia and Baby Ethan—my love, inspiration, and

rock . To my family and friends for their support: Dad,
Mom, Ziv, Adam, and everyone else, you’re the best!"

— Shai Mishali

"To Fabienne and Alexandra ."

— Florent Pillet

"To my father. To my mom. To Mirjam and our beautiful

daughter."

— Marin Todorov

raywenderlich.com 13
Combine About the Cover

About the Authors

Scott Gardner is an author and the technical editor for this book.
He’s also authored over a dozen books, video courses, tutorials, and
articles on Swift and iOS app development — with a focus on
reactive programming. He’s an iOS Architect at Wayfair, and an
Apple Certified Trainer for Swift and iOS. You can find Scott on
Twitter or GitHub as @scotteg, or connect with him on LinkedIn at
scotteg.com.

Shai Mishali is an author and the final pass editor on this book.
He's the iOS Tech Lead for Gett, the global on-demand mobility
company; as well as an international speaker, and a highly active
open-source contributor and maintainer on several high-profile
projects - namely, the RxSwift Community and RxSwift projects,
but also releases many open-source endeavors around Combine
such as CombineCocoa, RxCombine and more. As an avid
enthusiast of hackathons, Shai took 1st place at BattleHack Tel-
Aviv 2014, BattleHack World Finals San Jose 2014, and Ford's
Developer Challenge Tel-Aviv 2015. You can find him on GitHub
and Twitter as @freak4pc.

Florent Pillet is an author of this book. He has been developing for

mobile platforms since the last century and moved to iOS on day 1.
He adopted reactive programming before Swift was announced,
using it in production since 2015. A freelance developer, Florent
also uses reactive programming on the server side as well as on
Android and likes working on tools for developers like the popular
NSLogger when he's not contracting, training or reviewing code for
clients worldwide. Say hello to Florent on Twitter and GitHub at
@fpillet.

Marin Todorov is an author of this book. Marin is one of the

founding members of the raywenderlich.com team and has worked
on eight of the team’s books. He's an independent contractor and
has worked for clients like Roche, Realm, and others. Besides
crafting code, Marin also enjoys blogging, teaching and speaking at
conferences. He happily open-sources code. You can find out more
about Marin at www.underplot.com.

raywenderlich.com 14
Combine About the Cover

About the Artist

Vicki Wenderlich is the designer and artist of the cover of this
book. She is Ray’s wife and business partner. She is a digital artist
who creates illustrations, game art and a lot of other art or design
work for the tutorials and books on raywenderlich.com. When she’s
not making art, she loves hiking, a good glass of wine and
attempting to create the perfect cheese plate.

raywenderlich.com 15
W What You Need

To follow along with this book, you’ll need the following:

• A Mac running macOS Mojave (10.14) or later. Earlier versions might work, but
they're untested.

• Xcode 11 or later. Xcode is the main development tool for iOS. You’ll need Xcode
11 or later for the tasks in this book, since Combine was introduced with the iOS 13
SDK. You can download the latest version of Xcode from Apple’s developer site
here: apple.co/2asi58y

• An intermediate level knowledge of Swift. This book teaches you how to write
declarative and reactive iOS applications using Apple's Combine framework.
Combine uses a multitude of advanced Swift features such as generics, so you
should have at least an intermediate-level knowledge of Swift.

If you want to try things out on a physical iOS device, you’ll need a developer
account with Apple, which you can obtain for free. However, all the sample projects
in this book will work just fine in the iOS Simulator bundled with Xcode, so a paid
developer account is completely optional.

raywenderlich.com 16
L Book License

By purchasing Combine: Asynchronous Programming with Swift, you have the

following license:

• You are allowed to use and/or modify the source code in Combine: Asynchronous
Programming with Swift in as many apps as you want, with no attribution required.

• You are allowed to use and/or modify all art, images and designs that are included
in Combine: Asynchronous Programming with Swift in as many apps as you want, but
must include this attribution line somewhere inside your app: “Artwork/images/
designs: from Combine: Asynchronous Programming with Swift, available at
www.raywenderlich.com”.

• The source code included in Combine: Asynchronous Programming with Swift is for
your personal use only. You are NOT allowed to distribute or sell the source code in
Combine: Asynchronous Programming with Swift without prior authorization.

• This book is for your personal use only. You are NOT allowed to sell this book
without prior authorization, or distribute it to friends, coworkers or students; they
would need to purchase their own copies.

All materials provided with this book are provided on an “as is” basis, without
warranty of any kind, express or implied, including but not limited to the warranties
of merchantability, fitness for a particular purpose and noninfringement. In no event
shall the authors or copyright holders be liable for any claim, damages or other
liability, whether in an action or contract, tort or otherwise, arising from, out of or in
connection with the software or the use or other dealings in the software.

All trademarks and registered trademarks appearing in this guide are the properties
of their respective owners.

raywenderlich.com 17
B Book Source Code &
Forums

If you bought the digital edition

This book comes with the source code for the starter and completed projects for each
chapter. These resources are shipped with the digital edition you downloaded here:

• https://store.raywenderlich.com/products/combine-asynchronous-programming-
with-swift.

If you bought the print version

You can get the source code for the print edition of the book here: https://
store.raywenderlich.com/products/combine-asynchronous-programming-with-
swift-source-code.

And if you purchased the print version of this book, you’re eligible to upgrade to the
digital editions at a significant discount! Simply email [email protected] with
your receipt for the physical copy and we’ll get you set up with the discounted digital
edition version of the book.

Forums
We’ve also set up an official forum for the book here:

• https://forums.raywenderlich.com.

This is a great place to ask questions about the book or to submit any errors you may
find.

raywenderlich.com 18
Combine Book Source Code & Forums

Digital book editions

We have a digital edition of this book available in both ePUB and PDF, which can be
handy if you want a soft copy to take with you, or you want to quickly search for a
specific term within the book.

Buying the digital edition version of the book also has a few extra benefits: free
updates each time we update the book, access to older versions of the book, and you
can download the digital editions from anywhere, at anytime.

Visit our book store page here:

• https://store.raywenderlich.com/products/combine-asynchronous-programming-
with-swift.

raywenderlich.com 19
Section I: Introduction to
Combine

In this part of the book, you're going to ramp up over the basics of Combine and
learn about some of the building blocks it comprises. You'll learn what Combine aims
to solve and what are some of the abstractions it provides to help you solve them:
Publisher, Subscriber, Subscription, Subject and much more.

Specifically, you'll cover:

Chapter 1: Hello, Combine!: A gentle introduction to what kind of problems

Combine solves, a back story of the roots of reactive programming on Apple's
platforms, and a crash course into the basic moving pieces of the framework.

Chapter 2: Publishers & Subscribers: The essence of Combine is that publishers

send values to subscribers. In this chapter you’ll learn all about what that means and
how to work with publishers and subscribers, and how to manage the subscriptions
that are created between the two of them.

raywenderlich.com 20
1 Chapter 1: Hello,
Combine!
By Marin Todorov

This book aims to introduce you to the Combine framework and to writing
declarative and reactive apps with Swift for Apple platforms.

In Apple's own words: "The Combine framework provides a declarative approach for
how your app processes events. Rather than potentially implementing multiple delegate
callbacks or completion handler closures, you can create a single processing chain for a
given event source. Each part of the chain is a Combine operator that performs a distinct
action on the elements received from the previous step."

Although very accurate and to the point, this delightful definition might sound a
little too abstract at first. That's why, before delving into coding exercises and
working on projects in the following chapters, you'll take a little time to learn a bit
about the problems Combine solves and the tools it uses to do so.

Once you've built up the relevant vocabulary and some understanding of the
framework in general, you'll move on to covering the basics while coding.

Gradually, as you progress in the book, you'll learn about more advanced topics and
eventually work through several projects.

When you've covered everything else you will, in the last chapter, work on a complete
app built with Combine.

raywenderlich.com 21
Combine Chapter 1: Hello, Combine!

Asynchronous programming
In a simple, single-threaded language, a program executes sequentially line-by-line.
For example, in pseudocode:

begin
var name = "Tom"
print(name)
name += " Harding"
print(name)
end

Synchronous code is easy to understand and makes it especially easy to argue about
the state of your data. With a single thread of execution, you can always be sure what
the current state of your data is. In the example above, you know that the first print
will always print "Tom" and the second will always print "Tom Harding".

Now, imagine you wrote the program in a multi-threaded language that is running
an asynchronous event-driven UI framework, like an iOS app running on Swift and
UIKit.

Consider what could potentially happen:

--- Thread 1 ---

begin
var name = "Tom"
print(name)

--- Thread 2 ---

name = "Billy Bob"

--- Thread 1 ---

name += " Harding"
print(name)
end

Here, the code sets name's value to "Tom" and then adds "Harding" to it, just like
before. But because another thread could execute at the same time, it's possible that
some other part of your program could run between the two mutations of name and
set it to another value like "Billy Bob".

When the code is running concurrently on different cores, it's difficult to say which
part of the code is going to modify the shared state first.

raywenderlich.com 22
Combine Chapter 1: Hello, Combine!

The code running on "Thread 2" in the example above might be:

• executing at exactly the same time on a different CPU core as your original code.

• executing just before name += " Harding", so instead of the original value "Tom",
it gets "Billy Bob" instead.

What exactly happens when you run this code depends on the system load, and you
might see different results each time you run the program.

Managing mutable state in your app becomes a loaded task once you run
asynchronous concurrent code.

Foundation and UIKit/AppKit

Apple has been improving asynchronous programming for their platforms over the
years. They've created several mechanisms you can use, on different system levels, to
create and execute asynchronous code. You’ve probably used these in your projects
without giving them a second thought because they are so fundamental to writing
mobile apps.

You’ve probably used most of the following:

• NotificationCenter: Executes a piece of code any time an event of interest

happens, such as when the user changes the orientation of the device or when the
software keyboard shows or hides on the screen.

• The delegate pattern: Lets you define an object that acts on behalf of, or in
coordination with, another object. For example, in your app delegate, you define
what should happen when a new remote notification arrives, but you have no idea
when this piece of code will be executed or how many times it will execute.

• Grand Central Dispatch and Operations: Helps you abstract the execution of
pieces of work. You can use them to schedule code to be executed sequentially in a
serial queue or to run a multitude of tasks concurrently in different queues with
different priorities.

• Closures: Create detached pieces of code that you can pass around in your code, so
other objects can decide whether to execute it, how many times, and in what
context.

Since most typical code performs some work asynchronously, and all UI events are
inherently asynchronous, it’s impossible to make assumptions about which order the
entirety of your app code will be executed.

raywenderlich.com 23
Combine Chapter 1: Hello, Combine!

And yet, writing good asynchronous programs is possible. It's just more complex
than... well, we'd like it to be. Unfortunately, asynchronous code and resource
sharing can produce issues which are difficult to reproduce, track down and
ultimately fix.

Certainly, one of the causes for these issues is the fact that a solid, real-life app most
likely uses all the different kinds of asynchronous APIs, each with its own interface,
like so:

Combine aims to introduce a new language to the Swift ecosystem that helps you
bring more order into the chaos of the asynchronous programming world.

Apple has integrated Combine's API deep into the Foundation framework, so Timer,
NotificationCenter and core frameworks like Core Data already speak its
language. Luckily, Combine is also very easy to integrate into your own code.

Finally, last but definitely not least, Apple designed their amazing new UI framework,
SwiftUI, to integrate easily with Combine as well.

To give you an idea of how committed Apple is to reactive programming with

Combine, here's a simple diagram showing where Combine sits in the system
hierarchy:

raywenderlich.com 24
Combine Chapter 1: Hello, Combine!

Various system frameworks, from Foundation all the way up to SwiftUI, depend on
Combine and offer Combine integration as an alternative to their "traditional" APIs.

Since Combine is an Apple framework, it doesn't aim to take away the role of well-
tested, solid APIs like Timer or NotificationCenter. Those Foundation types are
still present and doing their part. Instead, Combine integrates with them and allows
all the types in your app that want to talk asynchronously to each other do so via a
new, universal language.

So if the idea of using the same asynchronous tools to connect all the parts of your
app, from the data model to the networking layer and the user interface, sounds
interesting — you're in the right place, keep reading!

Foundation of Combine
Declarative, reactive programming isn't a new concept. It's been around for quite a
while, but it's made a fairly noticeable comeback in the last decade.

The first "modern-day" reactive solution came in a big way in 2009 when a team at
Microsoft launched a library called Reactive Extensions for .NET (Rx.NET).

Microsoft made that Rx.NET implementation open source in 2012, and since then,
many different languages have started to use its concepts. Currently, there are many
ports of the Rx standard like RxJS, RxKotlin, RxScala, RxPHP and more.

raywenderlich.com 25
Combine Chapter 1: Hello, Combine!

For Apple's platforms, there have been several third-party reactive frameworks like
RxSwift, which implements the Rx standard; ReactiveSwift, which was inspired by
Rx; Interstellar, which is a custom implementation and others.

Combine implements a standard that is different but similar to Rx, called Reactive
Streams. Reactive Streams has a few key differences from Rx, but they both agree on
most of the core concepts.

If you haven't previously used one or another of the frameworks mentioned above —
don't worry. So far, reactive programming has been a rather niche concept for Apple's
platforms, and especially with Swift.

In iOS 13/macOS Catalina, however, Apple brought reactive programming support to

its ecosystem via the built-in system framework, Combine.

As with any new technology from Apple, its application is at first slightly limited:
You can use Combine only for apps that support iOS 13/macOS Catalina or later. But
as with any technology that Apple bets on, its support will quickly become
widespread and the demand for Combine skills will surge.

With that said, start by learning some of Combine's basics to see how it can help you
write safe and solid asynchronous code.

Combine basics
In broad strokes, the three key moving pieces in Combine are publishers, operators
and subscribers. There are, of course, more players in the team, but without those
three you can't achieve much.

You'll learn in detail about publishers and subscribers in Chapter 2, “Publishers &
Subscribers,” and the complete second section of the book is devoted to acquainting
you with as many operators as humanly possible.

In this introductory chapter, however, you're going to get a simple crash course to
give you a general idea of the purpose those types have in the code and what their
responsibilities are.

raywenderlich.com 26
Combine Chapter 1: Hello, Combine!

Publishers
Publishers are types that can emit values over time to one or more interested parties,
such as subscribers. Regardless of the internal logic of the publisher, which can be
pretty much anything including math calculations, networking or handling user
events, every publisher can emit multiple events of these three types:

1. An output value of the publisher's generic Output type.

2. A successful completion.

3. A completion with an error of the publisher's Failure type.

A publisher can emit zero or more output values, and if it ever completes, either
successfully or due to a failure, it will not emit any other events.

Here's how a publisher emitting Int values could look like visualized on a timeline:

The blue boxes represent values that are emitted at a given time on the timeline, and
the numbers represent the emitted values. A vertical line, like the one you see on the
right-hand side of the diagram, represents a successful stream completion.

The simple contract of three possible events is so universal that it could represent
any kind of dynamic data in your program. That's why you can address any task in
your app using Combine publishers — regardless of whether it's about crunching
numbers, making network calls, reacting to user gestures or displaying data on-
screen.

raywenderlich.com 27
Combine Chapter 1: Hello, Combine!

Instead of always looking in your toolbox for the right tool to grab for the task at
hand, be it adding a delegate or injecting a completion callback — you can just use a
publisher instead.

One of the best features of publishers is that they come with error handling built in;
error handling isn't something you add optionally at the end, if you feel like it.

The Publisher protocol is generic over two types, as you might have noticed in the
diagram earlier:

• Publisher.Output is the type of the output values of the publisher. If the

publisher is specialized as an Int, it can never emit a String or a Date value.

• Publisher.Failure is the type of error the publisher can throw if it fails. If the
publisher can never fail, you specify that by using a Never failure type.

When you subscribe to a given publisher, you know what values to expect from it and
which errors it could fail with.

Operators
Operators are methods declared on the Publisher protocol that return either the
same or a new publisher. That's very useful because you can call a bunch of operators
one after the other, effectively chaining them together.

Because these methods, called "operators", are highly decoupled and composable,
they can be combined (aha!) to implement very complex logic over the execution of a
single subscription.

It's fascinating how operators fit tightly together like puzzle pieces. They cannot be
mistakenly put in the wrong order or fit together if one's output doesn't match the
next one's input type:

raywenderlich.com 28
Combine Chapter 1: Hello, Combine!

In a clear deterministic way, you can define the order of each of those asynchronous
abstracted pieces of work alongside with the correct input/output types and built-in
error handling. It's almost too good to be true!

As an added bonus, operators always have input and output, commonly referred to as
upstream and downstream — this allows them to avoid shared state (one of the
core issues we discussed earlier).

Operators focus on working with the data they receive from the previous operator
and provide their output to the next one in the chain. This means that no other
asynchronously-running piece of code can "jump in" and change the data you're
working on.

Subscribers
Finally, you arrive at the end of the subscription chain: Every subscription ends with
a subscriber. Subscribers generally do "something" with the emitted output or
completion events.

Currently, Combine provides two built-in subscribers, which make working with data
streams straightforward:

• The sink subscriber allows you to provide closures with your code that will receive
output values and completions. From there, you can do anything your heart desires
with the received events.

raywenderlich.com 29
Combine Chapter 1: Hello, Combine!

• The assign subscriber allows you to, without the need of custom code, bind the
resulting output to some property on your data model or on a UI control to display
the data directly on-screen via a key path.

Should you have other needs for your data, creating custom subscribers is even easier
than creating publishers. Combine uses a set of very simple protocols that allow you
to be able to build your own custom tools whenever the workshop doesn't offer the
right one for your task.

Subscriptions

Note: This book uses the term subscription to describe both Combine’s
Subscription protocol and its conforming objects, as well as the complete
chain of a publisher, operators and a subscriber.

When you add a subscriber at the end of a subscription, it "activates" the publisher all
the way at the beginning of the chain. This is a curious but important detail to
remember — publishers do not emit any values if there are no subscribers to
potentially receive the output.

Subscriptions are a wonderful concept in that they allow you to declare a chain of
asynchronous events with their own custom code and error handling only once, and
then you never have to think about it again.

If you go full-Combine, you could describe your whole app's logic via subscriptions
and once done, just let the system run everything without the need to push or pull
data or call back this or that other object:

raywenderlich.com 30
Combine Chapter 1: Hello, Combine!

Once the subscription code compiles successfully and there are no logic issues in
your custom code — you're done! The subscriptions, as designed, will asynchronously
"fire" each time some event like a user gesture, a timer going off or something else
awakes one of your publishers.

Even better, you don't need to specifically memory manage a subscription, thanks to
a protocol provided by Combine called Cancellable.

Both system-provided subscribers conform to Cancellable, which means that your

subscription code (e.g. the whole publisher, operators and subscriber call chain)
returns a Cancellable object. Whenever you release that object from memory, it
cancels the whole subscription and releases its resources from memory.

This means you can easily "bind" the lifespan of a subscription by storing it in a
property on your view controller, for example. This way, any time the user dismisses
the view controller from the view stack, that will deinitialize its properties and will
also cancel your subscription.

Or to automate this process, you can just have an [AnyCancellable] collection

property on your type and throw as many subscriptions inside it as you want. They'll
all be automatically canceled and released when the property is released from
memory.

As you see, there's plenty to learn, but it's all logical when explained in detail. And
that's exactly what the plan is for the next chapters — to bring you slowly but
steadily from zero to Combine hero by the end of this book.

raywenderlich.com 31
Combine Chapter 1: Hello, Combine!

What's the benefit of Combine code over

"standard" code?
You can, by all means, never use Combine and still create the best apps out there.
There's no argument about that. You can also create the best apps without Core Data,
URLSession, or even UIKit. But using those frameworks is more convenient, safe and
efficient than building those abstractions yourself.

Combine (and other system frameworks) aims to add another abstraction in your
async code. Another level of abstraction on the system level means tighter
integration that's well tested and a safe-bet technology for long-lasting support.

It's up to you to decide whether Combine is a great fit for your project or not, but
here are just a few "pro" reasons you might not have considered yet:

• Combine is integrated on the system level. That means Combine itself uses
language features that are not publicly available, offering you APIs that you
couldn't build yourself.

• The "old" style async code via delegates, IBAction or closures pushes you towards
writing custom code for each case of a button or a gesture you need to handle.
That's a lot of custom code to write tests for. Combine abstracts all async
operations in your code as "operators", which are already well tested.

• When all of your asynchronous pieces of work use the same interface — Publisher
— composition and reusability become extremely powerful.

• Combine's operators are highly composable. If you need to create a new one, that
new operator will instantly plug-and-play with the rest of Combine.

• Testing asynchronous code is usually more complex than testing synchronous

code. With Combine, however, the asynchronous operators are already tested, and
all that's left for you to do is test your business logic — that is, provide some input
and test if your subscription outputs the expected result.

As you see, most of the benefits revolve around safety and convenience. Combined
with the fact that the framework comes from Apple, investing in writing Combine
code looks promising.

raywenderlich.com 32
Combine Chapter 1: Hello, Combine!

App architecture
As this question is most likely already sounding alarms in your head, take a look at
how using Combine will change your pre-existing code and app architecture.

Combine is not a framework that affects how you structure your apps. Combine deals
with asynchronous data events and unified communication contract — it does not
alter, for example, how you would separate responsibilities in your project.

You can use Combine in your MVC (Model-View-Controller) apps, you can use it in
your MVVM (Model-View-ViewModel) code, in VIPER and so forth and so on.

This is one of the key aspects of adopting Combine that is important to understand
early — you can add Combine code iteratively and selectively, using it only in the
parts you wish to improve in your codebase. It's not an "all or nothing" choice you
need to make.

You could start by converting your data models, or adapting your networking layer, or
simply using Combine only in new code that you add to your app while keeping your
existing functionality as-is.

It's a slightly different story if you're adopting Combine and SwiftUI at the same
time. In that case, it really does make sense to drop the C from an MVC architecture.
But that's thanks to using Combine and SwiftUI in tandem — those two are simply on
fire when in the same room.

View controllers just don't have any chance against a Combine/SwiftUI team. When
you use reactive programming all the way from your data model to your views, you
don't need to have a special controller just to control your views:

raywenderlich.com 33
Combine Chapter 1: Hello, Combine!

If that sounds interesting, you're in for a treat, as this book includes a solid
introduction to using the two frameworks together in Chapter 15, “In Practice:
SwiftUI & Combine.”

Book projects
In this book, you'll start with the concepts first and move on to learning and trying
out a multitude of operators.

Unlike other system frameworks, you can work pretty successfully with Combine in
the isolated context of a playground.

Learning in an Xcode playground makes it easy to move forward and quickly

experiment as you progress through a given chapter and to see instantly the results
in Xcode's Console:

Combine does not require any third-party dependencies, so usually, a few simple
helper files included with the starter playground code for each chapter will suffice to
get you running. If Xcode ever gets stuck while you experiment in the playground, a
quick restart will likely solve the issue.

raywenderlich.com 34
Combine Chapter 1: Hello, Combine!

Once you move to more complex concepts than playing with a single operator, you'll
alternate between working in playgrounds and real Xcode projects like the Hacker
News app, which is a newsreader that displays news in real time:

It's important that, for each chapter, you begin with the provided starter playground
or project, as they might include some custom helper code which isn't relevant to
learning Combine. These tidbits are pre-written so you don't distract yourself from
the focus of that chapter.

In the last chapter, you’ll make use of all the skills you learned throughout the book
as you finish developing a complete iOS app that relies heavily on Combine and Core
Data. This will give you a final push on your road to building real-life applications
with Combine!

raywenderlich.com 35
Combine Chapter 1: Hello, Combine!

Key points
• Combine is a declarative, reactive framework for processing asynchronous events
over time.

• It aims to solve existing problems, like unifying tools for asynchronous

programming, dealing with mutable state and making error handling a starting
team player.

• Combine revolves around three main types: publishers to emit events over time,
operators to asynchronously process and manipulate upstream events and
subscribers to consume the results and do something useful with them.

Where to go from here?

Hopefully, this introductory chapter has been useful and has given you an initial
understanding of the issues Combine addresses as well as a look at some of the tools
it offers to make your asynchronous code safer and more reliable.

Another important takeaway from this chapter is what to expect from Combine and
what is out of its scope. Now, you know what you're in for when we speak of reactive
code or asynchronous events over time. And, of course, you don't expect using
Combine to magically solve your app's problems with navigation or drawing on-
screen.

Finally, having a taste of what's in store for you in the upcoming chapters has
hopefully gotten you excited about Combine and reactive programming with Swift.
Upwards and onwards, here we go!

raywenderlich.com 36
2 Chapter 2: Publishers &
Subscribers
By Scott Gardner

Now that you’ve learned some of the basic concepts of Combine, it’s time to jump in
and play with two of Combine’s core components — publishers and subscribers.

In this chapter, you’ll review several examples of creating publishers and subscribing
to those publishers using subscribers. By doing so, you’ll acquire important skills
that you’ll use throughout the rest of this book and beyond.

Getting started
Note: There are starter and final versions of the playgrounds and projects
you’ll use in each chapter throughout the book. The starter will be prepared
and ready for you to enter the code specified for each example and challenge.
You can compare your work with the final version at the end or along the way
if you get stuck.

raywenderlich.com 37
Combine Chapter 2: Publishers & Subscribers

For this chapter, you’ll use an Xcode playground with Combine imported. Open
Starter.playground in the projects folder and you’ll see the following:

Open Sources in the Project navigator (View ▸ Navigators ▸ Show Project

Navigator and twist down the Combine playground page), and select
SupportCode.swift. It contains the following helper function example(of:):

public func example(of description: String,

action: () -> Void) {
print("\n——— Example of:", description, "———")
action()
}

You’ll use this function to encapsulate some examples you’ll use throughout this
book.

However, before you begin playing with those examples, you first need to learn about
publishers, subscribers and subscriptions. They form the foundation of Combine and
enable you to send and receive data, typically asynchronously.

Hello Publisher
At the heart of Combine is the Publisher protocol. This protocol defines the
requirements for a type to be able to transmit a sequence of values over time to one
or more subscribers. In other words, a publisher publishes or emits events that can
include values of interest.

If you’ve developed on Apple platforms before, you can think of a publisher as kind of
like NotificationCenter. In fact, NotificationCenter now has a method named
publisher(for:object:) that provides a Publisher type that can publish
broadcasted notifications.

raywenderlich.com 38
Combine Chapter 2: Publishers & Subscribers

To check this out, go back to the starter playground and replace the Add your code
here placeholder with the following code:

example(of: "Publisher") {
// 1
let myNotification = Notification.Name("MyNotification")

// 2
let publisher = NotificationCenter.default
.publisher(for: myNotification, object: nil)
}

In this code, you:

1. Create a notification name.

2. Access NotificationCenter’s default center, call its publisher(for:object:)

method and assign its return value to a local constant.

Option-click on publisher(for:object:), and you’ll see that it returns a

Publisher that emits an event when the default notification center broadcasts a
notification.

So what’s the point of publishing notifications when a notification center is already

capable of broadcasting its notifications without a publisher? Glad you asked!

You can think of these types of methods as a bridge from the old to the new — a way
to Combine-ify existing APIs such as NotificationCenter.

A publisher emits two kinds of events:

1. Values, also referred to as elements.

2. A completion event.

A publisher can emit zero or more values but only one completion event, which can
either be a normal completion event or an error. Once a publisher emits a completion
event, it’s finished and can no longer emit any more events.

Before diving deeper into publishers and subscribers, you’ll first finish the example
of using traditional NotificationCenter APIs to receive a notification by
registering an observer. You’ll also unregister that observer when you’re no longer
interested in receiving that notification.

raywenderlich.com 39
Combine Chapter 2: Publishers & Subscribers

Add the following code to the end of the previous example:

// 3
let center = NotificationCenter.default

// 4
let observer = center.addObserver(
forName: myNotification,
object: nil,
queue: nil) { notification in
print("Notification received!")
}

// 5
center.post(name: myNotification, object: nil)

// 6
center.removeObserver(observer)

With this code, you:

3. Get a handle to the default notification center.

4. Create an observer to listen for the notification with the name you previously
created.

5. Post a notification with that name.

6. Remove the observer from the notification center.

Run the playground. You’ll see this output printed to the console:

——— Example of: Publisher ———

Notification received!

The example's title is a little misleading because the output is not actually coming
from a publisher. For that to happen, you need a subscriber.

Hello Subscriber
Subscriber is a protocol that defines the requirements for a type to be able to
receive input from a publisher. You’ll dive deeper into conforming to the Publisher
and Subscriber protocols shortly; for now, you’ll focus on the basic flow.

raywenderlich.com 40
Combine Chapter 2: Publishers & Subscribers

Add a new example to the playground that begins like the previous one:

example(of: "Subscriber") {
let myNotification = Notification.Name("MyNotification")

let publisher = NotificationCenter.default

.publisher(for: myNotification, object: nil)

let center = NotificationCenter.default

}

If you were to post a notification now, the publisher wouldn’t emit it — and that’s an
important distinction to remember. A publisher only emits an event when there’s at
least one subscriber.

Subscribing with sink(_:_:)

Continuing the previous example, add the following code to the example to create a
subscription to the publisher:

let subscription = publisher

.sink { _ in
print("Notification received from a publisher!")
}

With this code, you create a subscription by calling sink on the publisher — but
don’t let the obscurity of that method name give you a sinking feeling. Option-click
on sink and you’ll see that it simply provides an easy way to attach a subscriber with
closures to handle output from a publisher. In this example, you ignore those
closures and instead just print a message to indicate that a notification was received.

Run the playground and you’ll see the following:

——— Example of: Publisher ———

Notification received from a publisher!

The sink operator will continue to receive as many values as the publisher emits.
This is known as unlimited demand, which you’ll learn more about shortly. And
although you ignored them in the previous example, the sink operator actually
provides two closures: one to handle receiving a completion event, and one to handle
receiving values.

raywenderlich.com 41
Combine Chapter 2: Publishers & Subscribers

To see how this works, add this new example to your playground:

example(of: "Just") {
// 1
let just = Just("Hello world!")

// 2
_ = just
.sink(
receiveCompletion: {
print("Received completion", $0)
},
receiveValue: {
print("Received value", $0)
})
}

Here, you:

1. Create a publisher using Just, which lets you create a publisher from a primitive
value type.

2. Create a subscription to the publisher and print a message for each received
event.

Run the playground. You’ll see the following:

——— Example of: Just ———

Received value Hello world!
Received completion finished

Option-click on Just and the Quick Help explains that it’s a publisher that emits its
output to each subscriber once and then finishes.

Try adding another subscriber by adding the following code to the end of your
example:

_ = just
.sink(
receiveCompletion: {
print("Received completion (another)", $0)
},
receiveValue: {
print("Received value (another)", $0)
})

Run the playground. True to its word, a Just happily emits its output to each new
subscriber exactly once and then finishes.

raywenderlich.com 42
Combine Chapter 2: Publishers & Subscribers

Received value (another) Hello world!

Received completion (another) finished

Subscribing with assign(to:on:)

In addition to sink, the built-in assign(to:on:) operator enables you to assign the
received value to a KVO-compliant property of an object.

Add this example to see how this works:

example(of: "assign(to:on:)") {
// 1
class SomeObject {
var value: String = "" {
didSet {
print(value)
}
}
}

// 2
let object = SomeObject()

// 3
let publisher = ["Hello", "world!"].publisher

// 4
_ = publisher
.assign(to: \.value, on: object)
}

From the top:

1. Define a class with a property that has a didSet property observer that prints the
new value.

2. Create an instance of that class.

3. Create a publisher from an array of strings.

4. Subscribe to the publisher, assigning each value received to the value property of
the object.

Run the playground and you will see printed:

——— Example of: assign(to:on:) ———

Hello
world!

raywenderlich.com 43
Combine Chapter 2: Publishers & Subscribers

You’ll focus on using the sink operator for now — but fear not, you’ll get more
hands-on practice using assign beginning in Chapter 8, “In Practice: Project
"Collage".”

Hello Cancellable
When a subscriber is done and no longer wants to receive values from a publisher,
it’s a good idea to cancel the subscription to free up resources and stop any
corresponding activities from occurring, such as network calls.

Subscriptions return an instance of AnyCancellable as a "cancellation token," which

makes it possible to cancel the subscription when you’re done with it.
AnyCancellable conforms to the Cancellable protocol, which requires the
cancel() method exactly for that purpose.

Finish the Subscriber example from earlier by adding the following code:

// 1
center.post(name: myNotification, object: nil)

// 2
subscription.cancel()

With this code, you:

1. Post a notification (same as before).

2. Cancel the subscription. You’re able to call cancel() on the subscription because
the Subscription protocol inherits from Cancellable.

Run the playground. You’ll see the following:

——— Example of: Subscriber ———

Notification received from a publisher!

If you don’t explicitly call cancel() on a subscription, it will continue until the
publisher completes, or until normal memory management causes a stored
subscription to be deinitialized. At that point it will cancel the subscription for you.

raywenderlich.com 44
Combine Chapter 2: Publishers & Subscribers

Note: It’s also fine to ignore the return value from a subscription in a
playground (for example, _ = just.sink...). However, one caveat: if you
don’t store a subscription in full projects, that subscription will cancel as soon
as the program flow exits the scope in which it was created!

These are good examples to start with, but there’s a lot more going on behind the
scenes. It’s time to lift the curtain and learn more about the roles of publishers,
subscribers and subscriptions in Combine.

Understanding what’s going on

They say a picture is worth a thousand words, so let’s kick things off with one to
explain the interplay between publishers and subscribers:

Walking through this UML diagram:

1. The subscriber subscribes to the publisher.

2. The publisher creates a subscription and gives it to the subscriber.

3. The subscriber requests values.

raywenderlich.com 45
Combine Chapter 2: Publishers & Subscribers

4. The publisher sends values.

5. The publisher sends a completion.

Note: The above diagram provides a streamlined overview of what’s going on.
What you’ll learn here is enough to get you started working with Combine.
You’ll gain a deeper understanding of this process in Chapter 18, “Custom
Publishers & Handling Backpressure.”

Take a look at the Publisher protocol and one of its most crucial extensions:

public protocol Publisher {

// 1
associatedtype Output

// 2
associatedtype Failure : Error

// 4
func receive<S>(subscriber: S)
where S: Subscriber,
Self.Failure == S.Failure,
Self.Output == S.Input
}

extension Publisher {
// 3
public func subscribe<S>(_ subscriber: S)
where S : Subscriber,
Self.Failure == S.Failure,
Self.Output == S.Input
}

Here’s a closer look:

1. The type of values that the publisher can produce.

2. The type of error a publisher may produce, or Never if the publisher is

guaranteed to not produce an error.

3. A subscriber calls subscribe(_:) on a publisher to attach to it.

4. The implementation of subscribe(_:) will call receive(subscriber:) to

attach the subscriber to the publisher, i.e., create a subscription.

The associated types are the publisher’s interface that a subscriber must match in
order to create a subscription.

raywenderlich.com 46
Combine Chapter 2: Publishers & Subscribers

Now, look at the Subscriber protocol:

public protocol Subscriber: CustomCombineIdentifierConvertible {

// 1
associatedtype Input

// 2
associatedtype Failure: Error

// 3
func receive(subscription: Subscription)

// 4
func receive(_ input: Self.Input) -> Subscribers.Demand

// 5
func receive(completion: Subscribers.Completion<Self.Failure>)
}

Here’s a closer look:

1. The type of values a subscriber can receive.

2. The type of error a subscriber can receive; or Never if the subscriber won’t
receive an error.

3. The publisher calls receive(subscription:) on the subscriber to give it the

subscription.

4. The publisher calls receive(_:) on the subscriber to send it a new value that it
just published.

5. The publisher calls receive(completion:) on the subscriber to tell it that it has

finished producing values, either normally or due to an error.

The connection between the publisher and the subscriber is the subscription. Here’s
the Subscription protocol:

public protocol Subscription: Cancellable,

CustomCombineIdentifierConvertible {
func request(_ demand: Subscribers.Demand)
}

The subscriber calls request(_:) to indicate it is willing to receive more values, up

to a max number or unlimited.

Note: The concept of a subscriber stating how many values it’s willing to

raywenderlich.com 47
Combine Chapter 2: Publishers & Subscribers

receive is known as backpressure management. Without it, or some other

strategy, a subscriber could get flooded with more values from the publisher
than it can handle, and this can lead to problems. Backpressure is also covered
in depth in Chapter 18, “Custom Publishers & Handling Backpressure.”

In Subscriber, notice that receive(_:) returns a Demand. Even though the max
number of values a subscriber is willing to receive is specified when initially calling
subscription.request(_:) in receive(_:), you can adjust that max each time a
new value is received.

Note: Adjusting max in Subscriber.receive(_:) is additive, i.e., the new max

value is added to the current max. The max value must be positive, and passing
a negative value will result in a fatalError. This means that you can increase
the original max each time a new value is received, but you cannot decrease it.

Creating a custom subscriber

Time to put what you just learned to practice. Add this new example to your
playground:

example(of: "Custom Subscriber") {

// 1
let publisher = (1...6).publisher

// 2
final class IntSubscriber: Subscriber {
// 3
typealias Input = Int
typealias Failure = Never

// 4
func receive(subscription: Subscription) {
subscription.request(.max(3))
}

// 5
func receive(_ input: Int) -> Subscribers.Demand {
print("Received value", input)
return .none
}

// 6

raywenderlich.com 48
Combine Chapter 2: Publishers & Subscribers

func receive(completion: Subscribers.Completion<Never>) {

print("Received completion", completion)
}
}
}

What you do here is:

1. Create a publisher of integers via the range’s publisher property.

2. Define a custom subscriber, IntSubscriber.

3. Implement the type aliases to specify that this subscriber can receive integer
inputs and will never receive errors.

4. Implement the required methods, beginning with receive(subscription:),

which is called by the publisher; and in that method, call .request(_:) on the
subscription specifying that the subscriber is willing to receive up to three values
upon subscription.

5. Print each value as it’s received and return .none, indicating that the subscriber
will not adjust its demand; .none is equivalent to .max(0).

6. Print the completion event.

For the publisher to publish anything, it needs a subscriber. Add the following at the
end of the example:

let subscriber = IntSubscriber()

publisher.subscribe(subscriber)

In this code, you create a subscriber that matches the Output and Failure types of
the publisher. You then tell the publisher to subscribe, or attach, the subscriber.

Run the playground. You’ll see the following printed to the console:

——— Example of: Custom Subscriber ———

Received value 1
Received value 2
Received value 3

You did not receive a completion event. This is because the publisher has a finite
number of values, and you specified a demand of .max(3).

In your custom subscriber’s receive(_:), try changing .none to .unlimited, so

your receive(_:) method looks like this:

raywenderlich.com 49
Combine Chapter 2: Publishers & Subscribers

func receive(_ input: Int) -> Subscribers.Demand {

print("Received value", input)
return .unlimited
}

Run the playground again. This time you’ll see that all of the values are received and
printed, along with the completion event:

——— Example of: Custom Subscriber ———

Received value 1
Received value 2
Received value 3
Received value 4
Received value 5
Received value 6
Received completion finished

Try changing .unlimited to .max(1) and run the playground again.

You’ll see the same output as when you returned .unlimited, because each time you
receive an event, you specify that you want to increase the max by 1.

Change .max(1) back to .none, and change the definition of publisher to an array
of strings instead. Replace:

let publisher = (1...6).publisher

With:

let publisher = ["A", "B", "C", "D", "E", "F"].publisher

Run the playground. You get an error that the subscribe method requires types
String and IntSubscriber.Input (i.e., Int) to be equivalent. You get this error
because the Output and Failure associated types of a publisher must match the
Input and Failure types of a subscriber in order for a subscription between the two
to be created.

Change the publisher definition back to its original range of integers to resolve the
error.

raywenderlich.com 50
Combine Chapter 2: Publishers & Subscribers

Hello Future
Much like you can use Just to create a publisher that emits a single value to a
subscriber and then complete, a Future can be used to asynchronously produce a
single result and then complete. Add this new example to your playground:

example(of: "Future") {
func futureIncrement(
integer: Int,
afterDelay delay: TimeInterval) -> Future<Int, Never> {

}
}

Here, you create a factory function that returns a future of type Int and Never;
meaning, it will emit an integer and never fail.

You also add a subscriptions set in which you’ll store the subscriptions to the
future in the example. For long-running asynchronous operations, not storing the
subscription will result in the cancelation of the subscription as soon as the current
code scope ends. In the case of a Playground, that would be immediately.

Next, fill the function’s body to create the future:

Future<Int, Never> { promise in

DispatchQueue.global().asyncAfter(deadline: .now() + delay) {
promise(.success(integer + 1))
}
}

This code defines the future, which creates a promise that you then execute using the
values specified by the caller of the function to increment the integer after the
delay.

A Future is a publisher that will eventually produce a single value and finish, or it
will fail. It does this by invoking a closure when a value or error is made available,
and that closure is referred to as a promise. Command-click on Future and choose
Jump to Definition. You’ll see the following:

final public class Future<Output, Failure> : Publisher

where Failure: Error {
public typealias Promise = (Result<Output, Failure>) -> Void
...
}

raywenderlich.com 51
Combine Chapter 2: Publishers & Subscribers

Promise is a type alias to a closure that receives a Result containing either a single
value published by the Future, or an error.

Head back to the main playground page, and add the following code after the
definition of futureIncrement:

// 1
let future = futureIncrement(integer: 1, afterDelay: 3)

// 2
future
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

Here, you:

1. Create a future using the factory function you created earlier, specifying to
increment the integer you passed after a three-second delay.

2. Subscribe to and print the received value and completion event, and store the
resulting subscription in the subscriptions set. You’ll learn more about storing
subscriptions in a collection later in this chapter, so don’t worry if you don’t
entirely understand that portion of the example.

Run the playground. You’ll see the example title printed, followed by the output of
the future after a three-second delay:

——— Example of: Future ———

2
finished

Add a second subscription to the future by entering the following code in the
playground:

future
.sink(receiveCompletion: { print("Second", $0) },
receiveValue: { print("Second", $0) })
.store(in: &subscriptions)

Before running the playground, insert the following print statement immediately
before the DispatchQueue block in the futureIncrement function:

print("Original")

raywenderlich.com 52
Combine Chapter 2: Publishers & Subscribers

Run the playground. After the specified delay, the second subscription receives the
same value. The future does not re-execute its promise; instead, it shares or replays
its output.

——— Example of: Future ———

Original
2
finished
Second 2
Second finished

Also, Original is printed right away before the subscriptions occur. This happens
because a future executes as soon as it is created. It does not require a subscriber like
regular publishers.

In the last few examples, you’ve been working with publishers that have a finite
number of values to publish, which are sequentially and synchronously published.

The notification center example you started with is an example of a publisher that
can keep on publishing values indefinitely and asynchronously, provided:

1. The underlying notification sender emits notifications.

2. There are subscribers to the specified notification.

What if there was a way that you could do the same thing in your own code? Well, it
turns out, there is! Before moving on, comment out the entire "Future" example, so
the future isn’t invoked every time you run the playground — otherwise its delayed
output will be printed after the last example.

Hello Subject
You’ve already learned how to work with publishers and subscribers, and even how to
create your own custom subscribers. Later in the book, you’ll learn how to create
custom publishers. For now, though, there’s just a couple more things standing
between you and a well-deserved <insert your favorite beverage> break. First
is a subject.

A subject acts as a go-between to enable non-Combine imperative code to send

values to Combine subscribers. That <favorite beverage> isn’t going to drink
itself, so it’s time to get to work!

raywenderlich.com 53
Combine Chapter 2: Publishers & Subscribers

Add this new example to your playground:

example(of: "PassthroughSubject") {
// 1
enum MyError: Error {
case test
}

// 2
final class StringSubscriber: Subscriber {
typealias Input = String
typealias Failure = MyError

func receive(subscription: Subscription) {

subscription.request(.max(2))
}

func receive(_ input: String) -> Subscribers.Demand {

print("Received value", input)
// 3
return input == "World" ? .max(1) : .none
}

func receive(completion: Subscribers.Completion<MyError>) {

print("Received completion", completion)
}
}

// 4
let subscriber = StringSubscriber()
}

With this code, you:

1. Define a custom error type.

2. Define a custom subscriber that receives strings and MyError errors.

3. Adjust the demand based on the received value.

4. Create an instance of the custom subscriber.

Returning .max(1) in receive(_:) when the input is "World" results in the new
max being set to 3 (the original max plus 1).

Other than defining a custom error type and pivoting on the received value to adjust
demand, there’s nothing new here. Here comes the more interesting part.

raywenderlich.com 54
Combine Chapter 2: Publishers & Subscribers

Add this code to the example:

// 5
let subject = PassthroughSubject<String, MyError>()

// 6
subject.subscribe(subscriber)

// 7
let subscription = subject
.sink(
receiveCompletion: { completion in
print("Received completion (sink)", completion)
},
receiveValue: { value in
print("Received value (sink)", value)
}
)

This code:

5. Creates an instance of a PassthroughSubject of type String and the custom

error type you defined.

6. Subscribes the subscriber to the subject.

7. Creates another subscription using sink.

Passthrough subjects enable you to publish new values on demand. They will happily
pass along those values and a completion event. As with any publisher, you must
declare the type of values and errors it can emit in advance; subscribers must match
those types to its input and failure types in order to subscribe to that passthrough
subject.

Now that you’ve created a passthrough subject that can send values and
subscriptions to receive them, it’s time to send some values. Add the following code
to your example:

subject.send("Hello")
subject.send("World")

This sends two values (one at a time) using the subject’s send method.

raywenderlich.com 55
Combine Chapter 2: Publishers & Subscribers

Run the playground. You’ll see:

——— Example of: PassthroughSubject ———

Received value Hello
Received value (sink) Hello
Received value World
Received value (sink) World

Each subscriber receives the values as they’re published.

Add the following code:

// 8
subscription.cancel()

// 9
subject.send("Still there?")

Here, you:

8. Cancel the second subscription.

9. Send another value.

Run the playground. As you might have expected, only the first subscriber receives
the value. This happens because you previously canceled the second subscriber’s
subscription:

——— Example of: PassthroughSubject ———

Received value Hello
Received value (sink) Hello
Received value World
Received value (sink) World
Received value Still there?

Add this code to the example:

subject.send(completion: .finished)
subject.send("How about another one?")

Run the playground. The second subscriber does not receive the "How about
another one?" value, because it received the completion event right before that
value was sent. The first subscriber does not receive the completion event or the
value, because its subscription was previously canceled.

——— Example of: PassthroughSubject ———

Received value Hello
Received value (sink) Hello

raywenderlich.com 56
Combine Chapter 2: Publishers & Subscribers

Received value World

Received value (sink) World
Received value Still there?
Received completion finished

Add the following code immediately before the line that sends the completion event.

subject.send(completion: .failure(MyError.test))

Run the playground, again. You’ll see the following printed to the console:

——— Example of: PassthroughSubject ———

Received value Hello
Received value (sink) Hello
Received value World
Received value (sink) World
Received value Still there?
Received completion failure(...MyError.test)

Note: The error type is abbreviated.

The error is received by the first subscriber, but the completion event that was sent
after the error is not. This demonstrates that once a publisher sends a single
completion event — whether it’s a normal completion or an error — it’s done, as in
fini, kaput! Passing through values with a PassthroughSubject is one way to bridge
imperative code to the declarative world of Combine. Sometimes, however, you may
also want to look at the current value of a publisher in your imperative code — for
that, you have an aptly named subject: CurrentValueSubject.

Instead of storing each subscription as a value, you can store multiple subscriptions
in a collection of AnyCancellable. The collection will then automatically cancel
each subscription added to it when the collection is about to be deinitialized.

Add this new example to your playground:

example(of: "CurrentValueSubject") {
// 1
let subject = CurrentValueSubject<Int, Never>(0)

// 2
subject
.sink(receiveValue: { print($0) })
.store(in: &subscriptions) // 3
}

raywenderlich.com 57
Combine Chapter 2: Publishers & Subscribers

Here’s what’s happening:

1. Create a CurrentValueSubject of type Int and Never. This will publish integers
and never publish an error, with an initial value of 0.

2. Create a subscription to the subject and print values received from it.

3. Store the subscription in the subscriptions set, which is passed as an inout

parameter so that the same set is updated instead of a copy.

You must initialize current value subjects with an initial value; new subscribers
immediately get that value or the latest value published by that subject. Run the
playground to see this in action:

——— Example of: CurrentValueSubject ———

0

Now, add this code to send two new values:

subject.send(1)
subject.send(2)

Run the playground again. Those values are also received and printed to the console:

1
2

Unlike a passthrough subject, you can ask a current value subject for its value at any
time. Add the following code to print out the subject’s current value:

print(subject.value)

As you might have inferred by the subject’s type name, you can get its current value
by accessing its value property. Run the playground, and you’ll see 2 printed a
second time.

Calling send(_:) on a current value subject is one way to send a new value. Another
way is to assign a new value to its value property. Whoah, did we just go all
imperative here or what? Add this code:

subject.value = 3
print(subject.value)

Run the playground. You’ll see 2 and 3 each printed twice — once by the receiving
subscriber and once from printing the subject’s value after adding that value to the
subject.

raywenderlich.com 58
Combine Chapter 2: Publishers & Subscribers

Next, at the end of this example, create a new subscription to the current value
subject:

subject
.sink(receiveValue: { print("Second subscription:", $0) })
.store(in: &subscriptions)

Here, you create a subscription and print the received values. You also store that
subscription in the subscriptions set.

You read a moment ago that the subscriptions set will automatically cancel the
subscriptions added to it, but how can you verify this? You can use the print()
operator, which will log all publishing events to the console.

Insert the print() operator in both subscriptions, between subject and sink. The
beginning of each subscription should look like this:

subject
.print()
.sink...

Run the playground again and you’ll see the following output for the entire example:

——— Example of: CurrentValueSubject ———

receive subscription: (CurrentValueSubject)
request unlimited
receive value: (0)
0
receive value: (1)
1
receive value: (2)
2
2
receive value: (3)
3
3
receive subscription: (CurrentValueSubject)
request unlimited
receive value: (3)
Second subscription: 3
receive cancel
receive cancel

Each event is printed, along with the values printed in the subscription handlers, and
when you printed the subject’s values.

raywenderlich.com 59
Combine Chapter 2: Publishers & Subscribers

So, you may be wondering, can you also assign a completion event to the value
property? Try it out by adding this code:

subject.value = .finished

Nope! That produces an error. A CurrentValueSubject’s value property is meant

for just that: values. Completion events must still be sent using send(_:). Change
the erroneous line of code to the following:

subject.send(completion: .finished)

Run the playground again. This time you’ll see the following output at the bottom:

receive finished
receive finished

Both subscriptions receive the completion event instead of the cancel event. They are
finished and no longer need to be canceled.

Dynamically adjusting demand

You learned earlier that adjusting demand in Subscriber.receive(_:) is additive.
You’re now ready to take a closer look at how that works in a more elaborate
example. Add this new example to the playground:

example(of: "Dynamically adjusting Demand") {

final class IntSubscriber: Subscriber {
typealias Input = Int
typealias Failure = Never

func receive(subscription: Subscription) {

subscription.request(.max(2))
}

func receive(_ input: Int) -> Subscribers.Demand {

print("Received value", input)

switch input {
case 1:
return .max(2) // 1
case 3:
return .max(1) // 2
default:
return .none // 3
}
}

raywenderlich.com 60
Combine Chapter 2: Publishers & Subscribers

func receive(completion: Subscribers.Completion<Never>) {

print("Received completion", completion)
}
}

let subscriber = IntSubscriber()

let subject = PassthroughSubject<Int, Never>()

subject.subscribe(subscriber)

subject.send(1)
subject.send(2)
subject.send(3)
subject.send(4)
subject.send(5)
subject.send(6)
}

Most of this code is similar to example you’ve previously worked on in this chapter,
so instead you’ll focus on the receive(_:) method. You continually adjust the
demand from within your custom subscriber:

1. The new max is 4 (original max of 2 + new max of 2).

2. The new max is 5 (previous 4 + new 1).

3. max remains 5 (previous 4 + new 0).

Run the playground and you’ll see the following:

——— Example of: Dynamically adjusting Demand ———

Received value 1
Received value 2
Received value 3
Received value 4
Received value 5

As expected, five values are emitted but the sixth is not printed out.

There is one more important thing you’ll want to know about before moving on:
hiding details about a publisher from subscribers.

Type erasure
There will be times when you want to let subscribers subscribe to receive events from

raywenderlich.com 61
Combine Chapter 2: Publishers & Subscribers

a publisher without being able to access additional details about that publisher.

This would be best demonstrated with an example, so add this new one to your
playground:

example(of: "Type erasure") {

// 1
let subject = PassthroughSubject<Int, Never>()

// 2
let publisher = subject.eraseToAnyPublisher()

// 3
publisher
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

// 4
subject.send(0)
}

With this code you:

1. Create a passthrough subject.

2. Create a type-erased publisher from that subject.

3. Subscribe to the type-erased publisher.

4. Send a new value through the passthrough subject.

Option-click on publisher and you’ll see that it is of type AnyPublisher<Int,

Never>.

AnyPublisher is a type-erased struct that conforms the Publisher protocol. Type

erasure allows you to hide details about the publisher that you may not want to
expose to subscribers — or downstream publishers, which you’ll learn about in the
next section.

Are you are experiencing a little déjà vu right now? If so, that’s because you saw
another case of type erasure earlier. AnyCancellable is a type-erased class that
conforms to Cancellable, which lets callers cancel the subscription without being
able to access the underlying subscription to do things like request more items.

One example of when you would want to use type erasure for a publisher is when you
want to use a pair of public and private properties, to allow the owner of those
properties to send values on the private publisher, and let outside callers only access
the public publisher for subscribing but not be able to send values.

raywenderlich.com 62
Combine Chapter 2: Publishers & Subscribers

AnyPublisher does not have a send(_:) operator, so new values cannot be added to
that publisher.

The eraseToAnyPublisher() operator wraps the provided publisher in an instance

of AnyPublisher, hiding the fact that the publisher is actually a
PassthroughSubject. This is also necessary because you cannot specialize the
Publisher protocol, e.g., you cannot define the type as Publisher<UIImage,
Never>.

To prove that publisher is type-erased and cannot be used to send new values, add
this code to the example.

publisher.send(1)

You get the error Value of type 'AnyPublisher<Int, Never>' has no member
'send'. Comment out that line of code before moving on.

Fantastic job! You’ve learned a lot in this chapter, and you’ll put these new skills to
work throughout the rest of this book and beyond. But not so fast! It’s time to
practice what you just learned. So, grab yourself a <insert your favorite
beverage> to enjoy while you work through the challenges for this chapter.

Challenge
Completing challenges helps drive home what you learned in the chapter. There are
starter and final versions of the challenge in the exercise files download.

Challenge: Create a Blackjack card dealer

Open Starter.playground in the challenge folder, and twist down the playground
page and Sources in the Project navigator. Select SupportCode.swift.

Review the helper code for this challenge, including

• A cards array that contains 52 tuples representing a standard deck of cards.

• Two type aliases: Card is a tuple of String and Int, and Hand is an array of Cards.

• Two helper properties on Hand: cardString and points.

• A HandError error enumeration.

raywenderlich.com 63
Combine Chapter 2: Publishers & Subscribers

In the main playground page, add code immediately below the comment // Add
code to update dealtHand here that evaluates the result returned from the
hand’s points property. If the result is greater than 21, send the HandError.busted
through the dealtHand subject. Otherwise, send the hand value.

Also in the main playground page, add code immediately after the comment // Add
subscription to dealtHand here to subscribe to dealtHand and handle receiving
both values and an error.

For received values, print a string containing the results of the hand’s cardString
and points properties.

For an error, print it out. A tip though: You can receive either a .finished or
a .failure in the receivedCompletion block, so you’ll want to distinguish whether
that completion is a failure or not, and only print failures.

HandError conforms to CustomStringConvertible so printing it will result in a

user-friendly error message. You can use it like this:

if case let .failure(error) = $0 {

print(error)
}

The call to deal(_:) currently passes 3, so three cards are dealt each time you run
the playground. See how many times you go bust versus how many times you stay in
the game. Are the odds stacked up against you in Vegas or what?

The card emoji characters are small when printed in the console. You can
temporarily increase the font size of the Executable Console Output for this
challenge. To do so, select Xcode ▸ Preferences... ▸ Fonts & Colors/Console. Then,
select Executable Console Output, and click the T button in the bottom right to
change it to a larger font, such as 48.

raywenderlich.com 64
Combine Chapter 2: Publishers & Subscribers

Solution
How’d you do?

There were two things you needed to add to complete this challenge. The first was to
update the dealtHand publisher in the deal function, checking the hand’s points
and sending an error if it’s over 21:

// Add code to update dealtHand here

if hand.points > 21 {
dealtHand.send(completion: .failure(.busted))
} else {
dealtHand.send(hand)
}

Next, you needed to subscribe to dealtHand and print out the value received or the
completion event if it was an error:

_ = dealtHand
.sink(receiveCompletion: {
if case let .failure(error) = $0 {
print(error)

raywenderlich.com 65
Combine Chapter 2: Publishers & Subscribers

}
}, receiveValue: { hand in
print(hand.cardString, "for", hand.points, "points")
})

Each time you run the playground, you’ll get a new hand and output similar to the
following:

——— Example of: Create a Blackjack card dealer ———

!"# for 21 points

Blackjack!

Key points
• Publishers transmit a sequence of values over time to one or more subscribers,
either synchronously or asynchronously.

• A subscriber can subscribe to a publisher to receive values; however, the

subscriber’s input and failure types must match the publisher’s output and failure
types.

• There are two built-in operators you can use to subscribe to publishers:
sink(_:_:) and assign(to:on:).

• A subscriber may increase the demand for values each time it receives a value, but
it cannot decrease demand.

• To free up resources and prevent unwanted side effects, cancel each subscription
when you’re done.

• You can also store a subscription in an instance or collection of AnyCancellable

to receive automatic cancelation upon deinitialization.

• A future can be used to receive a single value asynchronously at a later time.

• Subjects are publishers that enable outside callers to send multiple values
asynchronously to subscribers, with or without a starting value.

• Type erasure prevents callers from being able to access additional details of the
underlying type.

• Use the print() operator to log all publishing events to the console and see
what’s going on.

raywenderlich.com 66
Combine Chapter 2: Publishers & Subscribers

Where to go from here?

Congratulations! You’ve taken a huge step forward by completing this chapter. You
learned how to work with publishers to send values and completion events, and how
to use subscribers to receive those values and events. Up next, you’ll learn how to
manipulate the values coming from a publisher to help filter, transform or combine
them.

raywenderlich.com 67
Section II: Operators

If you think of Combine as a language, such as the English language, operators are its
words. The more operators you know, the better you can articulate your intention
and the logic of your app. Operators are a huge part of the Combine ecosystem which
lets you manipulate values emitted from upstream publishers in meaningful and
logical ways.

In this section, you'll learn the majority of operators Combine has to offer, divided
into useful groups: transforming, filtering, combining, time manipulation and
sequence. Once you've got your operator chops down, you'll wrap up this section
with a hands-on project to practice your newly-acquired knowledge.

Specifically, you'll cover:

Chapter 3: Transforming Operators: Before a subscriber receives values from a

publisher, you’ll often want to manipulate those values in some way. One of the most
common things you’ll want to do is transform those values into some form that is
ideal for use by the subscriber. By the end of this chapter you’ll be transforming all
the things.

Chapter 4: Filtering Operators: In this chapter, you'll learn about filtering values
from Combine publishers, so you can easily control the values published by the
upstream and only deal with the ones you care about.

Chapter 5: Combining Operators: Publishers are extremely powerful, but they're

even more powerful when composed together! This chapter will teach you about
Combine's combining operators which let you take multiple publishers and create
meaningful logical relationships between them.

raywenderlich.com 68
Combine Section II: Operators

Chapter 6: Time Manipulation Operators: A large part of asynchronous

programming relates to processing values over time. This chapter goes into the
details of performing complex time-based tasks that would be hard to do without
Combine.

Chapter 7: Sequence Operators: When you think about it, publishers are merely
sequences. As such, there are many useful operators that let you target specific
values, or gather information about the sequence as a whole, which you'll learn
about in this chapter.

Chapter 8: In Practice: Project "Collage": It's time to try your new Combine skills
in a real project and learn how to make Foundation and UIKit play along with your
reactive code.

raywenderlich.com 69
3 Chapter 3: Transforming
Operators
By Scott Gardner

Having completed section 1, you’ve already learned a lot. You should feel pretty good
about that accomplishment! You’ve laid a solid foundation on the fundamentals of
Combine, and now you’re ready to build upon it.

In this chapter, you’re going to learn about one of the essential categories of
operators in Combine: Transforming operators. You’ll use transforming operators all
the time, to manipulate values coming from publishers into a format that is usable
for your subscribers. As you’ll see, there are parallels between transforming
operators in Combine and regular operators in the Swift standard library, such as map
and flatMap.

By the end of this chapter, you’ll be transforming all the things!

Getting started
Open the starter playground for this chapter, which already has Combine imported
and is ready to go.

Operators are publishers

In Combine, methods that perform an operation on values coming from a publisher
are called operators.

Each Combine operator actually returns a publisher. Generally speaking, that

publisher receives the upstream values, manipulates the data, and then sends that
data downstream. To streamline things conceptually, the focus will be on using the

raywenderlich.com 70
Combine Chapter 3: Transforming Operators

operator and working with its output. Unless an operator’s purpose is to handle
errors, if it receives an error from an upstream publisher, it will just publish that
error downstream.

Note: You’ll focus on transforming operators in this chapter, so error handling

will not appear in each operator example. You’ll learn all about error handling
in Chapter 16, “Error Handling.”

Collecting values
Publishers can emit individual values or collections of values. You’ll frequently want
to work with collections, such as when you want to populate a list of views. You’ll
learn how to do this later in the book.

collect()
The collect operator provides a convenient way to transform a stream of individual
values from a publisher into an array of those values. To help understand how this
and all other operators you’ll learn about in this book, you’ll use marble diagrams.

Marble diagrams help to visualize how operators work. The top line is the upstream
publisher. The box represents the operator. And the bottom line is the subscriber, or
more specifically, what the subscriber will receive after the operator manipulates the
values coming from the upstream publisher. The bottom line could also be another
operator that receives the output from the upstream publisher, performs its
operation, and sends those values downstream.

raywenderlich.com 71
Combine Chapter 3: Transforming Operators

As depicted in this marble diagram, collect will buffer a stream of individual values
into an array of those values once the upstream publisher completes. It will then
emit that array downstream.

Add this new example to your playground:

example(of: "collect") {
["A", "B", "C", "D", "E"].publisher
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

This is not using the collect operator yet. Run the playground, and you’ll see each
value is emitted and printed individually followed by the completion:

——— Example of: collect ———

A
B
C
D
E
finished

Now insert the use of collect before the sink. Your code should look like this:

["A", "B", "C", "D", "E"].publisher

.collect()
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

Run the playground, and now the sink receives one emitted collection followed by
the completion event:

——— Example of: collect ———

["A", "B", "C", "D", "E"]
finished

Note: Be careful when working with collect() and other buffering operators
that do not require specifying a count or limit. They will use an unbounded
amount of memory to store received values.

There are a few variations of the collect operator. For example, you can specify that
you only want to receive up to a certain number of values.

raywenderlich.com 72
Combine Chapter 3: Transforming Operators

Replace the following line:

.collect()

With:

.collect(2)

Run the playground, and you’ll see the following output:

——— Example of: collect ———

["A", "B"]
["C", "D"]
["E"]
finished

The last value, E, is emitted as an array. That’s because the upstream publisher
completed before collect filled its prescribed buffer, so it sent whatever it had left
as an array.

Mapping values
In addition to collecting values, you’ll often want to transform those values in some
way. Combine offers several mapping operators for that purpose.

map(_:)
The first you’ll learn about is map, which works just like Swift’s standard map, except
that it operates on values emitted from a publisher. In the marble diagram, map takes
a closure that multiplies each value by 2.

raywenderlich.com 73
Combine Chapter 3: Transforming Operators

Add this new example to your playground:

example(of: "map") {
// 1
let formatter = NumberFormatter()
formatter.numberStyle = .spellOut

// 2
[123, 4, 56].publisher
// 3
.map {
formatter.string(for: NSNumber(integerLiteral: $0)) ?? ""
}
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

Here’s the play-by-play:

1. Create a number formatter to spell out each number.

2. Create a publisher of integers.

3. Use map, passing a closure that gets upstream values and returns the result of
using the formatter to return the number’s spelled out string.

Run the playground, and you will see this output:

——— Example of: map ———

one hundred twenty-three
four
fifty-six

raywenderlich.com 74
Combine Chapter 3: Transforming Operators

Map key paths

The map family of operators also includes three versions that can map into one, two,
or three properties of a value using key paths. Their signatures are as follows:

• map<T>(_:)
• map<T0, T1>(_:_:)
• map<T0, T1, T2>(_:_:_:)
The T represents the type of values found at the given key paths.

In the next example, you’ll use the Coordinate type and quadrantOf(x:y:)
method defined in Sources/SupportCode.swift. Coordinate has two properties: x
and y. quadrantOf(x:y:) takes x and y values as parameters and returns a string
indicating the quadrant for the x and y values.

Note: Quadrants are part of coordinate geometry. For more information you
can visit mathworld.wolfram.com/Quadrant.html.

Feel free to review these definitions if you’re interested, and then add the following
example to your playground:

Add this example to see how you’d use map(_:_:) to map into two key paths:

example(of: "map key paths") {

// 1
let publisher = PassthroughSubject<Coordinate, Never>()

// 2
publisher
// 3
.map(\.x, \.y)
.sink(receiveValue: { x, y in
// 4
print(
"The coordinate at (\(x), \(y)) is in quadrant",
quadrantOf(x: x, y: y)
)
})
.store(in: &subscriptions)

// 5
publisher.send(Coordinate(x: 10, y: -8))
publisher.send(Coordinate(x: 0, y: 5))
}

raywenderlich.com 75
Combine Chapter 3: Transforming Operators

In this example you’re using the version of map that maps into two properties via key
paths.

Step-by-step, you:

1. Create a publisher of Coordinates that will never emit an error.

2. Begin a subscription to the publisher.

3. Map into the x and y properties of Coordinate using their key paths.

4. Print a statement that indicates the quadrant of the provide x and y values.

5. Send some coordinates through the publisher.

Run the playground and the output from this subscription will be the following:

——— Example of: map key paths ———

The coordinate at (10, -8) is in quadrant 4
The coordinate at (0, 5) is in quadrant boundary

tryMap(_:)
Several operators, including map, have a counterpart try operator that will take a
closure that can throw an error. If you throw an error, it will emit that error
downstream. Add this example to the playground:

example(of: "tryMap") {
// 1
Just("Directory name that does not exist")
// 2
.tryMap { try
FileManager.default.contentsOfDirectory(atPath: $0) }
// 3
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

Here’s what you just did, or at least tried to do!

1. Create a publisher of a string representing a directory name that does not exist.

2. Use tryMap to attempt to get the contents of that nonexistent directory.

3. Receive and print out any values or completion events.

Notice that you still need to use the try keyword when calling a throwing method.

raywenderlich.com 76
Combine Chapter 3: Transforming Operators

Run the playground and observe that tryMap outputs a failure completion event with
the appropriate “folder doesn’t exist” error (output abbreviated):

——— Example of: tryMap ———

failure(..."The folder “Directory name that does not exist”
doesn't exist."...)

Flattening publishers
This section’s title might not shed any light on what you’re about to learn, unless
you have some prior experience with reactive programming. However, by the end of
this section, everything will be illuminated for you.

flatMap(maxPublishers:_:)
The flatMap operator can be used to flatten multiple upstream publishers into a
single downstream publisher — or more specifically, flatten the emissions from those
publishers.

The publisher returned by flatMap does not — and often will not — be of the same
type as the upstream publishers it receives. Before exploring how flatMap can
flatten multiple publisher inputs, you’ll focus on what flatMap outputs.

A common use case for flatMap in Combine is when you want to subscribe to
properties of values emitted by a publisher that are themselves publishers.

Time to implement an example to see this in action. Start by taking a look at the
code in Sources/SupportCode.swift. It includes the definition of a Chatter
structure with two properties:

1. name is a regular string.

2. message is a CurrentValueSubject subject that is initialized with the message

string passed in.

public struct Chatter {

public let name: String
public let message: CurrentValueSubject<String, Never>

public init(name: String, message: String) {

self.name = name
self.message = CurrentValueSubject(message)
}
}

raywenderlich.com 77
Combine Chapter 3: Transforming Operators

Switch back to the main playground page and add this new example:

example(of: "flatMap") {
// 1
let charlotte = Chatter(name: "Charlotte", message: "Hi, I'm
Charlotte!")
let james = Chatter(name: "James", message: "Hi, I'm James!")

// 2
let chat = CurrentValueSubject<Chatter, Never>(charlotte)

// 3
chat
.sink(receiveValue: { print($0.message.value) })
.store(in: &subscriptions)
}

From the top, you:

1. Create two instances of Chatter: charlotte and james.

2. Create a chat publisher initialized with charlotte.

3. Subscribe to chat and print out the message of any received Chatter structure.

Run the playground, and as you might expect, Charlotte’s message is printed out:

——— Example of: flatMap ———

Charlotte wrote: Hi, I'm Charlotte!

Now add this code to the example:

// 4
charlotte.message.value = "Charlotte: How's it going?"

// 5
chat.value = james

With this code you:

4. Change Charlotte’s message.

5. Change the chat publisher’s current value to james.

Run the playground again, and you’ll see the following:

Charlotte wrote: Hi, I'm Charlotte!

James wrote: Hi, I'm James!

raywenderlich.com 78
Combine Chapter 3: Transforming Operators

You don’t see Charlotte’s new message, but you do see James’ initial message. That’s
because you’re subscribed to chat, which is a Chatter publisher. You are not
subscribed to the message publisher property of each emitted Chatter. What if you
wanted to subscribe to the message of every chat? You can use flatMap.

Find the following code:

chat
.sink(receiveValue: { print($0.message.value) })
.store(in: &subscriptions)

And replace it with:

chat
// 6
.flatMap { $0.message }
// 7
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

Here you:

6. Flat map into the Chatter structure message publisher.

7. Change the handler to print the value received, which is now a string, not a
Chatter instance.

Run the playground again, and now you’ll see Charlotte’s new message printed.

Hi, I'm Charlotte!

Charlotte: How's it going?
Hi, I'm James!

Now add the following code to the example, which changes each Chatter’s message
value:

james.message.value = "James: Doing great. You?"

charlotte.message.value = "Charlotte: I'm doing fine thanks."

Run the playground, and you may be surprised by what you see:

James: Doing great. You?

Charlotte: I'm doing fine thanks.

Charlotte’s new message was printed, even though you changed chat’s value to
james. Herein lies the “flatten” part — huzzah!

raywenderlich.com 79
Combine Chapter 3: Transforming Operators

Recall the definition from earlier: flatMap flattens the output from all received
publishers into a single publisher. This poses a memory concern, because it will
buffer as many publishers as you send it to update the single publisher it emits
downstream.

To help you manage flatMap’s memory footprint, you can optionally specify how
many publishers flatMap will receive and buffer using its maxPublishers
parameter.

Find the following line:

.flatMap { $0.message }

And replace it with:

.flatMap(maxPublishers: .max(2)) { $0.message }

You specify that flatMap will receive a maximum of two upstream publishers. It will
ignore any additional publishers. If not specified, maxPublishers defaults
to .unlimited.

Now that you have a better understanding of how to use flatMap, its marble diagram
will be easier to understand and help you visualize what’s going on:

In the diagram, flatMap receives three publishers: P1, P2, and P3. Each of these
publishers has a value property that is also a publisher. flatMap emits the value
publishers’ values from P1 and P2, but ignores P3 because maxPublishers is set to 2.

raywenderlich.com 80
Combine Chapter 3: Transforming Operators

Back to the example. You previously set flatMap’s maxPublishers parameter to two.
Now add the following code to the bottom of the example to see how this affects the
output:

// 8
let morgan = Chatter(name: "Morgan",
message: "Hey guys, what are you up to?")

// 9
chat.value = morgan

// 10
charlotte.message.value = "Did you hear something?"

What you did here is:

8. Create a third Chatter instance.

9. Add that Chatter onto the chat publisher.

10. Change Charlotte’s message.

What do you think will be printed out? Run the playground and see if you were right:

——— Example of: flatMap ———

Hi, I'm Charlotte!
Charlotte: How's it going?
Hi, I'm James!
James: Doing great. You?
Charlotte: I'm doing fine thanks.
Did you hear something?

Morgan’s message is not printed, because flatMap will only receive up to a max of
two publishers.

You now have a handle on one of the most powerful operators in Combine. However,
flatMap is not the only way to swap input with a different output. So, before
wrapping up this chapter, you’ll learn a couple more useful operating for doing the
ol’ switcheroo.

Replacing upstream output

Earlier in the map example, you worked with Foundation’s
Formatter.string(for:) method. It produces an optional string, and you used the
nil-coalescing operator (??) to replace a nil value with a non-nil value. Combine
also includes an operator that you can use when you want to always deliver a value.

raywenderlich.com 81
Combine Chapter 3: Transforming Operators

replaceNil(with:)
As depicted in the following marble diagram, replaceNil will receive optional
values and replace nils with the value you specify:

Add this new example to your playground:

example(of: "replaceNil") {
// 1
["A", nil, "C"].publisher
.replaceNil(with: "-") // 2
.sink(receiveValue: { print($0) }) // 3
.store(in: &subscriptions)
}

What you just did:

1. Create a publisher from an array of optional strings.

2. Use replaceNil(with:) to replace nil values received from the upstream

publisher with a new non-nil value.

3. Print out the value.

Run the playground, and you will see the following:

——— Example of: replaceNil ———

Optional("A")
Optional("-")
Optional("C")

raywenderlich.com 82
Combine Chapter 3: Transforming Operators

The optional values were not converted to non-optional ones. True to its name,
replaceNil(with:) replaced a nil with a non-nil value. One way that you could
convert the output from replaceNil to a non-optional value is by inserting the use
of map to force-unwrap it. Do so by changing your code to the following:

["A", nil, "C"].publisher

.replaceNil(with: "-")
.map { $0! }
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

Now, run the playground, and you’ll see each unwrapped value printed instead:

A
-
C

There is a subtle but important difference between using ?? and replaceNil. The ??
operator can return another optional, while replaceNil cannot. Change the usage of
replaceNil to the following, and you will get an error that the optional must be
unwrapped:

.replaceNil(with: "-" as String?)

Revert that change before moving on. This example also demonstrates how you can
chain together multiple operators in a compositional way. This allows you to
manipulate the values coming from the origin publisher to the subscriber in a wide
variety of ways.

replaceEmpty(with:)
You can use the replaceEmpty(with:) operator to replace — or really, insert — a
value if a publisher completes without emitting a value.

In the following marble diagram, the publisher completes without emitting anything,
and at that point the replaceEmpty(with:) operator inserts a value and publishes it
downstream:

raywenderlich.com 83
Combine Chapter 3: Transforming Operators

Add this new example to see it in action:

example(of: "replaceEmpty(with:)") {
// 1
let empty = Empty<Int, Never>()

// 2
empty
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

What you’re doing here:

1. Create an empty publisher that immediately emits a completion event.

2. Subscribe to it, and print received events.

The Empty publisher type can be used to create a publisher that immediately emits
a .finished completion event. It can also be configured to never emit anything by
passing false to its completeImmediately parameter, which is true by default. This
publisher is useful for demo or testing purposes, or when all you want to do is signal
completion of some task to a subscriber. Run the playground and its completion
event is printed:

——— Example of: replaceEmpty ———

finished

Now, insert this line of code before calling sink:

.replaceEmpty(with: 1)

raywenderlich.com 84
Combine Chapter 3: Transforming Operators

Run the playground again, and this time you get a 1 before the completion:

1
finished

Incrementally transforming output

You’ve seen how Combine includes operators such as map that correspond and work
similarly to higher-order functions found in the Swift standard library. However,
Combine has a few more tricks up its sleeve that let you manipulate values received
from an upstream publisher.

scan(_:_:)
A great example of this in the transforming category is scan. It will provide the
current value emitted by an upstream publisher to a closure, along with the last
value returned by that closure.

In the following marble diagram, scan begins by storing a starting value of 0. As it

receives each value from the publisher, it adds it to the previously stored value, and
then stores and emits the result:

Note: If you are using the full project to enter and run this code, there’s no
straightforward way to plot the output — as is possible in a playground.
Instead, you can print the output by changing the sink code in the example
below to .sink(receiveValue: { print($0) }).

raywenderlich.com 85
Combine Chapter 3: Transforming Operators

For a practical example of how to use scan, add this new example to your
playground:

example(of: "scan") {
// 1
var dailyGainLoss: Int { .random(in: -10...10) }

// 2
let august2019 = (0..<22)
.map { _ in dailyGainLoss }
.publisher

// 3
august2019
.scan(50) { latest, current in
max(0, latest + current)
}
.sink(receiveValue: { _ in })
.store(in: &subscriptions)
}

In this example, you:

1. Create a computed property that generates a random integer between -10 and
10.

2. Use that generator to create a publisher from an array of random integers

representing fictitious daily stock price changes for a month.

3. Use scan with a starting value of 50, and then add each daily change to the
running stock price. The use of max keeps the price non-negative — thankfully
stock prices can’t fall below zero!

This time, you did not print anything in the subscription. Run the playground, and
then click the square Show Results button in the right results sidebar.

Talk about a bull run! How’d your stock do?

There’s also an error-throwing tryScan operator that works similarly. If the closure

raywenderlich.com 86
Combine Chapter 3: Transforming Operators

throws an error, tryScan fails with that error.

Challenge
Practice makes permanent. Complete this challenge to ensure you’re good to go with
transforming operators before moving on.

Challenge: Create a phone number lookup

using transforming operators
Your goal for this challenge is to create a publisher that does two things:

1. Receives a string of ten numbers or letters.

2. Looks up that number in a contacts data structure.

The starter playground, which can be found in the challenge folder, includes a
contacts dictionary and three functions. You’ll need to create a subscription to the
input publisher using transforming operators and those functions. Insert your code
right below the Add your code here placeholder, before the forEach blocks that
will test your implementation.

Tip: A function or closure can be passed directly to an operator as a parameter

if the function signature matches. For example, map(convert).

Breaking down this challenge, you’ll need to:

1. Convert the input to numbers — use the convert function, which will return nil
if it cannot convert the input to an integer.

2. If nil was returned from the previous operator, replace it with a 0.

3. Collect ten values at a time, which correspond to the three-digit area code and
seven-digit phone number format used in the United States.

4. Format the collected string value to match the format of the phone numbers in
the contacts dictionary — use the provided format function.

5. “Dial” the input received from the previous operator — use the provided dial
function.

raywenderlich.com 87
Combine Chapter 3: Transforming Operators

Solution
Did your code produce the expected results? Starting with a subscription to input,
first you needed to convert the string input one character at a time into integers:

input
.map(convert)

Next you needed to replace nil values returned from convert with 0s:

.replaceNil(with: 0)

To look up the result of the previous operations, you needed to collect those values,
and then format them to match the phone number format used in the contacts
dictionary:

.collect(10)
.map(format)

Finally, you needed to use the dial function to look up the formatted string input,
and then subscribe:

.map(dial)
.sink(receiveValue: { print($0) })

Running the playground will produce the following:

——— Example of: Create a phone number lookup ———

Contact not found for 000-123-4567
Dialing Marin (408-555-4321)...
Dialing Shai (212-555-3434)...

Bonus points if you hook this up to a VoIP service!

Key points
• Methods that perform operations on output from publishers are called operators.

• Operators are also publishers.

• Transforming operators convert input from an upstream publisher into output that
is suitable for use downstream.

• Marble diagrams are a great way to visualize how each Combine operators work.

raywenderlich.com 88
Combine Chapter 3: Transforming Operators

• Be careful when using any operators that buffer values such as collect or
flatMap to avoid memory problems.

• Be mindful when applying existing knowledge of functions from Swift standard

library. Some similarly-named Combine operators work the same while others
work entirely differently.

• Multiple operators can be chained together in a subscription.

Where to go from here?

Way to go! You just transformed yourself into a transforming titan.

Now it’s time to learn how to use another essential collection of operators to filter
what you get from an upstream publisher.

raywenderlich.com 89
4 Chapter 4: Filtering
Operators
By Shai Mishali

As you might have realized by now, operators are basically the vocabulary that you
use to manipulate Combine publishers. The more "words" you know, the better your
control of your data will be.

In the previous chapter, you learned how to consume values and transform them into
different values — definitely one of the most useful operator categories for your daily
work.

But what happens when you want to limit the values or events emitted by the
publisher, and only consume some of them? This chapter is all about how to do this
with a special group of operators: Filtering operators!

Luckily, many of these operators have parallels with the same names in the Swift
standard library, so don’t be surprised if you’re able to filter some of this chapter’s
content. :]

It’s time to dive right in.

Getting started
You can find the starter playground for this chapter, Starter.playground, in the
projects folder. As you progress through this chapter, you’ll write code in the
playground and then run the playground. This will help you understand how
different operators manipulate events emitted by your publisher.

raywenderlich.com 90
Combine Chapter 4: Filtering Operators

Note: Most operators in this chapter have parallels with a try prefix, for
example, filter vs. tryFilter. The only difference between them is that the
latter provides a throwing closure. Any error you throw from within the closure
will terminate the publisher with the thrown error. For brevity’s sake, this
chapter will only cover the non-throwing variations, since they are virtually
identical.

Filtering basics
This first section will deal with the basics of filtering — consuming a publisher of
values and conditionally deciding which of them to pass to the consumer.

The easiest way to do this is the aptly-named operator — filter, which takes a
closure returning a Bool and only passes down values that match the provided
predicate:

Add this new example to your playground:

example(of: "filter") {
// 1
let numbers = (1...10).publisher

// 2
numbers
.filter { $0.isMultiple(of: 3) }
.sink(receiveValue: { n in

raywenderlich.com 91
Combine Chapter 4: Filtering Operators

print("\(n) is a multiple of 3!")

})
.store(in: &subscriptions)
}

In the above example, you:

1. Create a new publisher, which will emit a finite number of values — 1 through 10,
and then complete, using the publisher property on Sequence types.

2. Use the filter operator, passing in a predicate where you only allow through
numbers that are multiples of three.

Run your playground. You should see the following in your console:

——— Example of: filter ———

3 is a multiple of 3!
6 is a multiple of 3!
9 is a multiple of 3!

Such an elegant way to cheat on your math homework, isn’t it? :]

Many times in the lifetime of your app, you have publishers that emit identical
values in a row that you might want to ignore. For example, if a user types "a" five
times in a row and then types "b", you might want to disregard the excessive "a"s.

Combine provides the perfect operator for the task: removeDuplicates:

Notice how you don’t have to provide any arguments to this operator!
removeDuplicate automatically works for any values conforming to Equatable,
including String.

raywenderlich.com 92
Combine Chapter 4: Filtering Operators

Add the following example of removeDuplicates() to your playground — and be

sure to include a space before the ? in the words variable:

example(of: "removeDuplicates") {
// 1
let words = "hey hey there! want to listen to mister mister ?"
.components(separatedBy: " ")
.publisher
// 2
words
.removeDuplicates()
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

This code isn’t too different from the last one. You:

1. Separate a sentence into an array of words (e.g., Array<String>) and then create
a new publisher to emit these words.

2. Apply removeDuplicates() to your words publisher.

Run your playground and take a look at the debug console:

——— Example of: removeDuplicates ———

hey
there!
want
to
listen
to
mister
?

As you can see, you’ve skipped the second "hey" and the second "mister". Awesome!

Note: What about values that don’t conform to Equatable? Well,

removeDuplicates has another overload that takes a closure with two values,
from which you'll return a Bool to indicate whether the values are equal or
not.

raywenderlich.com 93
Combine Chapter 4: Filtering Operators

Compacting and ignoring

Quite often, you’ll find yourself dealing with a publisher emitting Optional values.
Or even more commonly, you’ll want to perform some operation on your values that
might return nil, but who wants to handle all those nils ?!

If your spidey sense is tingling, thinking of a very well-known method on Sequence

from the Swift standard library called compactMap that does that job, good news –
there’s also an operator with the same name!

Add the following to your playground:

example(of: "compactMap") {
// 1
let strings = ["a", "1.24", "3",
"def", "45", "0.23"].publisher

// 2
strings
.compactMap { Float($0) }
.sink(receiveValue: {
// 3
print($0)
})
.store(in: &subscriptions)
}

raywenderlich.com 94
Combine Chapter 4: Filtering Operators

Just as the diagram outlines, you:

1. Create a publisher that emits a finite list of strings.

2. Use compactMap to attempt to initialize a Float from each individual string. If

Float’s initializer doesn’t know how to convert the provided string, it returns
nil.

3. Only print strings that have been successfully converted to Floats.

Run the above example in your playground and you should see output similar to the
diagram above:

——— Example of: compactMap ———

1.24
3.0
45.0
0.23

All right, why don’t you take a quick break from all these values... who cares about
those, right? Sometimes, all you want to know is that the publisher has finished
emitting values, disregarding the actual values. When such a scenario occurs, you
can use the ignoreOutput operator:

As the diagram above shows, it doesn’t matter which values are emitted or how many
of them, as they’re all ignored; you only push the completion event through to the
consumer.

raywenderlich.com 95
Combine Chapter 4: Filtering Operators

Experiment with this example by adding the following code to your playground:

example(of: "ignoreOutput") {
// 1
let numbers = (1...10_000).publisher

// 2
numbers
.ignoreOutput()
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

In the above example, you:

1. Create a publisher emitting 10,000 values from 1 through 10,000.

2. Add the ignoreOutput operator, which omits all values and emits only the
completion event to the consumer.

Can you guess what the output of this code will be?

If you guessed that no values will be printed, you’re right! Run your playground and
check out the debug console:

——— Example of: ignoreOutput ———

Completed with: finished

Finding values
In this section, you’ll learn about two operators that also have their origins in the
Swift standard library: first(where:) and last(where:). As their names imply,
you use them to find and emit only the first or the last value matching the provided
predicate, respectively.

raywenderlich.com 96
Combine Chapter 4: Filtering Operators

Time to check out a few examples, starting with first(where:).

This operator is interesting because it’s lazy, meaning: It only takes as many values
as it needs until it finds one matching the predicate you provided. As soon as it finds
a match, it cancels the subscription and completes.

Add the following piece of code to your playground to see how this works:

example(of: "first(where:)") {
// 1
let numbers = (1...9).publisher

// 2
numbers
.first(where: { $0 % 2 == 0 })
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

Here’s what the code you’ve just added does:

1. Creates a new publisher emitting numbers from 1 through 9.

2. Uses the first(where:) operator to find the first emitted even value.

Run this example in your playground and look at the console output:

——— Example of: first(where:) ———

2
Completed with: finished

raywenderlich.com 97
Combine Chapter 4: Filtering Operators

It works exactly like you probably guessed it would. But wait, what about the
subscription to the upstream, meaning the numbers publisher? Does it keep emitting
its values even after it finds a matching even number? Test this theory by finding the
following line:

numbers

Then add the print("numbers") operator immediately after that line, so it looks as
follows:

numbers
.print("numbers")

Note: You can use the print operator anywhere in your operator chain to see
exactly what events occur at that point.

Run your playground again, and take a look at it. Your output should like similar to
the following:

——— Example of: first(where:) ———

numbers: receive subscription: (1...9)
numbers: request unlimited
numbers: receive value: (1)
numbers: receive value: (2)
numbers: receive cancel
2
Completed with: finished

This is very interesting!

As you can see, as soon as first(where:) finds a matching value, it sends a

cancellation through the subscription, causing the upstream to stop emitting values.
Very handy!

raywenderlich.com 98
Combine Chapter 4: Filtering Operators

Now, you can move on to the opposite of this operator — last(where:), whose
purpose is to find the last value matching a provided predicate.

As opposed to first(where:), this operator is greedy since it must wait for all values
to emit to know whether a matching value has been found. For that reason, the
upstream must be a publisher that completes at some point.

Add the following code to your playground:

example(of: "last(where:)") {
// 1
let numbers = (1...9).publisher

// 2
numbers
.last(where: { $0 % 2 == 0 })
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

Much like the previous code example, you:

1. Create a publisher that emits numbers between 1 and 9.

2. Use the last(where:) operator to find the last emitted odd value.

Did you guess what the output will be? Run your playground and find out:

——— Example of: last(where:) ———

8
Completed with: finished

raywenderlich.com 99
Combine Chapter 4: Filtering Operators

Remember I said earlier that the publisher must complete for this operator to work?
Why is that?

Well, that’s because there’s no way for the operator to know if the publisher will emit
a value that matches the criteria down the line, so the operator must know the full
scope of the publisher before it can determine the last item matching the predicate.

To see this in action, replace the entire example with the following:

example(of: "last(where:)") {
let numbers = PassthroughSubject<Int, Never>()

numbers
.last(where: { $0 % 2 == 0 })
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)

numbers.send(1)
numbers.send(2)
numbers.send(3)
numbers.send(4)
numbers.send(5)
}

In this example, you use a PassthroughSubject and manually send events through
it.

Run your playground again, and you should see... absolutely nothing:

——— Example of: last(where:) ———

As expected, since the publisher never completes, there’s no way to determine the
last value matching the criteria.

To fix this, add the following as the last line of the example to send a completion
through the subject:

numbers.send(completion: .finished)

Run your playground again, and everything should now work as expected:

——— Example of: last(where:) ———

4
Completed with: finished

I guess that everything must come to an end... or completion, in this case.

raywenderlich.com 100
Combine Chapter 4: Filtering Operators

Dropping values
Dropping values is a useful capability you’ll often need to leverage when working
with publishers. For example, you can use it when you want to ignore values from
one publisher until a second one starts publishing, or if you want to ignore a specific
amount of values at the start of the stream.

Three operators fall into this category, and you’ll start by learning about the simplest
one first — dropFirst.

The dropFirst operator takes a count parameter — defaulting to 1 if omitted — and

ignores the first count values emitted by the publisher. Only values emitted after
count values have been emitted will be allowed through.

Add the following code to the end of your playground to try this operator:

example(of: "dropFirst") {
// 1
let numbers = (1...10).publisher

// 2
numbers
.dropFirst(8)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

raywenderlich.com 101
Combine Chapter 4: Filtering Operators

As in the previous diagram, you:

1. Create a publisher that emits 10 numbers between 1 and 10.

2. Use dropFirst(8) to drop the first eight values, printing only 9 and 10.

Run your playground and you should see the following output:

——— Example of: dropFirst ———

9
10

Simple, right? Often, the most useful operators are!

Moving on to the next operator in the value dropping family – drop(while:). This is
another extremely useful variation that takes a predicate closure and ignores any
values emitted by the publisher until the first time that predicate is met. As soon as
the predicate is met, values begin to flow through the operator:

Add the following example to your playground to see this in action:

example(of: "drop(while:)") {
// 1
let numbers = (1...10).publisher

// 2
numbers
.drop(while: { $0 % 5 != 0 })
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

raywenderlich.com 102
Combine Chapter 4: Filtering Operators

In the following code, you:

1. Create a publisher that emits numbers between 1 and 10.

2. Use drop(while:) to wait for the first value that is divisible by five. As soon as
the condition is met, values will start flowing through the operator and won’t be
dropped anymore.

Run your playground and look at the debug console:

——— Example of: drop(while:) ———

5
6
7
8
9
10

Excellent! As you can see, you’ve dropped the first four values. As soon as 5 arrives,
the question "is this divisible by five?" is finally true, so it now emits 5 and all future
values.

You might ask yourself – how is this operator different from filter? Both of them
take a closure that controls which values are emitted based on the result of that
closure.

The first difference is that filter lets values through if you return true in the
closure, while drop(while:) skips values as long you return true from the closure.

The second, and more important difference is that filter never stops evaluating its
condition for all values published by the upstream publisher. Even after the
condition of filter evaluates to true, further values are still "questioned" and your
closure must answer the question: "Do you want to let this value through?".

On the contrary, drop(while:)’s predicate closure will never be executed again after
the condition is met. To confirm this, replace the following line:

.drop(while: { $0 % 5 != 0 })

With this piece of code:

.drop(while: {
print("x")
return $0 % 5 != 0
})

raywenderlich.com 103
Combine Chapter 4: Filtering Operators

You added a print statement to print x to the debug console every time the closure
is invoked. Run the playground and you should see the following output:

——— Example of: drop(while:) ———

x
x
x
x
x
5
6
7
8
9
10

As you might have noticed, x prints exactly five times. As soon as the condition is
met (when 5 is emitted), the closure is never evaluated again.

Alrighty then. Two dropping operators down, one more to go.

The final and most elaborate operator of the filtering category is

drop(untilOutputFrom:).

Imagine a scenario where you have a user tapping a button, but you want to ignore
all taps until your isReady publisher emits some result. This operator is perfect for
this sort of condition.

It skips any values emitted by a publisher until a second publisher starts emitting
values, creating a relationship between them:

raywenderlich.com 104
Combine Chapter 4: Filtering Operators

The top line represents the isReady stream and the second line represents taps by
the user passing through drop(untilOutputFrom:), which takes isReady as an
argument.

At the end of your playground, add the following code that reproduces this diagram:

example(of: "drop(untilOutputFrom:)") {
// 1
let isReady = PassthroughSubject<Void, Never>()
let taps = PassthroughSubject<Int, Never>()

// 2
taps
.drop(untilOutputFrom: isReady)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

// 3
(1...5).forEach { n in
taps.send(n)

if n == 3 {
isReady.send()
}
}
}

In this code, you:

1. Create two PassthroughSubjects that you can manually send values through.
The first is isReady while the second represents taps by the user.

2. Use drop(untilOutputFrom: isReady) to ignore any taps from the user until
isReady emits at least one value.

3. Send five "taps" through the subject, just like in the diagram above. After the
third tap, you send isReady a value.

Run your playground, then take a look at your debug console. You will see the
following output:

——— Example of: drop(untilOutputFrom:) ———

4
5

raywenderlich.com 105
Combine Chapter 4: Filtering Operators

This output is the same as the diagram above:

• There are five taps from the user. The first three are ignored.

• After the third tap, isReady emits a value.

• All future taps by the user are passed through.

You’ve gained quite a mastery of getting rid of unwanted values! Now, it’s time for
the final filtering operators group: Limiting values.

Limiting values
In the previous section, you’ve learned how to drop — or skip — values until a certain
condition is met. That condition could be either matching some static value, a
predicate closure, or a dependency on a different publisher.

This section tackles the opposite need: receiving values until some condition is met,
and then forcing the publisher to complete. For example, consider a request that may
emit an unknown amount of values, but you only want a single emission and don’t
care about the rest of them.

Combine solves this set of problems with the prefix family of operators. Even
though the name isn’t entirely intuitive, the abilities these operators provide are
useful for many real-life situations.

The prefix family of operators is similar to the drop family and provides
prefix(_:), prefix(while:) and prefix(untilOutputFrom:). However, instead
of dropping values until some condition is met, the prefix operators take values
until that condition is met.

Now, it’s time for you to dive into the final set of operators for this chapter, starting
with prefix(_:).

raywenderlich.com 106
Combine Chapter 4: Filtering Operators

As the opposite of dropFirst, prefix(_:) will take values only up to the provided
amount and then complete:

Add the following code to your playground to demonstrate this:

example(of: "prefix") {
// 1
let numbers = (1...10).publisher

// 2
numbers
.prefix(2)
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

This code is quite similar to the drop code you used in the previous section. You:

1. Create a publisher that emits numbers from 1 through 10.

2. Use prefix(2) to allow the emission of only the first two values. As soon as two
values are emitted, the publisher completes.

Run your playground and you’ll see the following output:

——— Example of: prefix ———

1
2
Completed with: finished

raywenderlich.com 107
Combine Chapter 4: Filtering Operators

Just like first(where:), this operator is lazy, meaning it only takes up as many
values as it needs and then terminates. This also prevents numbers from producing
additional values beyond 1 and 2, since it also completes.

Next up is prefix(while:), which takes a predicate closure and lets values from the
upstream publisher through as long as the result of that closure is true. As soon as
the result is false, the publisher will complete:

Add the following example to your playground to try this:

example(of: "prefix(while:)") {
// 1
let numbers = (1...10).publisher

// 2
numbers
.prefix(while: { $0 < 3 })
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)
}

This example is mostly identical to the previous one, aside from using a closure to
evaluate the prefixing condition. You:

1. Create a publisher that emits values between 1 and 10.

2. Use prefix(while:) to let values through as long as they’re smaller than 3. As

soon as a value equal to or larger than 3 is emitted, the publisher completes.

raywenderlich.com 108
Combine Chapter 4: Filtering Operators

Run the playground and check out the debug console; the output should be identical
to the one from the previous operator:

——— Example of: prefix(while:) ———

1
2
Completed with: finished

With the first two prefix operators behind us, it’s time for the most complex one:
prefix(untilOutputFrom:). Once again, as opposed to drop(untilOutputFrom:)
which skips values until a second publisher emits, prefix(untilOutputFrom:) takes
values until a second publisher emits.

Imagine a scenario where you have a button that the user can only tap twice. As soon
as two taps occur, further tap events on the button should be omitted:

Add the final example for this chapter to the end of your playground:

example(of: "prefix(untilOutputFrom:)") {
// 1
let isReady = PassthroughSubject<Void, Never>()
let taps = PassthroughSubject<Int, Never>()

// 2
taps
.prefix(untilOutputFrom: isReady)
.sink(receiveCompletion: { print("Completed with: \($0)") },
receiveValue: { print($0) })
.store(in: &subscriptions)

// 3

raywenderlich.com 109
Combine Chapter 4: Filtering Operators

(1...5).forEach { n in
taps.send(n)

if n == 2 {
isReady.send()
}
}
}

If you think back to the drop(untilOutputFrom:) example, you should find this
easy to understand. You:

1. Create two PassthroughSubjects that you can manually send values through.
The first is isReady while the second represents taps by the user.

2. Use prefix(untilOutputFrom: isReady) to let tap events through until

isReady emits at least one value.

3. Send five "taps" through the subject, exactly as in the diagram above. After the
second tap, you send isReady a value.

Run the playground. Looking at the console, you should see the following:

——— Example of: prefix(untilOutputFrom:) ———

1
2
Completed with: finished

raywenderlich.com 110
Combine Chapter 4: Filtering Operators

Challenge
You have quite a lot of filtering knowledge at your disposal now. Why not try a short
challenge?

Challenge: Filter all the things

Create an example that publishes a collection of numbers from 1 through 100, and
use filtering operators to:

1. Skip the first 50 values emitted by the upstream publisher.

2. Take the next 20 values after those first 50 values.

3. Only take even numbers.

The output of your example should produce the following numbers, one per line:
52 54 56 58 60 62 64 66 68 70

Note: In this challenge, you’ll need to chain multiple operators together to

produce the desired values.

You can find the full solution to this challenge in projects/challenge/

Final.playground.

Key points
In this chapter, you learned that:

• Filtering operators let you control which values emitted by the upstream publisher
are sent downstream, to another operator or to the consumer.

• When you don’t care about the values themselves, and only want a completion
event, ignoreOutput is your friend.

• Finding values is another sort of filtering, where you can find the first or last
values to match a provided predicate using first(where:) and last(where:),
respectively.

raywenderlich.com 111
Combine Chapter 4: Filtering Operators

• First-style operators are lazy; they take only as many values as needed and then
complete. Last-style operators are greedy and must know the full scope of the
values before deciding which of the values is the last to fulfill the condition.

• You can control how many values emitted by the upstream publisher are ignored
before sending values downstream by using the drop family of operators.

• Similarly, you can control how many values the upstream publisher may emit
before completing by using the prefix family of operators.

Where to go from here?

Wow, what a ride this chapter has been! You should rightfully feel like a master of
filtering, ready to channel these upstream values in any way you desire.

With the knowledge of transforming and filtering operators already in your tool belt,
it’s time for you to move to the next chapter and learn another extremely useful
group of operators: Combining operators.

raywenderlich.com 112
5 Chapter 5: Combining
Operators
By Shai Mishali

Now that the transforming and filtering operator categories are in your tool belt,
you have a substantial amount of knowledge. You’ve learned how operators work,
how they manipulate the upstream and how to use them to construct logical
publisher chains from your data.

In this chapter, you’ll learn about one of the more complex, yet useful, categories of
operators: Combining operators. This set of operators lets you combine events
emitted by different publishers and create meaningful combinations of data in your
Combine code.

Why is combining useful? Think about a form with multiple inputs from the user — a
username, a password and a checkbox. You’ll need to combine this data to compose a
single publisher with all of the information you need.

As you learn more about how each operator functions and how to select the right one
for your needs, your code will become more coherent.

Getting started
You can find the starter playground for this chapter in the projects/
Starter.playground folder. Throughout this chapter, you’ll add code to your
playground and run it to see how various operators create different combinations of
publishers and their events.

raywenderlich.com 113
Combine Chapter 5: Combining Operators

Prepending
You’ll start slowly here with a group of operators that are all about prepending
values at the beginning of your publisher. In other words, you’ll use them to add
values that emit before any values from your original publisher.

In this section, you’ll learn about prepend(Output...), prepend(Sequence) and

prepend(Publisher).

prepend(Output...)
This variation of prepend takes a variadic list of values using the variadic ... syntax.
This means it can take any number of values, as long as they’re of the same Output
type as the original publisher.

Add the following code to your playground to experiment with the above example:

example(of: "prepend(Output...)") {
// 1
let publisher = [3, 4].publisher

// 2
publisher
.prepend(1, 2)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

raywenderlich.com 114
Combine Chapter 5: Combining Operators

In the above code, you:

1. Create a publisher that emits the numbers 3 4.

2. Use prepend to add the numbers 1 and 2 before the publisher’s own values.

Run your playground. You should see the following in your debug console:

——— Example of: prepend(Output...) ———

1
2
3
4

Pretty straightforward!

Hang on, do you remember how operators are chainable? That means you can easily
add more than a single prepend, if you’d like.

Below the following line:

.prepend(1, 2)

Add the following:

.prepend(-1, 0)

Run your playground again. you should see the following output:

——— Example of: prepend(Output...) ———

-1
0
1
2
3
4

Notice that the order of operations is crucial here. The last prepend affects the
upstream first, meaning -1 and 0 are prepended, then 1 and 2, and finally the
original publisher’s values.

raywenderlich.com 115
Combine Chapter 5: Combining Operators

prepend(Sequence)
This variation of prepend is similar to the previous one, with the difference that it
takes any Sequence-conforming object as an input. For example, it could take an
Array or a Set.

Add the following code to your playground to experiment with this operator:

example(of: "prepend(Sequence)") {
// 1
let publisher = [5, 6, 7].publisher

// 2
publisher
.prepend([3, 4])
.prepend(Set(1...2))
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

In the previous code, you:

1. Create a publisher that emits the numbers 5, 6 and 7.

2. Chain prepend(Sequence) twice to the original publisher. Once to prepend

values from an Array and a second time to prepend values from a Set.

raywenderlich.com 116
Combine Chapter 5: Combining Operators

Run the playground. Your output should be similar to the following:

——— Example of: prepend(Sequence) ———

1
2
3
4
5
6
7

Note: An important fact to remember about Sets, as opposed to Arrays, is

that they are unordered, so the order in which the items emit is not
guaranteed. This means the first two values in the above example could be
either 1 and 2, or 2 and 1.

But wait, there’s more! Many types conform to Sequence in Swift, which lets you do
some interesting things.

After the second prepend:

.prepend(Set(1...2))

Add the following line:

.prepend(stride(from: 6, to: 11, by: 2))

In this line of code, you create a Strideable which lets you stride between 6 and 11
in steps of 2. Since Strideable conforms to Sequence, you can use it in
prepend(Sequence).

Run your playground one more time and take a look at the debug console:

——— Example of: prepend(Sequence) ———

6
8
10
1
2
3
4
5
6
7

raywenderlich.com 117
Combine Chapter 5: Combining Operators

As you can see, three new values are now prepended to the publisher before the
previous output – 6, 8 and 10, the result of striding between 6 and 11 in steps of 2.

prepend(Publisher)
The two previous operators prepended lists of values to an existing publisher. But
what if you have two different publishers and you want to glue their values together?
You can use prepend(Publisher) to add values emitted by a second publisher before
the original publisher’s values.

Try out the above example by adding the following to your playground:

example(of: "prepend(Publisher)") {
// 1
let publisher1 = [3, 4].publisher
let publisher2 = [1, 2].publisher

// 2
publisher1
.prepend(publisher2)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

raywenderlich.com 118
Combine Chapter 5: Combining Operators

In this code, you:

1. Create two publishers. One emitting the numbers 3 and 4, and a second one
emitting 1 and 2.

2. Prepend publisher2 at the beginning of publisher1. Values from publisher1

emit only after publisher2 completes.

If you run your playground, your debug console should present the following output:

——— Example of: prepend(Publisher) ———

1
2
3
4

As expected, the values 1 and 2 are emitted first from publisher2; only then are 3
and 4 emitted by publisher1.

There’s one more detail about this operator that you should be aware of, and it would
be easiest to show it with an example.

Add the following to the end of your playground:

example(of: "prepend(Publisher) #2") {

// 1
let publisher1 = [3, 4].publisher
let publisher2 = PassthroughSubject<Int, Never>()

// 2
publisher1
.prepend(publisher2)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

// 3
publisher2.send(1)
publisher2.send(2)
}

This example is similar to the previous one, except that publisher2 is now a
PassthroughSubject that you can push values to manually.

In the following example, you:

1. Create two publishers. The first emits values 3, and 4 while the second is a
PassthroughSubject that can accept values dynamically.

2. Prepend the subject before publisher1.

raywenderlich.com 119
Combine Chapter 5: Combining Operators

3. Send the values 1 and 2 through the subject publisher2.

Take a second and run through this code inside your head. What do you expect the
output to be?

Now, run the playground again and take a look at the debug console. You should see
the following:

——— Example of: prepend(Publisher) #2 ———

1
2

Wait, what? Why are there only two numbers emitted here from publisher2? You
must be thinking... hey there, Shai, didn’t you just say values prepend to the existing
publisher?

Well, think about it — how can Combine know the prepended publisher, publisher2,
has finished emitting values? It doesn’t, since it has emitted values, but no
completion event. For that reason, a prepended publisher must complete so
Combine knows it has finished prepending and can continue to the primary
publisher.

After the following line:

publisher2.send(2)

Add this one:

publisher2.send(completion: .finished)

Combine now knows it can handle emissions from publisher1 since publisher2
has finished its work.

Run your playground again; you should see the expected output this time around:

——— Example of: prepend(Publisher) #2 ———

1
2
3
4

raywenderlich.com 120
Combine Chapter 5: Combining Operators

Appending
This next set of operators deals with concatenating events emitted by publishers
with other values. But in this case, you’ll deal with appending instead of prepending,
using append(Output...), append(Sequence) and append(Publisher). These
operators work in a similar way as their prepend counterparts.

append(Output...)
append(Output...) works similarly to its prepend counterpart: It also takes a
variadic list of type Output but then appends its items after the original publisher has
completed with a .finished event.

Add the following code to your playground to experiment with this operator:

example(of: "append(Output...)") {
// 1
let publisher = [1].publisher

// 2
publisher
.append(2, 3)
.append(4)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

raywenderlich.com 121
Combine Chapter 5: Combining Operators

In the code above, you:

1. Create a publisher emitting only a single value: 1.

2. Use append twice, first to append 2 and 3 and then to append 4.

Think about this code for a minute — what do you think the output will be?

Run the playground and check out the output:

——— Example of: append(Output...) ———

1
2
3
4

Appending works exactly like you’d expect, where each append waits for the
upstream to complete before adding its own work to it.

This means that the upstream must complete or appending would never occur since
Combine couldn’t know the previous publisher has finished emitting all of its values.

To verify this behavior, add the following example:

example(of: "append(Output...) #2") {

// 1
let publisher = PassthroughSubject<Int, Never>()

publisher
.append(3, 4)
.append(5)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)

// 2
publisher.send(1)
publisher.send(2)
}

This example is identical to the previous one, with two differences:

1. publisher is now a PassthroughSubject, which lets you manually send values

to it.

2. You send 1 and 2 to the PassthroughSubject.

raywenderlich.com 122
Combine Chapter 5: Combining Operators

Run your playground again and you’ll see that only the values sent to publisher are
emitted:

——— Example of: append(Output...) #2 ———

1
2

Both append operators have no effect since they can’t possibly work until publisher
completes. Add the following line at the very end of the example:

publisher.send(completion: .finished)

Run your playground again and you should see all values, as expected:

——— Example of: append(Output...) #2 ———

1
2
3
4
5

This behavior applies to the entire family of append operators; no appending occurs
unless the original publisher sends a completion event.

append(Sequence)
This variation of append takes any Sequence-conforming object and appends its
values after all values from the original publisher have emitted.

raywenderlich.com 123
Combine Chapter 5: Combining Operators

Add the following to your playground to experiment with this operator:

example(of: "append(Sequence)") {
// 1
let publisher = [1, 2, 3].publisher

publisher
.append([4, 5]) // 2
.append(Set([6, 7])) // 3
.append(stride(from: 8, to: 11, by: 2)) // 4
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

This code is similar to the prepend(Sequence) example from the previous section.
You:

1. Create a publisher that emits 1, 2 and 3.

2. Append an Array with the values 4 and 5 (ordered).

3. Append a Set with the values 6 and 7 (unordered).

4. Append a Strideable that strides between 8 and 11 by steps of 2.

Run your playground and you should see the following output:

——— Example of: append(Sequence) ———

1
2
3
4
5
7
6
8
10

As you can see, the execution of the appends is sequential as the previous publisher
must complete before the next append performs. Note that the set of 6 and 7 may be
in a different order for you, as sets are unordered.

raywenderlich.com 124
Combine Chapter 5: Combining Operators

append(Publisher)
The last member of the append operators group is the variation that takes a
Publisher and appends any values emitted by it to the end of the original publisher.

To try this example, add the following to your playground:

example(of: "append(Publisher)") {
// 1
let publisher1 = [1, 2].publisher
let publisher2 = [3, 4].publisher

// 2
publisher1
.append(publisher2)
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

In this code, you:

1. Create two publishers, where the first emits 1 and 2, and the second emits 3 and
4.

2. Append publisher2 to publisher1, so all values from publisher2 are appended

at the end of publisher1 once it completes.

Run the playground and you should see the following output:

——— Example of: append(Publisher) ———

1
2
3
4

raywenderlich.com 125
Combine Chapter 5: Combining Operators

Advanced combining
At this point, you know everything about appending and prepending values,
sequences and even entire publishers.

This next section will dive into some of the more complex operators related to
combining different publishers. Even though they’re relatively complex, they’re also
some of the most useful operators for publisher composition. It’s worth taking the
time to get comfortable with how they work.

switchToLatest
Since this section includes some of the more complex combining operators in
Combine, why not start with the most complex one of the bunch?!

Joking aside, switchToLatest is complex but highly useful. It lets you switch entire
publisher subscriptions on the fly while canceling the pending publisher
subscription, thus switching to the latest one.

You can only use it on publishers that themselves emit publishers.

raywenderlich.com 126
Combine Chapter 5: Combining Operators

Add the following code to your playground to experiment with the example you see
in the above diagram:

example(of: "switchToLatest") {
// 1
let publisher1 = PassthroughSubject<Int, Never>()
let publisher2 = PassthroughSubject<Int, Never>()
let publisher3 = PassthroughSubject<Int, Never>()

// 2
let publishers = PassthroughSubject<PassthroughSubject<Int,
Never>, Never>()

// 3
publishers
.switchToLatest()
.sink(receiveCompletion: { _ in print("Completed!") },
receiveValue: { print($0) })
.store(in: &subscriptions)

// 4
publishers.send(publisher1)
publisher1.send(1)
publisher1.send(2)

// 5
publishers.send(publisher2)
publisher1.send(3)
publisher2.send(4)
publisher2.send(5)

// 6
publishers.send(publisher3)
publisher2.send(6)
publisher3.send(7)
publisher3.send(8)
publisher3.send(9)

// 7
publisher3.send(completion: .finished)
publishers.send(completion: .finished)
}

Yikes, that’s a lot of code! But don’t worry, it’s simpler than it looks. Breaking it
down, you:

1. Create three PassthroughSubjects that accept integers and no errors.

2. Create a second PassthroughSubject that accepts other PassthroughSubjects.

For example, you can send publisher1, publisher2 or publisher3 through it.

raywenderlich.com 127
Combine Chapter 5: Combining Operators

3. Use switchToLatest on your publishers. Now, every time you send a different
publisher through the publishers subject, you switch to the new one and cancel
the previous subscription.

4. Send publisher1 to publishers and then send 1 and 2 to publisher1.

5. Send publisher2, which cancels the subscription to publisher1. You then send
3 to publisher1, but it’s ignored, and send 4 and 5 to publisher2, which are
pushed through because publisher2 is the current subscription.

6. Send publisher3, which cancels the subscription to publisher2. As before, you

send 6 to publisher2 and it’s ignored, and then send 7, 8 and 9, which are
pushed through the subscription.

7. Finally, you send a completion event to the current publisher, publisher3, and
another completion event to publishers. This completes all active subscriptions.

If you followed the above diagram, you might have already guessed the output of this
example.

Run the playground and look at the debug console:

——— Example of: switchToLatest ———

1
2
4
5
7
8
9
Completed!

If you’re not sure why this is useful in a real-life app, consider the following scenario:
Your user taps a button that triggers a network request. Immediately afterward, the
user taps the button again, which triggers a second network request. But how do you
get rid of the pending request, and only use the latest request? switchToLatest to
the rescue!

Instead of just theorizing, why don’t you try out this example?

Add the following code to your playground:

example(of: "switchToLatest - Network Request") {

let url = URL(string: "https://source.unsplash.com/random")!

// 1
func getImage() -> AnyPublisher<UIImage?, Never> {

raywenderlich.com 128
Combine Chapter 5: Combining Operators

return URLSession.shared
.dataTaskPublisher(for: url)
.map { data, _ in UIImage(data: data) }
.print("image")
.replaceError(with: nil)
.eraseToAnyPublisher()
}

// 2
let taps = PassthroughSubject<Void, Never>()

taps
.map { _ in getImage() } // 3
.switchToLatest() // 4
.sink(receiveValue: { _ in })
.store(in: &subscriptions)

// 5
taps.send()

DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
taps.send()
}
DispatchQueue.main.asyncAfter(deadline: .now() + 3.1) {
taps.send()
}
}

As in the previous example, this might look like a long and complicated piece of
code, but it’s simple once you break it down.

In this code, you:

1. Define a function, getImage(), which performs a network request to fetch a

random image from Unsplash’s public API. This uses
URLSession.dataTaskPublisher, one of the many Combine extensions for
Foundation. You’ll learn much more about this and others in Section 3, "Combine
in Action."

2. Create a PassthroughSubject to simulate user taps on a button.

3. Upon a button tap, map the tap to a new network request for a random image by
calling getImage(). This essentially transforms Publisher<Void, Never> into
Publisher<Publisher<UIImage?, Never>, Never> — a publisher of
publishers.

4. Use switchToLatest() exactly like in the previous example, since you have a
publisher of publishers. This guarantees only one publisher will emit values, and
cancel any previous subscriptions.

raywenderlich.com 129
Combine Chapter 5: Combining Operators

5. Simulate three delayed button taps using a DispatchQueue. The first tap is
immediate, the second tap comes after three seconds, and the last tap comes just
a tenth of a second after the second tap.

Run the playground and take a look at the output below:

——— Example of: switchToLatest - Network Request ———

image: receive subscription: (DataTaskPublisher)
image: request unlimited
image: receive value: (Optional(<UIImage:0x600000364120
anonymous {1080, 720}>))
image: receive finished
image: receive subscription: (DataTaskPublisher)
image: request unlimited
image: receive cancel
image: receive subscription: (DataTaskPublisher)
image: request unlimited
image: receive value: (Optional(<UIImage:0x600000378d80
anonymous {1080, 1620}>))
image: receive finished

You might notice that only two images are actually fetched; that’s because only a
tenth of a second passes between the second and third taps. The third tap switches to
a new request before the second fetch returns, canceling the second subscription –
hence the line that says image: receive cancel.

If you want to see a better visualization of this, tap the following button:

Then run the playground again and wait a few seconds. You should see the last image
loaded.

raywenderlich.com 130
Combine Chapter 5: Combining Operators

Right-click the image and select Value History:

You should see both loaded images — you may have to scroll to see both of them:

Before moving to the next operator, be sure to comment out this entire example to
avoid running the asynchronous network requests every time you run your
playground.

raywenderlich.com 131
Combine Chapter 5: Combining Operators

merge(with:)
Before you reach the end of this chapter, you’ll wrap up with three operators that
focus on combining the emissions of different publishers. You’ll start with
merge(with:).

This operator interleaves emissions from different publishers of the same type, like
so:

To try out this example, add the following code to your playground:

example(of: "merge(with:)") {
// 1
let publisher1 = PassthroughSubject<Int, Never>()
let publisher2 = PassthroughSubject<Int, Never>()

// 2
publisher1
.merge(with: publisher2)
.sink(receiveCompletion: { _ in print("Completed") },
receiveValue: { print($0) })
.store(in: &subscriptions)

// 3
publisher1.send(1)
publisher1.send(2)

publisher2.send(3)

publisher1.send(4)

publisher2.send(5)

raywenderlich.com 132
Combine Chapter 5: Combining Operators

// 4
publisher1.send(completion: .finished)
publisher2.send(completion: .finished)
}

In this code, which correlates with the above diagram, you:

1. Create two PassthroughSubjects that accept and emit integer values and will
not emit an error.

2. Merge publisher1 with publisher2, interleaving the emitted values from both.
Combine offers overloads that let you merge up to eight different publishers.

3. You add 1 and 2 to publisher1, then add 3 to publisher2, then add 4 to

publisher1 again and finally add 5 to publisher2.

4. You send a completion event to both publisher1 and publisher2.

Run your playground and you should see the following output, as expected:

——— Example of: merge(with:) ———

1
2
3
4
5
Completed

combineLatest
combineLatest is another operator that lets you combine different publishers. It
also lets you combine publishers of different value types, which can be extremely
useful. However, instead of interleaving the emissions of all publishers, it emits a
tuple with the latest values of all publishers whenever any of them emit a value.

raywenderlich.com 133
Combine Chapter 5: Combining Operators

One catch though: The origin publisher and every publisher passed to
combineLatest must emit at least one value before combineLatest will emit
anything.

Add the following code to your playground to try out this operator:

example(of: "combineLatest") {
// 1
let publisher1 = PassthroughSubject<Int, Never>()
let publisher2 = PassthroughSubject<String, Never>()

// 2
publisher1
.combineLatest(publisher2)
.sink(receiveCompletion: { _ in print("Completed") },
receiveValue: { print("P1: \($0), P2: \($1)") })
.store(in: &subscriptions)

// 3
publisher1.send(1)
publisher1.send(2)

publisher2.send("a")
publisher2.send("b")

publisher1.send(3)

publisher2.send("c")

// 4
publisher1.send(completion: .finished)
publisher2.send(completion: .finished)
}

raywenderlich.com 134
Combine Chapter 5: Combining Operators

This code reproduces the above diagram. You:

1. Create two PassthroughSubjects. The first accepts integers with no errors,

while the second accepts strings with no errors.

2. Combine the latest emissions of publisher2 with publisher1. You may combine
up to four different publishers using different overloads of combineLatest.

3. Send 1 and 2 to publisher1, then "a" and "b" to publisher2, then 3 to

publisher1 and finally "c" to publisher2.

4. Send a completion event to both publisher1 and publisher2.

Run the playground and take a look at the output in your console:

——— Example of: combineLatest ———

P1: 2, P2: a
P1: 2, P2: b
P1: 3, P2: b
P1: 3, P2: c
Completed

You might notice that the 1 emitted from publisher1 is never pushed through
combineLatest. That’s because combineLatest only combines once every publisher
emits at least one value. Here, that condition is true only after "a" emits, at which
point the latest emitted value from publisher1 is 2. That’s why the first emission is
(2, "a").

zip
You’ll finish with one final operator for this chapter: zip. You might recognize this
one from the Swift standard library method with the same name on Sequence types.

This operator works similarly, emitting tuples of paired values in the same indexes. It
waits for each publisher to emit an item, then emits a single tuple of items after all
publishers have emitted an value at the current index.

raywenderlich.com 135
Combine Chapter 5: Combining Operators

This means that if you are zipping two publishers, you’ll get a single tuple emitted
every time both publishers emit a value.

Add the following code to your playground to try this example:

example(of: "zip") {
// 1
let publisher1 = PassthroughSubject<Int, Never>()
let publisher2 = PassthroughSubject<String, Never>()

// 2
publisher1
.zip(publisher2)
.sink(receiveCompletion: { _ in print("Completed") },
receiveValue: { print("P1: \($0), P2: \($1)") })
.store(in: &subscriptions)

// 3
publisher1.send(1)
publisher1.send(2)
publisher2.send("a")
publisher2.send("b")
publisher1.send(3)
publisher2.send("c")
publisher2.send("d")

// 4
publisher1.send(completion: .finished)
publisher2.send(completion: .finished)
}

raywenderlich.com 136
Combine Chapter 5: Combining Operators

In this final example, you:

1. Create two PassthroughSubjects, where the first accepts integers and the
second accepts strings. Both cannot emit errors.

2. Zip publisher1 with publisher2, pairing their emissions once they each emit a
new value.

3. Send 1 and 2 to publisher1, then "a" and "b" to publisher2, then 3 to

publisher1 again, and finally "c" and "d" to publisher2.

4. Complete both publisher1 and publisher2.

Run your playground a final time and take a look at the debug console:

——— Example of: zip ———

P1: 1, P2: a
P1: 2, P2: b
P1: 3, P2: c
Completed

Notice how each emitted value "waits" for the other zipped publisher to emit an
value. 1 waits for the first emission from the second publisher, so you get (1, "a").
Likewise, 2 waits for the next emission from the second publisher, so you get (2,
"b"). The last emitted value from the second publisher, "d", is ignored since there is
no corresponding emission from the first publisher to pair with.

Key points
In this chapter, you learned how to take different publishers and create meaningful
combinations with them. More specifically, you learned that:

• You can use the prepend and append families of operators to add emissions from
one publisher before or after the original publisher.

• While switchToLatest is relatively complex, it’s extremely useful. It takes a

publisher that emits publishers, switches to the latest publisher and cancels the
subscription to the previous publisher.

• merge(with:) lets you interleave values from multiple publishers.

• combineLatest emits the latest values of all combined publishers whenever any of
them emit a value, once all of the combined publishers have emitted at least one
value.

raywenderlich.com 137
Combine Chapter 5: Combining Operators

• zip pairs emissions from different publishers, emitting a tuple of pairs after all
publishers have emitted an value.

• You can mix combination operators to create interesting and complex

relationships between publishers and their emissions.

Where to go from here?

This has been quite a long chapter, but it includes some of the most useful and
involved operators Combine has to offer. Kudos to you for making it this far!

No challenges this time. Try to experiment with all of the operators you’ve learned
thus far, there are plenty of use cases to play with.

You have two more groups of operators to learn about in the next two chapters:
"Time Manipulation Operators" and "Sequence Operators," so move on to the next
chapter!

raywenderlich.com 138
6 Chapter 6: Time
Manipulation Operators
By Florent Pillet

Timing is everything. The core idea behind reactive programming is to model

asynchronous event flow over time. In this respect, the Combine framework provides
a range of operators that allow you to deal with time. In particular, how sequences
react to and transform values over time.

As you’ll see throughout this chapter, managing the time dimension of your
sequence of values is easy and straightforward. It’s one of the great benefits of using
a framework like Combine.

Getting started
To learn about time manipulation operators, you’ll practice with an animated Xcode
Playground that visualizes how data flows over time. This chapter comes with a
starter playground you’ll find in the projects folder.

The playground is divided into several pages. You’ll use each page to exercise one or
more related operators. It also includes some ready-made classes, functions and
sample data that’ll come in handy to build the examples.

If you have the playground set to show rendered markup, at the bottom of each page
there will be a Next link that you can click to go to the next page.

Note: To toggle showing rendered markup on and off, select Editor ▸ Show
Rendered/Raw Markup from the menu.

raywenderlich.com 139
Combine Chapter 6: Time Manipulation Operators

You can also select the page you want from the Project navigator in the left sidebar
or even the jump bar at the top of the page. There are lots of ways to get around in
Xcode!

Look at Xcode, you can see controls at top-right of the window:

1. Make sure the left sidebar button is enabled so you can see the list of Playground
pages.

2. Show the editor with Live View. This will display a live view of the sequences you
build in code. This is where the real action will happen! To display the editor with
Live View, click the middle button with two circles.

Also, remember that playgrounds can run manually or automatically. Showing the
Debug area and configuring the playground for manual / automatic run is done using
the controls at bottom left of the editor:

3. Click the vertical arrow at left to show/hide the Debug area. This is where the
debug prints go.

4. Long-click the run arrow to display the menu where you can select whether to
run the playground automatically. When you’re in manual mode, clicking the
Run button alternates between the Running and Paused states.

raywenderlich.com 140
Combine Chapter 6: Time Manipulation Operators

Playground not working?

From time to time Xcode may “act up” and not run properly your playground. If this
happens to you, open the Preferences dialog in Xcode and select the Locations tab.
Click the arrow next to the Derived Data location, depicted by the red circled 1 in the
screenshot below. It shows the DerivedData folder in the Finder.

Quit Xcode, move the DerivedData folder to trash then launch Xcode again. Your
playground should now work properly!

Shifting time
Every now and again you need time traveling. While Combine can’t help with fixing
your past relationship mistakes, it can freeze time for a little while to let you wait
until self-cloning is available.

The most basic time manipulation operator delays values emitted by a publisher so
that you see them later than they actually occur.

The delay(for:tolerance:scheduler:options) operator time-shifts a whole

sequence of values: Every time the upstream publisher emits a value, delay keeps it
for a while then emits it after the delay you asked for, on the Scheduler you specified.

Open the Delay playground page to get started. The first thing you’ll see is that
you’re not only importing the Combine framework but also SwiftUI! This animated
playground is built with SwiftUI and Combine. When you feel in an adventurous
mood, it’ll be a good idea to peruse through the code in the Sources folder.

But first things first. Start by defining a couple of constants you’ll be able to tweak
later:

let valuesPerSecond = 1.0

let delayInSeconds = 1.5

raywenderlich.com 141
Combine Chapter 6: Time Manipulation Operators

You’re going to create a publisher that emits one value every second, then delay it by
1.5 seconds and display both timelines simultaneously to compare them. Once you
complete the code on this page, you’ll be able to adjust the constants and watch
results in the timelines.

Next, create the publishers you need:

// 1
let sourcePublisher = PassthroughSubject<Date, Never>()

// 2
let delayedPublisher =
sourcePublisher.delay(for: .seconds(delayInSeconds), scheduler:
DispatchQueue.main)

// 3
let subscription = Timer
.publish(every: 1.0 / valuesPerSecond, on: .main, in: .common)
.autoconnect()
.subscribe(sourcePublisher)

Breaking this code down:

1. sourcePublisher is a simple Subject which you’ll feed dates emitted by a

Timer. The type of values is of little importance here. You only care about
imaging when a value is emitted by a publisher, and when the delayed value
shows up.

2. delayedPublisher will delay values emitted by sourcePublisher and emit

them on the main scheduler. You’ll learn all about schedulers in Chapter 17,
“Schedulers.” For now, specify that values must end up on the main queue, ready
for display to consume them.

3. Create a timer that delivers one value per second on the main thread. Start it
immediately with autoconnect() and feed the values it emits through the
sourcePublisher subject.

Note: This particular timer is a Combine extension on the Foundation Timer

class. It takes a RunLoop and RunLoop.Mode, and not a DispatchQueue as you
may expect. You’ll learn all about timers in Chapter 11, “Timers.” Also, timers
are part of a class of publishers that are connectable. This means they need to
be connected to before they start emitting values. You use autoconnect()
which immediately connects upon the first subscription.

raywenderlich.com 142
Combine Chapter 6: Time Manipulation Operators

You’re getting to the part where you create the two views that will let you visualize
events. Add this code to your playground:

// 4
let sourceTimeline = TimelineView(title: "Emitted values (\
(valuesPerSecond) per sec.):")

// 5
let delayedTimeline = TimelineView(title: "Delayed values (with
a \(delayInSeconds)s delay):")

// 6
let view = VStack(spacing: 50) {
sourceTimeline
delayedTimeline
}

// 7
PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

In this code, you:

4. Create a TimelineView that will display values emitted by the timer.

TimelineView is a SwiftUI view, its code can be found at Sources/Views.swift.

5. Create another TimelineView to display delayed values.

6. Create a simple SwiftUI vertical stack to display both timelines one above the
other.

7. Set up the live view for this playground page.

At this stage, you see two empty timelines on the screen. You now need to feed them
with the values emitted by each publisher! Add this final code to the playground:

sourcePublisher.displayEvents(in: sourceTimeline)
delayedPublisher.displayEvents(in: delayedTimeline)

In this last piece of code, you connect the source and delayed publishers to their
respective timelines to display events.

raywenderlich.com 143
Combine Chapter 6: Time Manipulation Operators

Once you save these source changes, Xcode will recompile the playground code and...
look at the Live View pane! Finally!

You’ll see two timelines. The top timeline shows values emitted by the timer. The
bottom timeline shows the same values, delayed. The numbers inside the circles
reflect the count of emitted values, not their actual value.

Note: As exciting as it is to see a live observable diagram, it might confuse at

first. Static timelines usually have their values aligned to the left. But, if you
think twice about it, they also have the most recent ones on the right side just
as the animated diagrams you observe right now.

Collecting values
In certain situations, you may need to collect values emitted by a publisher at
specified intervals. This is a form of buffering that can be useful. For example, when
you want to average a group of values over short periods of time and output the
average.

raywenderlich.com 144
Combine Chapter 6: Time Manipulation Operators

Switch to the Collect page by clicking the Next link at the bottom, or by selecting it
in the Project navigator or jump bar.

As in the previous example, you’ll begin with some constants:

let valuesPerSecond = 1.0

let collectTimeStride = 4

Of course, reading these constants gives you an idea of where this is all going. Create
your publishers now:

// 1
let sourcePublisher = PassthroughSubject<Date, Never>()

// 2
let collectedPublisher = sourcePublisher
.collect(.byTime(DispatchQueue.main, .seconds(collectTimeStrid
e)))

Like in the previous example, you:

1. Set up a source publisher — a subject that emits values published by a timer.

2. Create a collectedPublisher which collects values emitted during strides of

collectTimeStride using the collect operator. The operator emits these
groups of values as arrays on the specified scheduler: DispatchQueue.main.

Note: You might remember learning about the collect operator in Chapter 3,
“Transforming Operators,” where you used a simple number to define how to
group values together. The overload of collect you just used accepts a
strategy for grouping values; in this case, by time.

You’ll use a Timer again to emit values at regular intervals as you did for the delay
operator:

let subscription = Timer

.publish(every: 1.0 / valuesPerSecond, on: .main, in: .common)
.autoconnect()
.subscribe(sourcePublisher)

Next, create the timeline views like in the previous example. Then, set the
playground’s live view to a vertical stack showing the source timeline and the
timeline of collected values:

raywenderlich.com 145
Combine Chapter 6: Time Manipulation Operators

let sourceTimeline = TimelineView(title: "Emitted values:")

let collectedTimeline = TimelineView(title: "Collected values
(every \(collectTimeStride)s):")

let view = VStack(spacing: 40) {

sourceTimeline
collectedTimeline
}

PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

Finally, feed the timelines with events from both publishers:

sourcePublisher.displayEvents(in: sourceTimeline)
collectedPublisher.displayEvents(in: collectedTimeline)

You’re done! Now look at the live view for a while:

You see values emitted at regular intervals on the Emitted values timeline. Below it,
you see that every four seconds the Collected values timeline displays a single
value. But what is it?

You may have guessed that the value is an array of values received during the last
four seconds. You can improve the display to see what’s actually in it! Go back to the
line where you created the collectedPublisher object. Add the use of the flatMap
operator just below it, so it looks like this:

let collectedPublisher = sourcePublisher

.collect(.byTime(DispatchQueue.main, .seconds(collectTimeStrid
e)))
.flatMap { dates in dates.publisher }

raywenderlich.com 146
Combine Chapter 6: Time Manipulation Operators

Do you remember your friendly flatMap you learned about in Chapter 3,

“Transforming Operators?” You’re putting it to good use here: Every time collect
emits a group of values it collected, flatMap breaks it down again to individual
values but emitted all at the same time. To this end, it uses the publisher
extension of Collection that turns a sequence of values into a Publisher, emitting
immediately all values in the sequence as individual values.

Now, look at the effect it has on the timeline:

You can now see that, every four seconds, collect emits an array of values collected
during the last time interval.

Collecting values (part 2)

The second option offered by the collect(_:options:) operator allows you to keep
collecting values at regular intervals. It also allows you to limit the number of
collected values.

Staying on the same Collect page, and add a new constant right below
collectTimeStride at the top:

let collectMaxCount = 2

raywenderlich.com 147
Combine Chapter 6: Time Manipulation Operators

Next, create a new publisher after collectedPublisher:

let collectedPublisher2 = sourcePublisher

.collect(.byTimeOrCount(DispatchQueue.main,
.seconds(collectTimeStride),
collectMaxCount))
.flatMap { dates in dates.publisher }

This time, you are using the .byTimeOrCount(Context,

Context.SchedulerTimeType.Stride, Int) variant to collect up to
collectMaxCount values at a time. What does this mean? Keep adding code and
you’ll find out!

Add a new TimelineView for the second collect publisher in between

collectedTimeline and let view = VStack...:

let collectedTimeline2 = TimelineView(title: "Collected values

(at most \(collectMaxCount) every \(collectTimeStride)s):")

And of course add it to the list of stacked views, so view looks like this:

let view = VStack(spacing: 40) {

sourceTimeline
collectedTimeline
collectedTimeline2
}

Finally, make sure it displays the events it emits in the timeline by adding the
following at the end of your playground:

collectedPublisher2.displayEvents(in: collectedTimeline2)

raywenderlich.com 148
Combine Chapter 6: Time Manipulation Operators

Now, let this timeline run for a while so you can witness the difference:

You can see here that the second timeline is limiting its collection to two values at a
time, as required by the collectMaxCount constant. It’s a useful tool to know about!

Holding off on events

When coding user interfaces, you frequently deal with text fields. Wiring up text field
contents to an action using Combine is a common task. For example, you may want
to send a search URL request that returns a list of items matching what’s typed in the
text field.

But of course, you don’t want to send a request every time your user types a single
letter! You need some kind of mechanism to help pick up on typed text only when
the user is done typing for a while.

Combine offers two operators that can help you here: debounce and throttle. Let’s
explore them!

raywenderlich.com 149
Combine Chapter 6: Time Manipulation Operators

Debounce
Switch to the playground page named Debounce. Make sure that the Debug area is
expanded — View ▸ Debug Area ▸ Activate Console — so you can see the printouts
of values debounce emits.

Start by creating a couple of publishers:

// 1
let subject = PassthroughSubject<String, Never>()

// 2
let debounced = subject
.debounce(for: .seconds(1.0), scheduler: DispatchQueue.main)
// 3
.share()

In this code, you:

1. Create a source publisher which will emit strings.

2. Use debounce to wait for one second on emissions from subject. Then, it will
send the last value sent in that one-second interval, if any. This has the effect of
allowing a max of one value per second to be sent.

3. You are going to subscribe multiple times to debounced. To guarantee

consistency of the results, you use share() to create a single subscription point
to debounce that will show the same results at the same time to all subscribers.

Note: Diving into the share() operator is out of the scope of this chapter. Just
remember that it is helpful when a single subscription to a publisher is
required to deliver the same results to multiple subscribers. You’ll learn more
about share() in Chapter 13, “Resource Management.”

For these next few examples, you will use a set of data to simulate a user typing text
in a text field. Don’t type this in — it’s already been implemented in Sources/
Data.swift for you:

public let typingHelloWorld: [(TimeInterval, String)] = [

(0.0, "H"),
(0.1, "He"),
(0.2, "Hel"),
(0.3, "Hell"),
(0.5, "Hello"),

raywenderlich.com 150
Combine Chapter 6: Time Manipulation Operators

(0.6, "Hello "),

(2.0, "Hello W"),
(2.1, "Hello Wo"),
(2.2, "Hello Wor"),
(2.4, "Hello Worl"),
(2.5, "Hello World")
]

The simulated user starts typing at 0.0 seconds, pauses after 0.6 seconds, and
resumes typing at 2.0 seconds.

Note: The time values you’ll see in the Debug area may be offset by one or two
tenth of a second. Since you’ll be emitting values on the main queue using
DispatchQueue.asyncAfter(), you are guaranteed a minimum time interval
between values but maybe not exactly what you requested.

In the playground’s Debounce page, create a couple of timelines to visualize events,

and wire them up to the two publishers:

let subjectTimeline = TimelineView(title: "Emitted values")

let debouncedTimeline = TimelineView(title: "Debounced values")

let view = VStack(spacing: 100) {

subjectTimeline
debouncedTimeline
}

PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

subject.displayEvents(in: subjectTimeline)
debounced.displayEvents(in: debouncedTimeline)

You are now familiar with this playground structure where you stack timelines on the
screen and connect them to the publishers for event display.

This time, you’re going to do something more: Print values emitted by each
publisher, along with the time (since start) at which they show up. This will help you
figure out what’s happening.

Add this code:

let subscription1 = subject

.sink { string in
print("+\(deltaTime)s: Subject emitted: \(string)")
}

raywenderlich.com 151
Combine Chapter 6: Time Manipulation Operators

let subscription2 = debounced

.sink { string in
print("+\(deltaTime)s: Debounced emitted: \(string)")
}

Each subscription prints the values it receives, along with the time since start.
deltaTime is a dynamic global variable defined in Sources/DeltaTime.swift which
formats the time difference since the playground started running.

Now you need to feed your subject with data. This time you’re going to use a pre-
made data source that simulates a user typing text. It’s all defined in Sources/
Data.swift and you can modify it at will. Take a look, you’ll see that it’s a simulation
of a user typing the words “Hello World”.

Add this code to the end of the playground page:

subject.feed(with: typingHelloWorld)

The feed(with:) method takes a data set and sends data to the given subject at
pre-defined time intervals. A handy tool for simulations and mocking data input! You
may want to keep this around when you write tests for your code because you will
write tests, won’t you?

Now look at the result:

raywenderlich.com 152
Combine Chapter 6: Time Manipulation Operators

You see the emitted values at the top, there are 11 strings total being pushed to the
sourcePublisher. You can see that the user paused between the two words. This is
the time where debounce emitted the captured input.

You can confirm this by looking at the debug area where the prints show up:

+0.0s: Subject emitted: H

+0.1s: Subject emitted: He
+0.2s: Subject emitted: Hel
+0.3s: Subject emitted: Hell
+0.5s: Subject emitted: Hello
+0.6s: Subject emitted: Hello
+1.6s: Debounced emitted: Hello
+2.1s: Subject emitted: Hello W
+2.1s: Subject emitted: Hello Wo
+2.4s: Subject emitted: Hello Wor
+2.4s: Subject emitted: Hello Worl
+2.7s: Subject emitted: Hello World
+3.7s: Debounced emitted: Hello World

As you can see, at 0.6 seconds the user pauses and resumes typing only at 2.1
seconds. Meanwhile, you configured debounce to wait for a one-second pause. It
obliges (at 1.6 seconds) and emits the latest received value.

Same around the end where typing ends at 2.7 seconds and debounce kicks in one
second later at 3.7 seconds. Cool!

Note: One thing to watch out for is the publisher’s completion. If your
publisher completes right after the last value was emitted, but before the time
configured for debounce elapses, you will never see the last value in the
debounced publisher!

Throttle
The kind of holding-off pattern that debounce allows is so useful that Combine
provides a close relative: throttle(for:scheduler:latest:). It’s very close to
debounce, but the differences justify the need for two operators.

Switch to the Throttle page in the playground and get coding. First, you need a
constant, as usual:

let throttleDelay = 1.0

// 1

raywenderlich.com 153
Combine Chapter 6: Time Manipulation Operators

let subject = PassthroughSubject<String, Never>()

// 2
let throttled = subject
.throttle(for: .seconds(throttleDelay), scheduler:
DispatchQueue.main, latest: false)
// 3
.share()

Breaking down this code:

1. The source publisher will emit strings.

2. Your throttled subject will now only emit the first value received from subject
during each one-second interval because you set latest to false.

3. Like in the previous operator, debounce, adding the share() operator here
guarantees that all subscribers see the same output at the same time from the
throttled subject.

Create a couple timelines to visualize events, and wire them up to the two
publishers:

let subjectTimeline = TimelineView(title: "Emitted values")

let throttledTimeline = TimelineView(title: "Throttled values")

let view = VStack(spacing: 100) {

subjectTimeline
throttledTimeline
}

PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

subject.displayEvents(in: subjectTimeline)
throttled.displayEvents(in: throttledTimeline)

Now you also want to print the values each publisher emits, to better understand
what’s going on. Add this code:

let subscription1 = subject

.sink { string in
print("+\(deltaTime)s: Subject emitted: \(string)")
}

let subscription2 = throttled

.sink { string in
print("+\(deltaTime)s: Throttled emitted: \(string)")
}

raywenderlich.com 154
Combine Chapter 6: Time Manipulation Operators

Again, you‘re going to feed your source publisher with a simulated “Hello World”
user input. Add this final line to your playground page:

subject.feed(with: typingHelloWorld)

Your playground is ready! You can now see what’s happening in the live view:

Isn’t this puzzling? It doesn’t look that much different from the previous debounce
output! Well, it actually is.

First, look closely at both. You can see that the values emitted by throttle have
slightly different timing.

Second, to get a better picture of what’s happening, look at the debug console:

+0.0s: Subject emitted: H

+0.1s: Subject emitted: He
+0.2s: Subject emitted: Hel
+0.3s: Subject emitted: Hell
+0.5s: Subject emitted: Hello
+0.6s: Subject emitted: Hello
+1.0s: Throttled emitted: H
+2.2s: Subject emitted: Hello W
+2.2s: Subject emitted: Hello Wo
+2.2s: Subject emitted: Hello Wor
+2.4s: Subject emitted: Hello Worl
+2.7s: Subject emitted: Hello World
+3.0s: Throttled emitted: Hello W

raywenderlich.com 155
Combine Chapter 6: Time Manipulation Operators

This is clearly different! You can see a few interesting things here:

• At 1.0 second, throttle kicks in and emits “H”. Remember you asked it to send
you the first value after one second.

• At 2.2 seconds, typing resumes. You can see that at this time, throttle didn’t
emit anything. This is because no new value had been received from the source
publisher.

• At 3.0 seconds, after typing completes, throttle kicks in again and outputs the
first value again, i.e., the value at 2.2 seconds.

There you have the fundamental difference between debounce and throttle:

• debounce waits for a pause in values it receives, then emits the latest one after the
specified interval.

• throttle waits for the specified interval, then emits either the first or the latest of
the values it received during that interval. It doesn’t care about pauses.

To see what happens when you change latest to true, change your implementation
of throttled to the following:

let throttled = subject

.throttle(for: .seconds(throttleDelay), scheduler:
DispatchQueue.main, latest: true)
.share()

Now, observe the resulting output in the debug area:

+0.0s: Subject emitted: H

+0.1s: Subject emitted: He
+0.2s: Subject emitted: Hel
+0.3s: Subject emitted: Hell
+0.5s: Subject emitted: Hello
+0.6s: Subject emitted: Hello
+1.0s: Throttled emitted: Hello
+2.0s: Subject emitted: Hello W
+2.3s: Subject emitted: Hello Wo
+2.3s: Subject emitted: Hello Wor
+2.6s: Subject emitted: Hello Worl
+2.6s: Subject emitted: Hello World
+3.0s: Throttled emitted: Hello World

raywenderlich.com 156
Combine Chapter 6: Time Manipulation Operators

The throttled output occurs at precisely 1.0 second and 3.0 seconds. Compare this
with the output from debounce from the earlier example:

...
+1.6s: Debounced emitted: Hello
...
+3.7s: Debounced emitted: Hello World

The output is the same, but debounce is delayed from the pause.

Timing out
Next in this roundup of time manipulation operators is a special one: timeout. Its
primary purpose is to semantically distinguish an actual timer from a timeout
condition. Therefore, when a timeout operator fires, it either completes the publisher
or emits an error you specify. In both cases, the publisher terminates.

Switch to the Timeout playground page. Begin by adding this code:

let subject = PassthroughSubject<Void, Never>()

// 1
let timedOutSubject = subject.timeout(.seconds(5), scheduler:
DispatchQueue.main)

1. The timedOutSubject publisher will time-out after five seconds without the
upstream publisher emitting any value. This form of timeout forces a publisher
completion without any failure.

You now need to add your timeline, as well as a button to let you trigger events:

let timeline = TimelineView(title: "Button taps")

let view = VStack(spacing: 100) {

// 1
Button(action: { subject.send() }) {
Text("Press me within 5 seconds")
}
timeline
}

PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

timedOutSubject.displayEvents(in: timeline)

raywenderlich.com 157
Combine Chapter 6: Time Manipulation Operators

1. This is a new one! You add a button above the timeline, which sends a new value
through the source subject when pressed. The action closure will execute every
time you press the button.

Note: Have you noticed you’re using a subject that emits Void values? Yes, this
is totally legitimate! It signals that something happened. But, there is no
particular value to carry. So, you simply use Void as the value type. This is
such a common case that Subject has an extension with a send() function
that takes no parameter in case the Output type is Void. This saves you from
writing the awkward subject.send(()) statement!

Your playground page is now complete. Watch it run and do nothing: the timeout
will trigger after five seconds and complete the publisher.

Now, run it again. This time, keep pressing the button at less-than-five-seconds
intervals. The publisher never completes because timeout doesn’t kick in.

Of course, the simple completion of a publisher is not what you want in many cases.
Instead, you need the timeout publisher to send a failure so you can accurately take
action in this case.

Go to the top of the playground page and define the error type you want:

enum TimeoutError: Error {

case timedOut
}

raywenderlich.com 158
Combine Chapter 6: Time Manipulation Operators

Next, modify the definition of subject to change the error type from Never to
TimeoutError. Your code should look like this:

let subject = PassthroughSubject<Void, TimeoutError>()

Now you need to modify the call to timeout. The complete signature for this
operator is timeout(_:scheduler:options:customError:). Here is your chance to
provide your custom error type!

Modify the line that creates the timedOutSubjectto this:

let timedOutSubject = subject.timeout(.seconds(5),

scheduler:
DispatchQueue.main,
customError:
{ .timedOut })

Now when you run the playground and don’t press the button for five seconds, you
can see that the timedOutSubject emits a failure.

Now that the time allocated to this operator ran out, let’s move to the last one in this
section.

Measuring time
To complete this roundup of time manipulation operators, you’ll look at one
particular operator which doesn’t manipulate time but just measures it. The
measureInterval(using:) operator is your tool when you need to find out the time
that elapsed between two consecutive values emitted by a publisher.

raywenderlich.com 159
Combine Chapter 6: Time Manipulation Operators

Switch to the MeasureInterval playground page. Begin by creating a couple of

publishers:

let subject = PassthroughSubject<String, Never>()

// 1
let measureSubject = subject.measureInterval(using:
DispatchQueue.main)

The measureSubject will emit measurements on the scheduler you specify. Here,
the main queue.

Now as usual, add a couple of timelines:

let subjectTimeline = TimelineView(title: "Emitted values")

let measureTimeline = TimelineView(title: "Measured values")

let view = VStack(spacing: 100) {

subjectTimeline
measureTimeline
}

PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

subject.displayEvents(in: subjectTimeline)
measureSubject.displayEvents(in: measureTimeline)

Finally, here comes the interesting part. Print out values emitted by both publishers
and then feed the subject:

let subscription1 = subject.sink {

print("+\(deltaTime)s: Subject emitted: \($0)")
}

let subscription2 = measureSubject.sink {

print("+\(deltaTime)s: Measure emitted: \($0)")
}

subject.feed(with: typingHelloWorld)

Run your playground and have a look at the debug area! This is where you see what
measureInterval(using:) emits:

+0.0s: Subject emitted: H

+0.0s: Measure emitted: Stride(magnitude: 16818353)
+0.1s: Subject emitted: He
+0.1s: Measure emitted: Stride(magnitude: 87377323)
+0.2s: Subject emitted: Hel

raywenderlich.com 160
Combine Chapter 6: Time Manipulation Operators

+0.2s: Measure emitted: Stride(magnitude: 111515697)

+0.3s: Subject emitted: Hell
+0.3s: Measure emitted: Stride(magnitude: 105128640)
+0.5s: Subject emitted: Hello
+0.5s: Measure emitted: Stride(magnitude: 228804831)
+0.6s: Subject emitted: Hello
+0.6s: Measure emitted: Stride(magnitude: 104349343)
+2.2s: Subject emitted: Hello W
+2.2s: Measure emitted: Stride(magnitude: 1533804859)
+2.2s: Subject emitted: Hello Wo
+2.2s: Measure emitted: Stride(magnitude: 154602)
+2.4s: Subject emitted: Hello Wor
+2.4s: Measure emitted: Stride(magnitude: 228888306)
+2.4s: Subject emitted: Hello Worl
+2.4s: Measure emitted: Stride(magnitude: 138241)
+2.7s: Subject emitted: Hello World
+2.7s: Measure emitted: Stride(magnitude: 333195273)

The values are a bit puzzling, aren’t they? It turns out that, as per the
documentation, the type of the value measureInterval emits is “the time interval of
the provided scheduler”. In the case of DispatchQueue, the TimeInterval is defined
as “A DispatchTimeInterval created with the value of this type in nanoseconds.”.

What you are seeing here is a count, in nanoseconds, between each consecutive
value received from the source subject. You can now fix the display to show more
readable values. Modify the code that prints values from measureSubject like so:

let subscription2 = measureSubject.sink {

print("+\(deltaTime)s: Measure emitted: \(Double($0.magnitude)
/ 1_000_000_000.0)")
}

Now, you’ll see values in seconds.

But what happens if you use a different scheduler? You can try it using a RunLoop
instead of a DispatchQueue!

Note: You will explore the RunLoop and DispatchQueue schedulers in depth in
Chapter 17, “Schedulers.”

Back to the top of the file, create a second subject that uses a RunLoop:

let measureSubject2 = subject.measureInterval(using:

RunLoop.main)

raywenderlich.com 161
Combine Chapter 6: Time Manipulation Operators

You don’t need to bother wiring up a new timeline view, because what’s interesting is
the debug output. Add this third subscription to your code:

let subscription3 = measureSubject2.sink {

print("+\(deltaTime)s: Measure2 emitted: \($0)")
}

Now, you’ll see the output from the RunLoop scheduler as well, with magnitudes
directly expressed in seconds:

+0.0s: Subject emitted: H

+0.0s: Measure emitted: 0.016503769
+0.0s: Measure2 emitted: Stride(magnitude: 0.015684008598327637)
+0.1s: Subject emitted: He
+0.1s: Measure emitted: 0.087991755
+0.1s: Measure2 emitted: Stride(magnitude: 0.08793699741363525)
+0.2s: Subject emitted: Hel
+0.2s: Measure emitted: 0.115842671
+0.2s: Measure2 emitted: Stride(magnitude: 0.11583995819091797)
...

The scheduler you use for measurement is really up to your personal taste. It is
generally a good idea to stick with DispatchQueue for everything. But that’s your
personal choice!

Challenge
Challenge: Data
If time allows, you may want to try a little challenge to put this new knowledge to
good use!

Open the starter challenge playground in the projects/challenge folder. You see
some code waiting for you:

• A subject that emits integers.

• A function call that feeds the subject with mysterious data.

In between those parts, your challenge is to:

• Group data by batches of 0.5 seconds.

• Turn the grouped data into a string.

raywenderlich.com 162
Combine Chapter 6: Time Manipulation Operators

• If there is a pause longer than 0.9 seconds in the feed, print the emoji. Hint:
Create a second publisher for this step and merge it with the first publisher in your
subscription.

• Print it.

Note: To convert an Int to a Character, you can do something like

Character(Unicode.Scalar(value)!).

If you code this challenge correctly, you’ll see a sentence printed in the Debug area.
What is it? "

Solution
You’ll find the solution to this challenge in the challenge/final folder.

Here’s the solution code:

// 1
let strings = subject
// 2
.collect(.byTime(DispatchQueue.main, .seconds(0.5)))
// 3
.map { array in
String(array.map { Character(Unicode.Scalar($0)!) })
}

// 4
let spaces = subject.measureInterval(using: DispatchQueue.main)
.map { interval in
// 5
interval > 0.9 ? " " : ""
}

// 6
let subscription = strings
.merge(with: spaces)
// 7
.filter { !$0.isEmpty }
.sink {
// 8
print($0)
}

raywenderlich.com 163
Combine Chapter 6: Time Manipulation Operators

From the top, you:

1. Create a first publisher derived from the subject which emits the strings.

2. Use collect() using the .byTime strategy to group data in 0.5 seconds batches.
"
3. Map each integer value to a Unicode scalar, then to a character and then turn the
whole lot into a string using map.

4. Create a second publisher

" derived from the subject, which measures the intervals
between each character.

5. If the interval is greater than 0.9 seconds, map the value to the emoji.
Otherwise, map it to an empty string.

6. The final publisher is a merge of both strings and the emoji.

7. Filter out empty strings for better display.

8. Print the result!

Your solution might have been subtly different, and that’s OK. As long as you met the
requirements, you get the W!

Running the playground with this solution will print the following output to the
console:

Combine

is

cool!

raywenderlich.com 164
Combine Chapter 6: Time Manipulation Operators

Key points
In this chapter, you looked at time from a different angle. In particular, you learned
that:

• Combine’s handling of asynchronous events extends to manipulating time itself.

• Even though it doesn’t provide time-traveling options, the framework has

operators that let you abstract work over long periods of time, rather than just
handling discrete events.

• Time can be shifted using the delay operator.

• You can manage the flow of values over time like a dam and release them by
chunks using collect.

• Picking individual values over time is easy with debounce and throttle.

• Not letting time run out is the job of timeout.

• Time can be measured with measureInterval.

Where to go from here?

This was a lot to learn. To put events in their right order, move along to the next
chapter and learn about sequence operators!

raywenderlich.com 165
7 Chapter 7: Sequence
Operators
By Shai Mishali

At this point, you know most of the operators that Combine has to offer! How great is
that? There's one more category for you to dig into: Sequence Operators.

Sequence operators are easiest to understand when you realize that publishers are
just sequences themselves. Sequence operators work with the collection of a
publisher’s values, much like an array or set — which, of course, are just finite
sequences!

With that in mind, sequence operators mostly deal with the sequence as a whole and
not with individual values, as other operator categories do.

Many of the operators in this category have nearly identical names and behaviors as
their counterparts in the Swift standard library.

Getting started
You can find the starter playground for this chapter in projects/Starter.playground.
Throughout this chapter, you’ll add code to your playground and run it to see how
these different sequence operators manipulate your publisher. You’ll use the print
operator to log all publishing events.

raywenderlich.com 166
Combine Chapter 7: Sequence Operators

Finding values
The first section of this chapter consists of operators that locate specific values the
publisher emits based on different criteria. These are similar to the collection
methods in the Swift standard library.

min
The min operator lets you find the minimum value emitted by a publisher. It's greedy,
which means it must wait for the publisher to send a .finished completion event.
Once the publisher completes, only the minimum value is emitted by the operator:

Add the following example to your playground to try min:

example(of: "min") {
// 1
let publisher = [1, -50, 246, 0].publisher

// 2
publisher
.print("publisher")
.min()
.sink(receiveValue: { print("Lowest value is \($0)") })
.store(in: &subscriptions)
}

raywenderlich.com 167
Combine Chapter 7: Sequence Operators

In this code, you:

1. Create a publisher emitting four different numbers.

2. Use the min operator to find the minimum number emitted by the publisher and
print that value.

Run your playground and you'll see the following output in the console:

——— Example of: min ———

publisher: receive subscription: ([1, -50, 246, 0])
publisher: request unlimited
publisher: receive value: (1)
publisher: receive value: (-50)
publisher: receive value: (246)
publisher: receive value: (0)
publisher: receive finished
Lowest value is -50

As you can see, the publisher emits all its values and finishes, then min finds the
minimum and sends it downstream to sink to print it out.

But wait, how does Combine know which of these numbers is the minimum? Well,
that's thanks to the fact numeric values conform to the Comparable protocol. You
can use min() directly, without any arguments, on publishers that emit Comparable-
conforming types.

But what happens if your values don't conform to Comparable? Luckily, you can
provide your own comparator closure using the min(by:) operator.

Consider the following example, where your publisher emits many pieces of Data and
you'd like to find the smallest one.

Add the following code to your playground:

example(of: "min non-Comparable") {

// 1
let publisher = ["12345",
"ab",
"hello world"]
.compactMap { $0.data(using: .utf8) } // [Data]
.publisher // Publisher<Data, Never>

// 2
publisher
.print("publisher")
.min(by: { $0.count < $1.count })
.sink(receiveValue: { data in
// 3

raywenderlich.com 168
Combine Chapter 7: Sequence Operators

let string = String(data: data, encoding: .utf8)!

print("Smallest data is \(string), \(data.count) bytes")
})
.store(in: &subscriptions)
}

In the above code:

1. You create a publisher that emits three Data objects created from various strings.

2. Since Data doesn't conform to Comparable, you use the min(by:) operator to
find the Data object with the smallest number of bytes.

3. You convert the smallest Data object back to a string and print it out.

Run your playground and you'll see the following in your console:

——— Example of: min non-Comparable ———

publisher: receive subscription: ([5 bytes, 2 bytes, 11 bytes])
publisher: request unlimited
publisher: receive value: (5 bytes)
publisher: receive value: (2 bytes)
publisher: receive value: (11 bytes)
publisher: receive finished
Smallest data is ab, 2 bytes

Like the previous example, the publisher emits all its Data objects and finishes, then
min(by:) finds and emits the data with the smallest byte size and sink prints it out.

max
As you'd guess, max works exactly like min, except that it finds the maximum value
emitted by a publisher:

raywenderlich.com 169
Combine Chapter 7: Sequence Operators

Add the following code to your playground to try this example:

example(of: "max") {
// 1
let publisher = ["A", "F", "Z", "E"].publisher

// 2
publisher
.print("publisher")
.max()
.sink(receiveValue: { print("Highest value is \($0)") })
.store(in: &subscriptions)
}

In the following code, you:

1. Create a publisher that emits four different letters.

2. Use the max operator to find the letter with the highest value and print it.

Run your playground. You'll see the following output in your playground:

——— Example of: max ———

publisher: receive subscription: (["A", "F", "Z", "E"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive value: (F)
publisher: receive value: (Z)
publisher: receive value: (E)
publisher: receive finished
Highest value is Z

raywenderlich.com 170
Combine Chapter 7: Sequence Operators

Exactly like min, max is greedy and must wait for the upstream publisher to finish
emitting its values before it determines the maximum value. In this case, that value
is Z.

Note: Exactly like min, max also has a companion max(by:) operator that takes
a predicate to determine the maximum value emitted among non-Comparable
values.

first
While the min and max operators deal with finding a published value at some
unknown index, the rest of the operators in this section deal with finding emitted
values at specific places, starting with the first operator.

The first operator is similar to Swift's first property on collections, except that it
lets the first emitted value through and then completes. It's lazy, meaning it doesn't
wait for the upstream publisher to finish, but instead will cancel the subscription
when it receives the first value emitted.

Add the above example to your playground:

example(of: "first") {
// 1
let publisher = ["A", "B", "C"].publisher

// 2
publisher
.print("publisher")

raywenderlich.com 171
Combine Chapter 7: Sequence Operators

.first()
.sink(receiveValue: { print("First value is \($0)") })
.store(in: &subscriptions)
}

In the above code, you:

1. Create a publisher emitting three letters.

2. Use first() to let only the first emitted value through and print it out.

Run your playground and take a look at the console:

——— Example of: first ———

publisher: receive subscription: (["A", "B", "C"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive cancel
First value is A

As soon as first() lets the first value through, it immediately cancels the
subscription to the upstream publisher.

If you're looking for more granular control, you can also use first(where:). Just like
its counterpart in the Swift standard library, it will emit the first value that matches a
provided predicate — if there is one.

Add the following example to your playground:

example(of: "first(where:)") {
// 1
let publisher = ["J", "O", "H", "N"].publisher

// 2
publisher
.print("publisher")
.first(where: { "Hello World".contains($0) })
.sink(receiveValue: { print("First match is \($0)") })
.store(in: &subscriptions)
}

In this code, you:

1. Create a publisher that emits four letters.

2. Use the first(where:) operator to find the first letter contained in Hello
World and then print it out.

raywenderlich.com 172
Combine Chapter 7: Sequence Operators

Run the playground and you'll see the following output:

——— Example of: first(where:) ———

publisher: receive subscription: (["J", "O", "H", "N"])
publisher: request unlimited
publisher: receive value: (J)
publisher: receive value: (O)
publisher: receive value: (H)
publisher: receive cancel
First match is H

In the above example, the operator checks if Hello World contains the emitted
letter until it finds the first match: H. Upon finding that much, it cancels the
subscription and emits the letter for sink to print out.

last
Just as min has an opposite, max, first also has an opposite: last!

last works exactly like first, except it emits the last value that the publisher emits.
This means it's also greedy and must wait for the upstream publisher to finish:

Add this example to your playground:

example(of: "last") {
// 1
let publisher = ["A", "B", "C"].publisher

// 2
publisher
.print("publisher")
.last()

raywenderlich.com 173
Combine Chapter 7: Sequence Operators

.sink(receiveValue: { print("Last value is \($0)") })

.store(in: &subscriptions)
}

In this code, you:

1. Create a publisher that will emit three letters and finish.

2. Use the last operator to only emit the last value published and print it out.

Run the playground and you'll see the following output:

——— Example of: last ———

publisher: receive subscription: (["A", "B", "C"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive value: (B)
publisher: receive value: (C)
publisher: receive finished
Last value is C

last waits for the upstream publisher to send a .finished completion event, at
which point it sends the last emitted value downstream to be printed out in sink.

Note: Exactly like first, last also has a companion last(where:) operator,
which emits the last value emitted by a publisher that matches the specified
predicate.

output(at:)
The last two operators in this section don't have counterparts in the Swift standard
library. The output operators will only let values through if they’re emitted by the
upstream publisher at the specified indices.

raywenderlich.com 174
Combine Chapter 7: Sequence Operators

Start with output(at:), which emits only the value emitted at the specified index:

Add the following code to your playground to try this example:

example(of: "output(at:)") {
// 1
let publisher = ["A", "B", "C"].publisher

// 2
publisher
.print("publisher")
.output(at: 1)
.sink(receiveValue: { print("Value at index 1 is \($0)") })
.store(in: &subscriptions)
}

In the above code, you:

1. Create a publisher which emits three letters.

2. Use output(at:) to only let through the value emitted at index 1 — i.e., the
second value.

Run the example in your playground and peek at your console:

——— Example of: output(at:) ———

publisher: receive subscription: (["A", "B", "C"])
publisher: request unlimited
publisher: receive value: (A)
publisher: request max: (1) (synchronous)
publisher: receive value: (B)
Value at index 1 is B
publisher: receive cancel

raywenderlich.com 175
Combine Chapter 7: Sequence Operators

Here, the output indicates the value at index 1 is B. However, you might've noticed an
additional interesting fact: The operator demands one more value after every emitted
value, since it knows it's only looking for an item at a specific index. While this is an
implementation detail of the specific operator, it provides interesting insight into
how Apple designs some of their own built-in Combine operators.

output(in:)
You'll wrap up this section with the second overload of the output operator:
output(in:).

While output(at:) emits a single value emitted at a specified index, output(in:)

emits values whose indices are within a provided range:

To try this out, add the following example to your playground:

example(of: "output(in:)") {
// 1
let publisher = ["A", "B", "C", "D", "E"].publisher

// 2
publisher
.output(in: 1...3)
.sink(receiveCompletion: { print($0) },
receiveValue: { print("Value in range: \($0)") })
.store(in: &subscriptions)
}

raywenderlich.com 176
Combine Chapter 7: Sequence Operators

In the previous code, you:

1. Create a publisher that emits five different letters.

2. Use the output(in:) operator to only let through values emitted in indices 1
through 3, then print out those values.

Can you guess what the output of this example will be? Run your playground and
find out:

——— Example of: output(in:) ———

Value in range: B
Value in range: C
Value in range: D
finished

Well, did you guess correctly? The operator emits individual values within the
range of indices, not a collection of them.

The operator prints the values B, C and D as they're in indices 1, 2 and 3, respectively.
Then, since all items within the range have been emitted, it cancels the subscription
as soon as it receives everything it needs to complete its work.

Querying the publisher

The following operators also deal with the entire set of values emitted by a publisher,
but they don't produce any specific value that it emits. Instead, these operators emit
a different value representing some query on the publisher as a whole. A good
example of this is the count operator.

count
The count operator will emit a single number depicting how many values were
emitted by the upstream publisher, once the publisher sends a .finished
completion event:

raywenderlich.com 177
Combine Chapter 7: Sequence Operators

Add the following code to try this example:

example(of: "count") {
// 1
let publisher = ["A", "B", "C"].publisher

// 2
publisher
.print("publisher")
.count()
.sink(receiveValue: { print("I have \($0) items") })
.store(in: &subscriptions)
}

In the above code, you:

1. Create a publisher that emits three letters.

2. Use count() to emit a single value indicating the number of values emitted by
the upstream publisher.

Run your playground and check your console. You'll see the following output:

——— Example of: count ———

publisher: receive subscription: (["A", "B", "C"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive value: (B)
publisher: receive value: (C)
publisher: receive finished
I have 3 items

raywenderlich.com 178
Combine Chapter 7: Sequence Operators

As expected, the value 3 is only printed out once the upstream publisher sends
a .finished completion event.

contains
Another useful operator is contains. You've probably used its counterpart in the
Swift standard library more than once.

The contains operator will emit true and cancel the subscription if the specified
value is emitted by the upstream publisher, or false if none of the emitted values
are equal to the specified one:

Add the following to your playground to try contains:

example(of: "contains") {
// 1
let publisher = ["A", "B", "C", "D", "E"].publisher
let letter = "C"

// 2
publisher
.print("publisher")
.contains(letter)
.sink(receiveValue: { contains in
// 3
print(contains ? "Publisher emitted \(letter)!"
: "Publisher never emitted \(letter)!")
})
.store(in: &subscriptions)
}

raywenderlich.com 179
Combine Chapter 7: Sequence Operators

In the following code, you:

1. Create a publisher emitting five different letters — A through E — and create a

letter value to use with contains.

2. Use contains to check if the upstream publisher emitted the value of letter: C.

3. Print an appropriate message based on whether or not the value was emitted.

Run your playground and check the console:

——— Example of: contains ———

publisher: receive subscription: (["A", "B", "C", "D", "E"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive value: (B)
publisher: receive value: (C)
publisher: receive cancel
Publisher emitted C!

Huzzah! You got a message indicating C was emitted by the publisher. You might
have also noticed contains is lazy, as it only consumes as many upstream values as
it needs to perform its work. Once C is found, it cancels the subscription and doesn't
produce any further values.

Why don't you try another variation? Replace the following line:

let letter = "C"

With:

let letter = "F"

Next, run your playground again. You'll see the following output:

——— Example of: contains ———

publisher: receive subscription: (["A", "B", "C", "D", "E"])
publisher: request unlimited
publisher: receive value: (A)
publisher: receive value: (B)
publisher: receive value: (C)
publisher: receive value: (D)
publisher: receive value: (E)
publisher: receive finished
Publisher never emitted F!

raywenderlich.com 180
Combine Chapter 7: Sequence Operators

In this case, contains waits for the publisher to emit F. However, the publisher
finishes without emitting F, so contains emits false and you see the appropriate
message printed out.

Finally, sometimes you want to look for a match for a predicate that you provide or
check for the existence of an emitted value that doesn't conform to Comparable. For
these specific cases, you have contains(where:).

Add the following example to your playground:

example(of: "contains(where:)") {
// 1
struct Person {
let id: Int
let name: String
}

// 2
let people = [
(456, "Scott Gardner"),
(123, "Shai Mishali"),
(777, "Marin Todorov"),
(214, "Florent Pillet")
]
.map(Person.init)
.publisher

// 3
people
.contains(where: { $0.id == 800 })
.sink(receiveValue: { contains in
// 4
print(contains ? "Criteria matches!"
: "Couldn't find a match for the criteria")
})
.store(in: &subscriptions)
}

This above code is a bit more complex, but not by much. You:

1. Define a Person struct with an id and a name.

2. Create a publisher that emits four different instances of People.

3. Use contains to see if the id of any of them is 800.

4. Print an appropriate message based on the emitted result.

raywenderlich.com 181
Combine Chapter 7: Sequence Operators

Run your playground and you'll see the following output:

——— Example of: contains(where:) ———

Couldn't find a match for the criteria

It didn't find any matches, as expected, because none of the emitted people have an
id of 800.

Next, change the implementation of contains(where:):

.contains(where: { $0.id == 800 })

To the following:

.contains(where: { $0.id == 800 || $0.name == "Marin Todorov" })

Run the playground again and look at the console:

——— Example of: contains(where:) ———

Criteria matches!

This time it found a value matching the predicate, since Marin is indeed one of the
people in your list. Awesome! :]

allSatisfy
A bunch of operators down, and only two to go! Both of them have counterpart
collection methods in the Swift standard library.

You’ll start with allSatisfy, which takes a closure predicate and emits a Boolean
indicating whether all values emitted by the upstream publisher match that
predicate.

raywenderlich.com 182
Combine Chapter 7: Sequence Operators

It's greedy and will, therefore, wait until the upstream publisher emits a .finished
completion event:

Add the following example to your playground to try this:

example(of: "allSatisfy") {
// 1
let publisher = stride(from: 0, to: 5, by: 2).publisher

// 2
publisher
.print("publisher")
.allSatisfy { $0 % 2 == 0 }
.sink(receiveValue: { allEven in
print(allEven ? "All numbers are even"
: "Something is odd...")
})
.store(in: &subscriptions)
}

In the above code, you:

1. Create a publisher that emits numbers between 0 to 5 in steps of 2 (i.e., 0, 2 and

4).

2. Use allSatisfy to check if all emitted values are even, then print an appropriate
message based on the emitted result.

Run the code and check the console output:

——— Example of: allSatisfy ———

publisher: receive subscription: (Sequence)
publisher: request unlimited

raywenderlich.com 183
Combine Chapter 7: Sequence Operators

publisher: receive value: (0)

publisher: receive value: (2)
publisher: receive value: (4)
publisher: receive finished
All numbers are even

Since all values are indeed even, the operator emits true after the upstream
publisher sends a .finished completion, and the appropriate message is printed
out.

However, if even a single value doesn't pass the predicate condition, the operator will
emit false immediately and will cancel the subscription.

Replace the following line:

let publisher = stride(from: 0, to: 5, by: 2).publisher

With:

let publisher = stride(from: 0, to: 5, by: 1).publisher

You simply changed the stride to step between 0 and 5 by 1, instead of 2. Run the
playground once again and take a look at the console:

——— Example of: allSatisfy ———

publisher: receive subscription: (Sequence)
publisher: request unlimited
publisher: receive value: (0)
publisher: receive value: (1)
publisher: receive cancel
Something is odd...

In this case, as soon as 1 is emitted, the predicate doesn't pass anymore, so

allSatisfy emits false and cancels the subscription.

reduce
Well, here we are! The final operator for this rather packed chapter: reduce.

The reduce operator is a bit different from the rest of the operators covered in this
chapter. It doesn't look for a specific value or query the publisher as a whole. Instead,
it lets you iteratively accumulate a new value based on the emissions of the upstream
publisher.

raywenderlich.com 184
Combine Chapter 7: Sequence Operators

This might sound confusing at first, but you'll get it in a moment. The easiest way to
start is with a diagram:

Combine's reduce operator works like its counterparts in the Swift standard library:
reduce(_:_) and reduce(into:_:). It lets you provide a seed value and an
accumulator closure. That closure receives the accumulated value — starting with the
seed value — and the current value. From that closure, you return a new accumulated
value. Once the operator receives a .finished completion event, it emits the final
accumulated value.

In the case of the above diagram, you can think of it this way :

Seed value is 0
Receives 1, 0 + 1 = 1
Receives 3, 1 + 3 = 4
Receives 7, 4 + 7 = 11
Emits 11

Time for you to try a quick example to get a better sense of this operator. Add the
following to your playground:

example(of: "reduce") {
// 1
let publisher = ["Hel", "lo", " ", "Wor", "ld", "!"].publisher

publisher
.print("publisher")
.reduce("") { accumulator, value in
// 2
accumulator + value
}
.sink(receiveValue: { print("Reduced into: \($0)") })

raywenderlich.com 185
Combine Chapter 7: Sequence Operators

.store(in: &subscriptions)
}

In this code, you:

1. Create a publisher that emits six Strings.

2. Use reduce with a seed of an empty string, appending the emitted values to it to
create the final string result.

Run the playground and take a look at the console output:

——— Example of: reduce ———

publisher: receive subscription: (["Hel", "lo", " ", "Wor",
"ld", "!"])
publisher: request unlimited
publisher: receive value: (Hel)
publisher: receive value: (lo)
publisher: receive value: ( )
publisher: receive value: (Wor)
publisher: receive value: (ld)
publisher: receive value: (!)
publisher: receive finished
Reduced into: Hello World!

Notice how the accumulated result — Hello World! — is only printed once the
upstream publisher sent a .finished completion event.

The second argument for reduce is a closure that takes two values of some type and
returns a value of that same type. In Swift, + is an also a function that matches that
signature.

So as a final neat trick, you can reduce the syntax above. Replace the following code:

.reduce("") { accumulator, value in

// 3
return accumulator + value
}

With simply:

.reduce("", +)

If you run your playground again, it will work exactly the same as before, with a bit of
a fancier syntax. ;]

raywenderlich.com 186
Combine Chapter 7: Sequence Operators

Note: Does this operator feel a bit familiar? Well, that might be because you
learned about scan in Chapter 3, “Transforming Operators.” scan and reduce
have the same functionality, with the main difference being that scan emits
the accumulated value for every emitted value, while reduce emits a single
accumulated value once the upstream publisher sends a .finished
completion event. Feel free to change reduce to scan in the above example
and try it out for yourself.

Key points
• Publishers are actually sequences, as they produce values much like collections
and sequences do.

• You can use min and max to emit the minimum or maximum value emitted by a
publisher, respectively.

• first, last and output(at:) are useful when you want to find a value emitted at
a specific index. Use output(in:) to find values emitted within a range of indices.

• first(where:) and last(where:) each take a predicate to determine which

values it should let through.

• Operators such as count, contains and allSatisfy don't emit values emitted by
the publisher. Rather, they emit a different value based on the emitted values.

• contains(where:) takes a predicate to determine if the publisher contains the

given value.

• Use reduce to accumulate emitted values into a single value.

Where to go from here?

Congrats on completing the last chapter on operators for this book! give yourself a
quick pat on the back and high-five yourself while you're at it. :]

You'll wrap up this section by working on your first practical project, where you'll
build a Collage app using Combine and many of the operators you've learned. Take a
few deep breaths, grab a cup of coffee, and move on to the next chapter.

raywenderlich.com 187
8 Chapter 8: In Practice:
Project "Collage"
By Marin Todorov

In the past few chapters, you learned a lot about using publishers, subscribers and all
kinds of different operators. You did that in the "safety" of a Swift playground. But
now, it's time to put those new skills to work and get your hands dirty with a real iOS
app.

To wrap up this section, you'll work on a project that includes real-life scenarios
where you can apply your newly acquired Combine knowledge. The project is called
Collage and it's an iOS app which allows the user to create simple collages out of
their photos, like this:

raywenderlich.com 188
Combine Chapter 8: In Practice: Project "Collage"

This project will take you through:

• Using Combine publishers in your UIKit view controllers.

• Handling user events with Combine.

• Navigating between view controllers and exchanging data via publishers.

• Using a variety of operators to create different subscriptions to implement your

app's logic.

• Wrapping existing Cocoa APIs so you can conveniently use them in your Combine
code.

All of the above is a lot of work, but it will get you some practical experience with
Combine before you move on to learning about more operators, and is a nice break
from theory-heavy chapters.

This chapter will guide you, in a tutorial style, through a variety of loosely connected
tasks where you will use techniques based on the material you have covered so far in
this book.

Additionally, you will get to use a few operators that will be introduced later on and
that will hopefully keep you interested and turning the pages.

Without further ado — it's time to get coding!

Getting started with "Collage"

To get started with Collage, open the starter project provided for this chapter and
select Assets/Main.storyboard in the project navigator. The app's structure is rather
simple — there is a main view controller to create and preview collages and an
additional view controller where users select photos to add to their current collage:

raywenderlich.com 189
Combine Chapter 8: In Practice: Project "Collage"

Note: In this chapter, you will work on integrating Combine data workflows
and UIKit user controls and events. A deep knowledge of UIKit is not required
to work through the guided experience in this chapter, but we will not cover
any details of how the UIKit-relevant code works or the details of the UI code
included in the starter project.

Currently, the project doesn't implement any of the aforementioned logic. But, it
does include some code you can leverage so you can focus only on Combine related
code. Let's start by fleshing out the user interaction that adds photos to the current
collage.

Open MainViewController.swift and import the Combine framework at the top of

the file:

import Combine

This will allow you to use Combine types in this file. To get started, add two new
private properties to the MainViewController class:

private var subscriptions = Set<AnyCancellable>()

private let images = CurrentValueSubject<[UIImage], Never>([])

subscriptions is the collection where you will store any UI subscriptions tied to the
lifecycle of the current view controller. When you bind your UI controls tying those
subscriptions to the lifecycle of the current view controller is usually what you need.

raywenderlich.com 190
Combine Chapter 8: In Practice: Project "Collage"

This way, in case the view controller is popped out of the navigation stack or
dismissed otherwise, all UI subscriptions will be canceled right away.

Note: As mentioned in Chapter 1, “Hello, Combine!,” subscribers return a

Cancellable token to allow manually canceling a subscription.
AnyCancellable is a type-erased type to allow storing cancelables of different
types in the same collection like in your code above.

You will use images to emit the user's currently selected photos for the current
collage. When you bind data to UI controls, it's most often suitable to use a
CurrentValueSubject instead of a PassthroughSubject. The former always
guarantees that upon subscription at least one value will be sent and your UI will
never have an undefined state. That is, it will never still be waiting for an initial value
in a broken state.

Next, to get some images added to the collage and test your code, add in
actionAdd():

let newImages = images.value + [UIImage(named: "IMG_1907.jpg")!]

images.send(newImages)

Whenever the user taps on the + button in the top-right corner of the screen, you
will add the IMG_1907.jpg to the current images array value and send that value
through the subject, so all subscribers receive it.

You can find IMG_1907.jpg in the project's Asset Catalog — it's a nice photo I took
near Barcelona some years ago.

To also be able to clear the currently selected photos, move over to actionClear()
and add there:

images.send([])

This line simply sends an empty array through the images subject, pushing it to all
of its subscribers.

Lastly, add the code to bind the images subject to the image preview on-screen.
Append at the end of viewDidLoad():

// 1
images
// 2
.map { photos in

raywenderlich.com 191
Combine Chapter 8: In Practice: Project "Collage"

UIImage.collage(images: photos, size: collageSize)

}
// 3
.assign(to: \.image, on: imagePreview)
// 4
.store(in: &subscriptions)

The play-by-play for this subscription is as follows:

1. You begin a subscription to the current collection of photos.

2. You use map to convert them to a single collage by calling into

UIImage.collage(images:size:), a helper method defined in
UIImage+Collage.swift.

3. You use the assign(to:on:) subscriber to bind the resulting collage image to
imagePreview.image, which is the center screen image view.

4. Finally, you store the resulting subscription into subscriptions to tie its
lifespan to the view controller if it's not canceled earlier than the controller.

Time to test that new subscription! Build and run the app and click the + button few
times. You should see a collage preview, featuring one more copy of the same photo
each time your click +:

Thanks to the simplicity of binding via assign, you can get the photos collection,
convert it to a collage and assign it to an image view in a single subscription!

In a typical scenario, however, you will need to update not one UI control but several.
Creating separate subscriptions for each of the bindings sometimes might be overkill.
So, let's see how we can perform a number of updates as a single batch.

raywenderlich.com 192
Combine Chapter 8: In Practice: Project "Collage"

There is already a method included in MainViewController called

updateUI(photos:), which makes various updates across the UI, disables the Save
button when the current selection contains an odd number of photos, enables the
Clear button whenever there is a collage in progress and more.

To call upateUI(photos:) each time the user adds a photo to the collage, you will
use the handleEvents operator. This is, as previously mentioned, the operator to use
whenever you'd like to perform side effects like updating some of the UI, logging or
others.

Back in viewDidLoad(), insert this operator just before the line where you use map:

.handleEvents(receiveOutput: { [weak self] photos in

self?.updateUI(photos: photos)
})

Note: The handleEvents operator enables you to perform side effects when a
publisher emits an event. You'll learn a lot more about it in Chapter 10,
“Debugging.”

This will feed the current selection to updateUI(photos:) just before they are
converted into a single collage image inside the map operator.

As soon as you run the project again you will notice the two buttons below the
preview are disabled, which is the correct initial state:

The buttons will keep changing state as you add more photos to the current collage.
For example, when you select one or three photos the Save button will be disabled
but Clear enabled like so:

raywenderlich.com 193
Combine Chapter 8: In Practice: Project "Collage"

Talking to other view controllers

You saw how easy it is to route your UI's data through a subject and bind it to some
controls on-screen. Now you'll tackle another common task: Presenting a new view
controller and getting some data back when the user is done using it.

The generic idea of exchanging data between two view controllers is exactly the
same as subscribing to a subject in the same view controller. At the end of the day,
you just have a publisher that emits some output and you use a subscriber to make
something useful with the emitted values.

Scroll back to actionAdd(), comment the existing body of that method and add the
following code instead:

let photos = storyboard!.instantiateViewController(

withIdentifier: "PhotosViewController") as!
PhotosViewController

navigationController!.pushViewController(photos, animated: true)

This code instantiates a PhotosViewController from the project storyboard and

pushes it onto the navigation stack. Since accessing the photos library and displaying
a list of the available photos isn't specifically a Combine related task, that code is
already fleshed out for you.

raywenderlich.com 194
Combine Chapter 8: In Practice: Project "Collage"

Open PhotosViewController.swift and in viewDidLoad() you will see it already

contains the code to load photos from the Camera Roll and display them in a
collection view.

Your next task is to add a subject to the view controller and emit any images that the
user taps in the Camera Roll list.

First and foremost, just like before, add a new import in

PhotosViewController.swift:

import Combine

Unlike the images subject in the main view controller which you both subscribe to
and send through, in this view controller you'd like to only allow other consumers to
subscribe, making it a read-only publisher. In other words, you'd like to be able to
send values from within PhotosViewController but only allow
MainViewController to subscribe. To achieve that, you'll use another common
pattern: Exposing a publisher publicly by abstracting a private subject.

Add this pair of public and private properties under their respective MARK comments:

// MARK: - Public properties

var selectedPhotos: AnyPublisher<UIImage, Never> {
return selectedPhotosSubject.eraseToAnyPublisher()
}

// MARK: - Private properties

private let selectedPhotosSubject =
PassthroughSubject<UIImage, Never>()

This code allows the current type to use selectedPhotosSubject to send values
while other types can only access the type-erased selectedPhotos to subscribe: For
example, selectedPhotos cannot be used to send new values through the publisher.
Speaking of, let's hook up the collection view delegate method to that subject.

Scroll down to collectionView(_:didSelectItemAt:). The code in that method

flashes the tapped collection cell and then fetches the photo asset from the device
library. Finally, having the photo ready, you should use the subject to send out the
image to any subscribers.

Replace the // Send the selected photo comment with:

self.selectedPhotosSubject.send(image)

raywenderlich.com 195
Combine Chapter 8: In Practice: Project "Collage"

Well, that was easy! However, since you're exposing the subject to other types, you'd
like to explicitly send a completion event in case the view controller is being
dismissed to tear down any external subscriptions. Scroll up to
viewWillDisappear(animated:) and append:

selectedPhotosSubject.send(completion: .finished)

This code will send a finished event when you navigate back from the view
controller. To wrap up the current task, you still need to subscribe to the selected
photos from your main view controller. Open MainViewController.swift, find
actionAdd() and insert before the last line presenting PhotosViewController:

let newPhotos = photos.selectedPhotos

newPhotos
.map { [unowned self] newImage in
// 1
return self.images.value + [newImage]
}
// 2
.assign(to: \.value, on: images)
// 3
.store(in: &subscriptions)

In this subscription, you:

1. Get the current list of selected images and append any new images to it.

2. Use assign to send the updated images array through the images subject.

3. You store the new subscription in subscriptions. However, the subscription will
end whenever the user dismisses the presented view controller.

Now, run the app and let's try out the newly added code. Tap on the + button and you
will see the system Photos access dialogue pop-up on-screen. Tap OK:

raywenderlich.com 196
Combine Chapter 8: In Practice: Project "Collage"

This will reload the collection view with the default photos included with the iOS
Simulator, or your own photos if you're testing on your device:

Tap a few of those. They'll flash to indicate they've been added to the collage. Then,
tap to go back to the main screen you will see your new collage in full glory:

Wrapping a callback function as a future

In a playground, you might play with subjects and publishers and be able to design
everything exactly as you like it, but in day-to-day iOS code, you will interact with
various Cocoa APIs, such as accessing the Camera Roll, reading the device's sensors
or interacting with some database.

raywenderlich.com 197
Combine Chapter 8: In Practice: Project "Collage"

Later in this book, you will learn how to create your own custom publishers. However,
in many cases adding a subject to an existing Cocoa class is enough to plug its
functionality in your Combine workflow.

In this part of the chapter, you will work on a new custom type called PhotoWriter
which will allow you to save the user's collage to disk. You will use the callback-based
Photos API to do the saving and a future to allow other types to subscribe to the
operation result.

Open Utility/PhotoWriter.swift, which contains an empty PhotoWriter class, and

add the following static function to it:

static func save(_ image: UIImage) -> Future<String,

PhotoWriter.Error> {
return Future { resolve in

}
}

This function will try to asynchronously store the given image on disk and return a
future that this API's consumers will subscribe to.

You'll use the closure-based Future initializer to return a ready-to-go future which
will execute the code in the provided closure once initialized.

Let's start fleshing out the future's logic by inserting the following code inside the
closure:

do {

} catch {
resolve(.failure(.generic(error)))
}

This is a pretty good start. You will perform the saving inside the do and, should it
throw an error, you'll resolve the future with a failure.

Since you don't know the exact errors that could be thrown while saving the photo,
you just take the thrown error and wrap it as a PhotoWriter.Error.generic error.

Now, for the real "meat" of the function: Insert the following inside the do body:

// 1
try PHPhotoLibrary.shared().performChangesAndWait {
// 2
let request =
PHAssetChangeRequest.creationRequestForAsset(from: image)

raywenderlich.com 198
Combine Chapter 8: In Practice: Project "Collage"

// 3
guard let savedAssetID =
request.placeholderForCreatedAsset?.localIdentifier else {
return resolve(.failure(.couldNotSavePhoto))
}

// 4
resolve(.success(savedAssetID))
}

Here, you use PHPhotoLibrary.performChangesAndWait(_) to access the Photos

library synchronously. The future's closure is itself executed asynchronously, so don't
worry about blocking the main thread. With this, you'll perform the following
changes from within the closure:

1. First, you create a request to store image.

2. Then, you attempt to get the newly-created asset's identifier via

request.placeholderForCreatedAsset?.localIdentifier.

3. If the creation has failed and you didn't get an asset id back, you resolve the
future with a PhotoWriter.Error.couldNotSavePhoto error.

4. Finally, in case you got back a savedAssetID, you resolve the future with success.

That's pretty much everything you need to wrap a callback function, resolve with a
failure if you get back an error or resolve with success in case you have some result to
return!

Now, you can use PhotoWriter.save(_) to save the current collage when the user
taps Save. Open MainViewController.swift and at the bottom of actionSave()
append:

// 1
PhotoWriter.save(image)
.sink(receiveCompletion: { [unowned self] completion in
// 2
if case .failure(let error) = completion {
self.showMessage("Error", description:
error.localizedDescription)
}
self.actionClear()
}, receiveValue: { [unowned self] id in
// 3
self.showMessage("Saved with id: \(id)")
})
.store(in: &subscriptions)

raywenderlich.com 199
Combine Chapter 8: In Practice: Project "Collage"

In the previous code you:

1. You subscribe the PhotoWriter.save(_) future by using

sink(receiveCompletion:receiveValue:).

2. In case of completion with a failure, you call into

showMessage(_:description:) to display an error alert on-screen.

3. In case you get back a value — the new asset id — you use
showMessage(_:description:) to let the user know their collage is saved
successfully.

Run the app one more time, pick a couple of photos and tap Save. This will call into
your shiny, new publisher and, upon saving the collage, will display an alert like so:

A note on memory management

Here is a good place for a quick side-note on memory management with Combine.
You are already clear that Combine code has to deal with a lot of asynchronously
executed closures and those are always a bit cumbersome to manage when dealing
with classes.

When you write your own custom Combine code, you might be dealing
predominantly with structs, so you won't need to explicitly specify capturing
semantics in the closures you use with map, flatMap, filter, etc.

However, when you're dealing with UI code, and specifically with UIKit/AppKit
related code, you will always need to work with classes like UIViewController,
UICollectionController, NSFetchedController, etc.

raywenderlich.com 200
Combine Chapter 8: In Practice: Project "Collage"

When writing Combine code, standard rules apply, so you should use the same Swift
capture semantics as always:

• If you're capturing an object that could be released from memory, like the
presented photos view controller earlier, you should use [weak self] or another
variable than self if you capture another object.

• If you're capturing an object that could not be released, like the main view
controller in that Collage app, you can safely use [unowned self]. For example,
one that you never pop-out of the navigation stack and is therefore always
present.

With that said, let's continue with the next task: Presenting a view controller and
fetching back the result via a future.

Presenting a view controller as a future

This task builds upon two of the tasks you've already completed. Previously you:

• Wrapped a UI-less callback function as a Future.

• Manually presented a view controller and subscribed to one of its exposed

publishers.

This time, you will use a future to present a new view controller on-screen, wait until
the user is done with it and then complete the future — all in one go!

In a new extension on ViewController, you will recreate the logic you have in
MainViewController.showMessage(title:description:) but build it using a
Combine future.

To do that, open the placeholder file UIViewController+Combine.swift and add the

initial skeleton of the new method inside the provided extension:

func alert(title: String, text: String?) -> AnyPublisher<Void,

Never> {
let alertVC = UIAlertController(title: title,
message: text,
preferredStyle: .alert)

The method returns an AnyPublisher<Void, Never> as you are not interested in

returning any values but simply in completing the publisher when the user taps
Close.

raywenderlich.com 201
Combine Chapter 8: In Practice: Project "Collage"

You begin by creating an alert controller called alertVC. Next, you will present it on-
screen and dismiss it when the future completes.

Right after the line let alertVC = ..., append:

return Future { resolve in

alertVC.addAction(UIAlertAction(title: "Close",
style: .default) { _ in
resolve(.success(()))
})

self.present(alertVC, animated: true, completion: nil)

}
.handleEvents(receiveCancel: {
self.dismiss(animated: true)
})
.eraseToAnyPublisher()

Here, you create a Future, and upon subscription you add a Close button to the alert
and present it on-screen. If the user taps the button, you resolve the future with
success.

In case the subscription gets canceled, you dismiss the alert automatically from
within handleEvents(receiveCancel:). This code handles the case when you tie
the alert subscription to the currently-presented view controller and that controller
gets dismissed itself. This will cancel the alert subscription and dismiss that alert as
well.

To test this code, replace the code in the existing showMessage method in
MainViewController with:

alert(title: title, text: description)

.sink(receiveValue: { _ in })
.store(in: &subscriptions)

Build and run the app another time and save some collages. You will see the alerts
behaving just like before, only this time with your new Combine-ified code.

Sharing subscriptions
Looking back to the code in actionAdd(), you could do a few more things with the
images being selected by the user in the presented PhotosViewController.

This poses an uneasy question: Should you subscribe multiple times to the same
photos.selectedPhotos publisher, or do something else?

raywenderlich.com 202
Combine Chapter 8: In Practice: Project "Collage"

Turns out, subscribing to the same publisher might have unwanted side effects. If
you think about it, you don't know what the publisher is doing upon subscription, do
you? It might be creating new resources, making network requests or something else.

The correct way to go when creating multiple subscriptions to the same publisher is
to share the original publisher via the share() operator. This wraps the publisher in
a class and therefore it can safely emit to multiple subscribers.

Find the line let newPhotos = photos.selectedPhotos and replace it with:

let newPhotos = photos.selectedPhotos.share()

Now, it's safe to create multiple subscriptions to newPhotos without being afraid that
the publisher is performing side effects multiple times upon each of the
subscriptions:

A caveat to keep in mind is that share() does not re-emit any values from the
shared subscription.

raywenderlich.com 203
Combine Chapter 8: In Practice: Project "Collage"

For example, if you have two subscriptions on a share() and the source publisher
emits synchronously upon subscribing that will send the initial output value only to
the first subscriber before the second one has the chance to subscribe. (If the source
publisher emits asynchronously, that's obviously not an issue.)

A reliable solution to that problem is building your own sharing operator which re-
emits, or replays, past values when a new subscriber subscribes. Building your own
operators is not complicated at all - you will, in fact, build one called shareReplay()
in Chapter 18, “Custom Publishers & Handling Backpressure,” which will allow you
to use share in the way described above.

Publishing properties with @Published

The Combine framework offers a few property wrappers, a new feature introduced in
Swift 5.1. Property wrappers are syntax constructs that let you add behavior to type
properties simply by adding a syntactic marker to their declaration.

Combine offers two property wrappers: @Published and @ObservedObject. In this

chapter, you will get to try @Published and will cover @ObservedObject in a later
one.

The @Published property wrapper allows you to automatically add a publisher to

back your property that will emit a new output value every time you change the
original property's value.

The syntax looks like this:

struct Person {
@Published var age: Int = 0
}

The property age behaves just like any normal property. You can get and set its value
imperatively as usual. The compiler will, however, generate another property
automatically in your type, with the same accessibility level (private or public), called
$age.

$age is a publisher that can never error out and its output is of the same type as the
age property. Whenever you modify the value of age, $age will emit that new value.

raywenderlich.com 204
Combine Chapter 8: In Practice: Project "Collage"

Note: @Published requires an initial value. You either need to provide a

default value for the original property or initialize it when instantiating your
type.

This automation of creating publishers for your types allows you to super easily
provide consumers of your APIs the ability to subscribe for data changes in real-time.

To try out @Published, you will add a new property to PhotosViewController to

expose how many photos the user has selected. Open PhotosViewController.swift
and add the new property below selectedPhotos:

var selectedPhotosCount = 0

Every time the user taps a photo, you will increase the value of the new property to
keep track of how many the user has selected. Scroll down to
collectionView(_:didSelectItemAt:) and find this line:
self.selectedPhotosSubject.send(image).

Below that line, add:

self.selectedPhotosCount += 1

So far, selectedPhotosCount is a vanilla Int property. You can get and set its value,
but you cannot subscribe to it.

Go back to the property declaration and add @Published like so:

@Published var selectedPhotosCount = 0

This makes the compiler generate behind the scenes a publisher for the property
called $selectedPhotosCount.

You can now subscribe to this publisher from your main view controller and display
the info about how many photos were selected on the main screen.

Subscribing works like any other publisher, just don't forget to add the $ prefix to the
property name. Open MainViewController.swift and scroll to actionAdd(). Here,
towards the top of the method just after you create photos, add:

photos.$selectedPhotosCount
.filter { $0 > 0 }
.map { "Selected \($0) photos" }
.assign(to: \.title, on: self)
.store(in: &subscriptions)

raywenderlich.com 205
Combine Chapter 8: In Practice: Project "Collage"

You subscribe photos.$selectedPhotosCount and bind it to the view controller's

title property.

What we call a "binding" here, and also later in this book, is a subscription that "ends"
on an assign(to:on:) subscriber. The noun "binding" describes very well the nature
of such a subscription, or at least better than "assigning". You bind the output of a
publisher to a specific instance property on the receiving end.

You provide assign(to:on:) a value and a key path, and it updates that key path
with any values it receives. It's a practical subscriber in common use-cases, like
binding your model to properties on your views, binding network requests to inputs
on your view models and more.

Run the project again and tap a few photos. Then, navigate back and check the main
view controller title:

Operators in practice
Now that you learned about a few useful reactive patterns, it's time to practice some
of the operators you covered in previous chapters and see them in action.

Updating the UI after the publisher completes

Right now, when you tap some photos, you change the main view controller title to
display how many photos were selected. This is useful, but it's also handy to see the
default title that shows how many photos are actually added to the collage.

Scroll to actionAdd() and add another subscription to newPhotos just after the
existing one:

newPhotos
.ignoreOutput()
.delay(for: 2.0, scheduler: DispatchQueue.main)

raywenderlich.com 206
Combine Chapter 8: In Practice: Project "Collage"

.sink(receiveCompletion: { [unowned self] _ in

self.updateUI(photos: self.images.value)
}, receiveValue: { _ in })
.store(in: &subscriptions)

This time, you perform the following:

1. ignoreOutput() ignores emitted values, only providing a completion event to

the subscriber.

2. delay(for:scheduler:) waits a given amount of seconds. This will give few

seconds of the previous message saying "X photos selected" to tell the user how
many they selected in one go before switching to the total amount of selected
photos.

3. sink(receiveCompletion:) calls updateUI(photos:) to update the UI with the

default controller title.

The subscription lets the custom title on-screen (that you display in the previous
subscription) for 2 seconds and then invokes updateUI(photos:) to reset the title to
its default value showing the total number of selected photos:

Accepting values while a condition is met

Change the code where you share the selectedPhotos subscription to the following:

let newPhotos = photos.selectedPhotos

.prefix(while: { [unowned self] _ in
return self.images.value.count < 6
})
.share()

You already learned about prefix(while:) as one of the powerful Combine filtering
operators and here you get to use it in practice. The code above will keep the
subscription to selectedPhotos alive as long as the total count of images selected is
less than six. (I.e. will effectively allow the user to select up to six photos for their
collage.)

raywenderlich.com 207
Combine Chapter 8: In Practice: Project "Collage"

Adding prefix(while:) just before the call to share() allows you to filter the
incoming values, not only on one subscription, but on all subscriptions that
consequently subscribe to newPhotos.

Run the app and try adding more than six photos. You will see that after the first six
that the main view controller doesn't accept more. In this chapter's challenges, you
will refine this by popping out the photos controller automatically when the user
reaches the photos limit.

And that's a wrap for this chapter! You did well and deserve a nice pat on the
shoulder!

Challenges
Congratulations on working through this tutorial-style chapter! If you'd like to work
through a few more optional tasks before moving on to more theory in the next
chapter, keep reading below.

Challenge 1: Try more operators

Start by adding yet another filter. Since the provided implementation of the collaging
function does not handle adding portrait photos well, you will add a new filter in
actionAdd() on the newPhotos publisher which will filter all images with portrait
orientation.

Tip: You can check the image's size property and compare the width and
height values to determine if the orientation is a landscape or a portrait.

Once you're finished with your first task, create a new subscription to newPhotos
which:

1. Ignore all values and only pass a completion event. You can use ignoreOutput(),
just like earlier in the chapter.

2. Use a filter operator to pass the emitted value only in case the current count of
images in images.value is equal to 6 — the maximum amount of photos in a
collage.

raywenderlich.com 208
Combine Chapter 8: In Practice: Project "Collage"

3. Use a flatMap to display an alert letting the user know they reached the
maximum photos and wait until they tap the Close button.

4. Use a sink(receiveCompletion:receiveValue:) to pop the photos view

controller out of the navigation stack.

This subscription should, when the maximum number of photos for a collage is
selected, pop the photos view controller automatically and take the user back to the
main view controller:

Note: When testing this last functionality, pay attention, because any portrait
photos you select won't be counted towards the maximum of six. This got me a
few times while I was working on this chapter because the system photo
selector crops all photos as square thumbnails and you can't really tell if they
are in portrait or landscape orientation.

Challenge 2: PHPhotoLibrary authorization

publisher
Open Utility/PHPhotoLibrary+Combine.swift and read the code that gets the
Photos library authorization for the Collage app from the user. You will certainly
notice that the logic is quite straightforward and is based on a "standard" callback
API.

raywenderlich.com 209
Combine Chapter 8: In Practice: Project "Collage"

This provides you with a great opportunity to wrap a Cocoa API as a future on your
own. For this challenge, add a new static property to PHPhotoLibrary called
isAuthorized, which is of type Future<Bool, Never> and allows other types to
subscribe to the Photos library authorization status.

You've already done this a couple of times in this chapter and the existing
fetchAuthorizationStatus(callback:) function should be pretty straight
forward to use. Good luck! Should you experience any difficulties along the way,
don't forget that you can always peak into the challenge folder provided for this
chapter and have a look at the example solution.

Finally, don't forget to use the new isAuthorized publisher in

PhotosViewController code! That's a good opportunity to exercise receiving values
in the main queue as well.

For bonus points, display an error message via your custom alert publisher in case
the user doesn't grant access to their photos and navigate back to the main view
controller when they tap Close.

To play with different authorization states and test your code, open the Settings app
on your Simulator or device and navigate to Settings/Collage/Photos/Collage.

raywenderlich.com 210
Combine Chapter 8: In Practice: Project "Collage"

Change the authorization status to either "Never" or "Read and Write" to test how
your code behaves in those states:

If you made it successfully on your own so far into the challenges, you really deserve
an extra round of applause! Either way, one possible solution you can consult with at
any time is provided in the challenges folder for this chapter.

Key points
• In your day-to-day tasks, you'll most likely have to deal with callback or delegate-
based APIs. Luckily, those are easily wrapped as futures or publishers by using a
subject.

• Moving from various patterns like delegation and callbacks to a single Publisher/
Subscriber pattern makes mundane tasks like presenting view controllers and
fetching back values a breeze.

• To avoid unwanted side-effects when subscribing a publisher multiple times, use a

shared publisher via the share() operator.

Where to go from here?

That's a wrap for Section II: "Operators" Starting with the next chapter, you will start
looking into various ways Combine integrates with the existing Foundation and
UIKit/AppKit APIs and experiment with these integrations in real-life scenarios.

raywenderlich.com 211
Section III: Combine in Action

You now know most of Combine's basics. You learned how publishers, subscribers
and subscriptions work and the intertwined relationship between these pieces, as
well as how you can use operators to manipulate publishers and their emissions.

While theory is great and definitely useful, practical real-life knowledge is king!

This section is divided into five mini-chapters, each with its own focus on practical
approaches for leveraging Combine for specific use-cases. You'll learn how to
leverage Combine for networking, how to debug your combine publishers, how to use
timers and observe KVO-compliant objects, as well as learn how resources work in
Combine.

To wrap up this section, you'll get your hands dirty and build an entire Combine-
backed network layer — how exciting!

Specifically, you'll cover:

Chapter 9: Networking: This chapter teaches you how to seamlessly integrate

network requests in Combine publisher chains and make your networking easier and
more resilient.

Chapter 10: Debugging: Debugging asynchronous code being notoriously harder

when compared to linear code, Combine helps with a few tools that will greatly help
you improve your understanding of the processes at play.

Chapter 11: Timers: A niche part of your code, timers are always useful to have
around and easy to create in Combine, as you’ll learn in this chapter.

raywenderlich.com 212
Combine Section III: Combine in Action

Chapter 12: Key-Value Observing: This chapter shows you how Key-Value
Observing, which was historically the best way to get notified when a value changed,
now integrates nicely with Combine publishers.

Chapter 13: Resource Management: Precisely controlling resource usage is a

touchy subject, but this chapter will shed light on sharing operators which let you do
just that.

Chapter 14: In Practice: Project "News": In this chapter you will work on a
networking API that talks in real-time to the Hacker News servers and along the way
exercise using multiple operators and publishers in Foundation.

raywenderlich.com 213
9 Chapter 9: Networking
By Florent Pillet

As programmers, a lot of what we do revolves around networking. Communicating

with a backend, fetching data, pushing updates, encoding and decoding JSON... this
is the daily meat of the mobile developer.

Combine offers a few select APIs to help perform common tasks declaratively. These
APIs revolve around two key components of modern applications:

• URLSession.

• JSON encoding and decoding through the Codable protocol.

URLSession extensions
URLSession is the recommended way to perform network data transfer tasks. It
offers a modern asynchronous API with powerful configuration options and fully
transparent backgrounding support. It supports a variety of operations such as:

• Data transfer tasks to retrieve the content of a URL.

• Download tasks to retrieve the content of a URL and save it to a file.

• Upload tasks to upload files and data to a URL.

• Stream tasks to stream data between two parties.

• Websocket tasks to connect to websockets.

raywenderlich.com 214
Combine Chapter 9: Networking

Out of these, only the first one, data transfer tasks, exposes a Combine publisher.
Combine handles these tasks using a single API with two variants, taking a
URLRequest or just a URL.

Here‘s a look at how you can use this API:

guard let url = URL(string: "https://mysite.com/mydata.json")

else {
return
}

// 1
let subscription = URLSession.shared
// 2
.dataTaskPublisher(for: url)
.sink(receiveCompletion: { completion in
// 3
if case .failure(let err) = completion {
print("Retrieving data failed with error \(err)")
}
}, receiveValue: { data, response in
// 4
print("Retrieved data of size \(data.count), response = \
(response)")
})

Here‘s what‘s happening with this code:

1. It‘s crucial that you keep the resulting subscription; otherwise, it gets
immediately canceled and the request never executes.

2. You‘re using the overload of dataTaskPublisher(for:) that takes a URL as a

parameter.

3. Make sure you always handle errors! Network connections are prone to failure.

4. The result is a tuple with both a Data object and a URLResponse.

As you can see, Combine provides a transparent bare-bones publisher abstraction on

top of URLSession.dataTask, only exposing a publisher instead of a closure.

Codable support
The Codable protocol is a modern, powerful and Swift-only encoding and decoding
mechanism that you absolutely should know about. If you don‘t, please do yourself a
favor and learn about it from Apple‘s documentation and tutorials on
raywenderlich.com!

raywenderlich.com 215
Combine Chapter 9: Networking

Foundation supports encoding to and decoding from JSON through JSONEncoder

and JSONDecoder. You can also use PropertyListEncoder and
PropertyListDecoder, but these are less useful in the context of network requests.

In the previous example, you downloaded some JSON. Of course, you could decode it
with a JSONDecoder:

let subscription = URLSession.shared

.dataTaskPublisher(for: url)
.tryMap { data, _ in
try JSONDecoder().decode(MyType.self, from: data)
}
.sink(receiveCompletion: { completion in
if case .failure(let err) = completion {
print("Retrieving data failed with error \(err)")
}
}, receiveValue: { object in
print("Retrieved object \(object)")
})

You decode the JSON inside a tryMap, which works, but Combine provides an
operator to help reduce the boilerplate: decode(type:decoder:).

In the example above, replace the tryMap operator with the following lines:

.map(\.data)
.decode(type: MyType.self, decoder: JSONDecoder())

Unfortunately, since dataTaskPublisher(for:) emits a tuple, you can‘t directly use

decode(type:decoder:) without first using a map(_:) that only emits the Data part
of the result.

The only advantage is that you instantiate the JSONDecoder only once, when setting
up the publisher, versus creating it every time in the tryMap(_:) closure.

Publishing network data to multiple

subscribers
Every time you subscribe to a publisher, it starts doing work. In the case of network
requests, this means sending the same request multiple times if multiple subscribers
need the result.

raywenderlich.com 216
Combine Chapter 9: Networking

Combine, surprisingly, lacks operators to make this easy, as other frameworks have.
You could use the share() operator, but that‘s tricky because you need to subscribe
all your subscribers before the result comes back.

Besides using a caching mechanism, one solution is to use the multicast()

operator, which creates a ConnectablePublisher that publishes values through a
Subject. It allows you to subscribe multiple times to the subject, then call the
publisher‘s connect() method when you‘re ready:

let url = URL(string: "https://www.raywenderlich.com")!

let publisher = URLSession.shared
// 1
.dataTaskPublisher(for: url)
.map(\.data)
.multicast { PassthroughSubject<Data, URLError>() }

// 2
let subscription1 = publisher
.sink(receiveCompletion: { completion in
if case .failure(let err) = completion {
print("Sink1 Retrieving data failed with error \(err)")
}
}, receiveValue: { object in
print("Sink1 Retrieved object \(object)")
})

// 3
let subscription2 = publisher
.sink(receiveCompletion: { completion in
if case .failure(let err) = completion {
print("Sink2 Retrieving data failed with error \(err)")
}
}, receiveValue: { object in
print("Sink2 Retrieved object \(object)")
})

// 4
let subscription = publisher.connect()

In this code, you:

1. Create your DataTaskPublisher, map to its data and then multicast it. The
closure you pass must return a subject of the appropriate type. Alternately, you
can pass an existing subject to multicast(subject:). You‘ll learn more about
multicast in Chapter 13, “Resource Management.”

2. Subscribe a first time to the publisher. Since it‘s a ConnectablePublisher it

won‘t start working right away.

raywenderlich.com 217
Combine Chapter 9: Networking

3. Subscribe a second time.

4. Connect the publisher, when you‘re ready. It will start working and pushing
values to all of its subscribers.

With this code, you send the request one time and share the outcome to the two
subscribers.

Note: Make sure to store all of your Cancellables; otherwise, they would be
deallocated and canceled when leaving the current code scope, which would be
immediate in this specific case.

This process remains a bit convoluted, as Combine does not offer operators for this
kind of scenario like other reactive frameworks do. In Chapter 18, “Custom
Publishers & Handling Backpressure,” you‘ll explore crafting a better solution.

Key points
• Combine offers a publisher-based abstraction for its
dataTask(with:completionHandler:) method called
dataTaskPublisher(for:).

• You can decode Codable-conforming models using the built-in decode operator
on a publisher that emits Data values.

• While there‘s no operator to share a replay of a subscription with multiple

subscribers, you can recreate this behavior using a ConnectablePublisher and
the multicast operator.

raywenderlich.com 218
Combine Chapter 9: Networking

Where to go from here?

Great job on going through this chapter!

If you want to learn more about using Codable, you can check out the following
resources:

• “Encoding and Decoding in Swift” at raywenderlich.com: https://

www.raywenderlich.com/3418439-encoding-and-decoding-in-swift

• “Encoding and Decoding Custom Types” on Apple‘s official documentation: https://

developer.apple.com/documentation/foundation/archives_and_serialization/
encoding_and_decoding_custom_types

raywenderlich.com 219
10 Chapter 10: Debugging
By Florent Pillet

Understanding the event flow in asynchronous programs has always been a

challenge. It is particularly the case in the context of Combine, as chains of operators
in a publisher may not all emit events at the same time. For example, operators like
throttle(for:scheduler:latest:) will not emit all events they receive, so you
need to understand what’s going on. Combine provides a few operators to help with
debugging your reactive flows. Knowing them will help you troubleshoot puzzling
situations.

Printing events
The print(_:to:) operator is the first one you should use when you’re unsure
whether anything is going through your publishers. It’s a passthrough publisher
which prints a lot of information about what’s happening.

Even with simple cases like this one:

let subscription = (1...3).publisher

.print("publisher")
.sink { _ in }

The output is very detailed:

publisher: receive subscription: (1...3)

publisher: request unlimited
publisher: receive value: (1)
publisher: receive value: (2)
publisher: receive value: (3)
publisher: receive finished

raywenderlich.com 220
Combine Chapter 10: Debugging

Here you see that the print(_:to:) operators shows a lot of information, as it:

• Prints when it receives a subscription and shows the description of its upstream
publisher.

• Prints the subscriber‘s demand requests so you can see how many items are being
requested.

• Prints every value the upstream publisher emits.

• Finally, prints the completion event.

There is an additional parameter that takes a TextOutputStream object. You can use
this to redirect strings to print to a logger. You can also add information to the log,
like the current date and time, etc. The possibilities are endless!

For example, you can create a simple logger that displays the time interval between
each string so you can get a sense of how fast your publisher emits values:

class TimeLogger: TextOutputStream {

private var previous = Date()
private let formatter = NumberFormatter()

init() {
formatter.maximumFractionDigits = 5
formatter.minimumFractionDigits = 5
}

func write(_ string: String) {

let trimmed =
string.trimmingCharacters(in: .whitespacesAndNewlines)
guard !trimmed.isEmpty else { return }
let now = Date()
print("+\(formatter.string(for:
now.timeIntervalSince(previous))!)s: \(string)")
previous = now
}
}

It’s very simple to use in your code:

let subscription = (1...3).publisher

.print("publisher", to: TimeLogger())
.sink { _ in }

raywenderlich.com 221
Combine Chapter 10: Debugging

And the result displays the time between each printed line:

+0.00111s: publisher: receive subscription: (1...3)

+0.03485s: publisher: request unlimited
+0.00035s: publisher: receive value: (1)
+0.00025s: publisher: receive value: (2)
+0.00027s: publisher: receive value: (3)
+0.00024s: publisher: receive finished

As mentioned above, the possibilities are quite endless here.

Acting on events — performing side

effects
Besides printing out information, it is often useful to perform actions upon specific
events. We call this performing side effects, as actions you take “on the side” don’t
directly impact further publishers down the stream, but can have an effect like
modifying an external variable.

The
handleEvents(receiveSubscription:receiveOutput:receiveCompletion:rece
iveCancel:receiveRequest:) (wow, what a signature!) lets you intercept any and
all events in the lifecycle of a publisher and then take action at each step.

Imagine you‘re tracking an issue where a publisher must perform a network request,
then emit some data. When you run it, it never receives any data. What’s happening?
Is the request really working? Do you even listen to what comes back?

Consider this code:

let request = URLSession.shared

.dataTaskPublisher(for: URL(string: "https://
www.raywenderlich.com/")!)

request
.sink(receiveCompletion: { completion in
print("Sink received completion: \(completion)")
}) { (data, _) in
print("Sink received data: \(data)")
}

You run it and never see anything print. Can you see the issue by looking at the code?

raywenderlich.com 222
Combine Chapter 10: Debugging

If not, use handleEvents to track what‘s happening. You can insert this operator
between the publisher and sink:

.handleEvents(receiveSubscription: { _ in
print("Network request will start")
}, receiveOutput: { _ in
print("Network request data received")
}, receiveCancel: {
print("Network request cancelled")
})

Then, run the code again. This time you see some debugging output:

Network request will start

Network request cancelled

There! You found it: You forgot to keep the Cancellable around. So, the
subscription starts but gets canceled immediately. Now, you can fix your code by
retaining the Cancellable:

let subscription = request

.handleEvents...

Then, running your code again, you‘ll now see it behaving correctly:

Network request will start

Network request data received
Sink received data: 153253 bytes
Sink received completion: finished

Using the debugger as a last resort

The last resort operator is one you pull in situations where you really need to
introspect things at certain times in the debugger, because nothing else helped you
figure out what’s wrong.

The first simple operator is breakpointOnError(). As the name suggests, when you
use this operator, if any of the upstream publishers emits an error, Xcode will break
in the debugger to let you look at the stack and, hopefully, find why and where your
publisher errors out.

raywenderlich.com 223
Combine Chapter 10: Debugging

A more complete variant is

breakpoint(receiveSubscription:receiveOutput:receiveCompletion:). It
allows you to intercept various events and decide on a case-by-case basis whether
you want to pause the debugger.

For example, you could break only if certain values pass through the publisher:

.breakpoint(receiveOutput: { value in
return value > 10 && value < 15
})

Assuming the upstream publisher emits integer values, but values 11 to 14 should
never happen, you can configure breakpoint to break only in this case and let you
investigate!

You can also conditionally break subscription and completion times, but cannot
intercept cancelations like the handleEvents operator.

Note: None of the breakpoint publishers will work in playgrounds. You will see
an error that execution was interrupted, but it won‘t drop into the debugger.

Key points
• Track the lifecycle of a publisher with the print operator,

• Create your own TextOutputStream to customize the output strings,

• Use the handleEvents operator to intercept lifecycle events and perform actions,

• Use the breakpointOnError and breakpoint operators to break on specific

events.

Where to go from here?

You found out how to track what your publishers are doing, now it’s time... for
timers! Move on to the next chapter to learn how to trigger events at regular
intervals with Combine.

raywenderlich.com 224
11 Chapter 11: Timers
By Florent Pillet

Repeating and non-repeating timers are always useful when coding. Besides
executing code asynchronously, you often need to control when and how often a task
should repeat.

Before the Dispatch framework was available, developers relied on RunLoop to

asynchronously perform tasks and implement concurrency. Timer (NSTimer in
Objective-C) could be used to create repeating and non-repeating timers. Then
Dispatch arrived and with it, DispatchSourceTimer.

Although all of the above are capable of creating timers, not all timers are equal in
Combine. Read on!

Using RunLoop
The main thread and any thread you create, preferably using the Thread class, can
have its own RunLoop. Just invoke RunLoop.current from the current thread:
Foundation would create one for you if needed. Beware, unless you understand how
run loops operate — in particular, that you need a loop that runs the run loop —
you’ll be better off simply using the main RunLoop that runs the main thread of your
application.

Note: One important note and a red light warning in Apple’s documentation is
that the RunLoop class is not thread-safe. You should only call RunLoop
methods for the run loop of the current thread.

raywenderlich.com 225
Combine Chapter 11: Timers

RunLoop implements the Scheduler protocol you’ll learn about in Chapter 17,
“Schedulers.” It defines several methods which are relatively low-level, and the only
one that lets you create cancellable timers:

let runLoop = RunLoop.main

let subscription = runLoop.schedule(

after: runLoop.now,
interval: .seconds(1),
tolerance: .milliseconds(100)
) {
print("Timer fired")
}

This timer does not pass any value and does not create a publisher. It starts at the
date specified in the after: parameter with the specified interval and tolerance,
and that’s about it. Its only usefulness in relation to Combine is that the
Cancellable it returns lets you stop the timer after a while.

An example of this could be:

runLoop.schedule(after: .init(Date(timeIntervalSinceNow: 3.0)))

{
cancellable.cancel()
}

But all things considered, RunLoop is not the best way to create a timer. You’ll be
better off using the Timer class!

Using the Timer class

Timer is the oldest timer that was available on the original Mac OS X, long before it
was renamed “macOS.” It has always been tricky to use because of its delegation
pattern and tight relationship with RunLoop. Combine brings a modern variant you
can directly use as a publisher without all the setup boilerplate.

You can create a repeating timer publisher this way:

let publisher = Timer.publish(every: 1.0, on: .main,

in: .common)

raywenderlich.com 226
Combine Chapter 11: Timers

The two parameters on and in determine:

• Which RunLoop your timer attaches to. Here, the main thread‘s RunLoop.

• Which run loop mode(s) the timer runs in. Here, the default run loop mode.

Unless you understand how a run loop operates, you should stick with these default
values. Run loops are the basic mechanism for asynchronous event source processing
in macOS, but their API is a bit cumbersome. You can get a RunLoop for any Thread
that you create yourself or obtain from Foundation by calling RunLoop.current, so
you could write the following as well:

let publisher = Timer.publish(every: 1.0, on: .current,

in: .common)

Note: Running this code on a Dispatch queue other than

DispatchQueue.main may lead to unpredictable results. The Dispatch
framework manages its threads without using run loops. Since a run loop
requires one of its run methods to be called to process events, you would never
see the timer fire on any queue other than the main one. Stay safe and target
RunLoop.main for your Timers.

The publisher the timer returns is a ConnectablePublisher. It’s a special variant of

Publisher that won’t start firing upon subscription until you explicitly call its
connect() method. You can also use the autoconnect() operator which
automatically connects when the first subscriber subscribes.

Note: You‘ll learn more about connectable publishers in Chapter 13, “Resource
Management.”

Therefore, the best way to create a publisher that will start a timer upon subscription
is to write:

let publisher = Timer

.publish(every: 1.0, on: .main, in: .common)
.autoconnect()

The timer repeatedly emits the current date, its Publisher.Output type being a
Date. You can make a timer that emits increasing values by using the scan operator.

raywenderlich.com 227
Combine Chapter 11: Timers

For example:

let subscription = Timer

.publish(every: 1.0, on: .main, in: .common)
.autoconnect()
.scan(0) { counter, _ in counter + 1 }
.sink { counter in
print("Counter is \(counter)")
}

There is an additional Timer.publish() parameter you didn’t see here: tolerance.

It specifies the acceptable deviation from the duration you asked for, as a
TimeInterval. But note that using a value lower than your RunLoop’s
minimumTolerance may not produce the expected results.

Using DispatchQueue
You can use a dispatch queue to generate timer events. While the Dispatch
framework has a DispatchTimerSource event source, Combine surprisingly doesn’t
provide a timer interface to it. Instead, you’re going to use an alternative method to
generate timer events in your queue. This can be a bit convoluted, though:

let queue = DispatchQueue.main

// 1
let source = PassthroughSubject<Int, Never>()

// 2
var counter = 0

// 3
let cancellable = queue.schedule(
after: queue.now,
interval: .seconds(1)
) {
source.send(counter)
counter += 1
}

// 4
let subscription = source.sink {
print("Timer emitted \($0)")
}

raywenderlich.com 228
Combine Chapter 11: Timers

In the previous code, you:

1. Create a Subject you will send timer values to.

2. Prepare a counter. You‘ll increment it every time the timer fires.

3. Schedule a repeating action on the selected queue every second. The action starts
immediately.

4. Subscribe to the subject to get the timer values.

As you can see, this is not pretty. It would help to move this code to a function and
pass both the interval and the start time.

Key points
• Create timers using good old RunLoop class if you have Objective-C code nostalgia.

• Use Timer.publish to obtain a publisher which generates values at given

intervals on the specified RunLoop.

• Use DispatchQueue.schedule for modern timers emitting events on a dispatch

queue.

Where to go from here?

In Chapter 18, “Custom Publishers & Handling Backpressure,” you’ll learn how to
write your own publishers, and you’ll create an alternative timer publisher using
DispatchSourceTimer.

But don’t hurry! There is plenty to learn before that, starting with Key-Value
Observing in the next chapter.

raywenderlich.com 229
12 Chapter 12: Key-Value
Observing
By Florent Pillet

Dealing with change is at the core of Combine. Publishers let you subscribe to them
to handle asynchronous events. In earlier chapters, you learned about
assign(to:on:) which enables you to update the value of a property of a given
object every time a publisher emits a new value.

But, what about a mechanism to observe changes to single variables?

Combine ships with a few options around this:

• It provides a publisher for any property of an object that is KVO (Key-Value

Observing)-compliant.

• The ObservableObject protocol handles cases where multiple variables could

change.

Introducing publisher(for:options:)
KVO has always been an essential component of Objective-C. A large number of
properties from Foundation, UIKit and AppKit classes are KVO-compliant. Therefore,
you can observe their changes using the KVO machinery.

It’s easy to observe KVO-compliant properties. Here is an example using an

OperationQueue (a class from Foundation):

let queue = OperationQueue()

let subscription = queue.publisher(for: \.operationCount)

.sink {

raywenderlich.com 230
Combine Chapter 12: Key-Value Observing

print("Outstanding operations in queue: \($0)")

}

Every time you add a new operation to the queue, its operationCount increments,
and your sink receives the new count. When the queue has consumed an operation,
the count decrements and again, your sink receives the updated count.

There are many other framework classes exposing KVO-compliant properties. Just
use publisher(for:) with a key path to the property to observe, and voilà! You get a
publisher capable of emitting value changes. You’ll learn more about this and
available options later in this chapter.

Note: There is no central list of KVO-compliant properties throughout the

frameworks. The documentation for each class usually indicates which
properties are KVO-compliant. But sometimes the documentation can be
sparse, and you’ll only find a quick note in the documentation for some of the
properties.

Preparing and subscribing to your own

KVO-compliant properties
You can also use Key-Value Observing in your own code, provided that:

• Your objects are classes (not structs) and inherit from NSObject,

• You mark the properties to make observable with the @objc dynamic attributes.

Once you do this, your object and the properties you marked become KVO-compliant
and can be observed with Combine!

Note: While the Swift language doesn’t directly support KVO, marking your
properties @objc dynamic forces the compiler to generate hidden methods
that trigger the KVO machinery. Describing this machinery is out of the scope
of this book. Suffice to say the machinery heavily relies on specific methods
from the NSObject protocol, which explains why your objects need to inherit
from it.

raywenderlich.com 231
Combine Chapter 12: Key-Value Observing

Try an example in a playground:

// 1
class TestObject: NSObject {
// 2
@objc dynamic var integerProperty: Int = 0
}

let obj = TestObject()

// 3
let subscription = obj.publisher(for: \.integerProperty)
.sink {
print("integerProperty changes to \($0)")
}

// 4
obj.integerProperty = 100
obj.integerProperty = 200

In the above code, you:

1. Create a class that inherits the NSObject protocol. This is required for KVO.

2. Mark any property you want to make observable as @objc dynamic.

3. Create and subscribe to a publisher observing the integerProperty property of

obj.

4. Make a couple of updates.

When running this code in a playground, can you guess what the debug console
displays?

You may be surprised, but here is the display you obtain:

integerProperty changes to 0
integerProperty changes to 100
integerProperty changes to 200

You first get the initial value of integerProperty, which is 0, then you receive the
two changes. You can avoid this initial value if you‘re not interested in it — read on
to find out how!

Did you notice that in TestObject you are using a plain Swift type (Int) and that
KVO, which is an Objective-C feature, still works? KVO will work fine with any
Objective-C type and with any Swift type bridged to Objective-C. This includes all the
native Swift types as well as arrays and dictionaries, provided their values are all
bridgeable to Objective-C.

raywenderlich.com 232
Combine Chapter 12: Key-Value Observing

Try it! Add a couple more properties to TestObject:

@objc dynamic var stringProperty: String = ""

@objc dynamic var arrayProperty: [Float] = []

As well as subscriptions to their publishers:

let subscription2 = obj.publisher(for: \.stringProperty)

.sink {
print("stringProperty changes to \($0)")
}

let subscription3 = obj.publisher(for: \.arrayProperty)

.sink {
print("arrayProperty changes to \($0)")
}

And finally, some property changes:

obj.stringProperty = "Hello"
obj.arrayProperty = [1.0]
obj.stringProperty = "World"
obj.arrayProperty = [1.0, 2.0]

You‘ll see both initial values and changes appear in your debug area. Nice!

If you ever use a pure-Swift type that isn‘t bridged to Objective-C though, you‘ll start
running into trouble:

struct PureSwift {
let a: (Int, Bool)
}

Then, add a property to TestObject:

@objc dynamic var structProperty: PureSwift = .init(a:

(0,false))

You‘ll immediately see an error in Xcode, stating that “Property cannot be marked
@objc because its type cannot be represented in Objective-C.” Here, you reached the
limits of Key-Value Observing.

raywenderlich.com 233
Combine Chapter 12: Key-Value Observing

Note: Be careful when observing changes on system frameworks objects. Make

sure the documentation mentions the property is observable because you can‘t
have a clue by just looking at a system object‘s property list. This is true for
Foundation, UIKit, AppKit, etc. Historically, properties had to be made “KVO-
aware” to be observable.

Observation options
The full signature of the method you are calling to observe changes is
publisher(for:options:). The options parameter is an option set with four
values: .initial, .prior, .old and .new. The default is [.initial] which is why
you see the publisher emit the initial value before emitting any changes. Here is a
breakdown of the options:

• .initial emits the initial value.

• .prior emits both the previous and the new value when a change occurs.

• .old and .new are unused in this publisher, they both do nothing (just let the new
value through).

If you don‘t want the initial value, you can simply write:

obj.publisher(for: \.stringProperty, options: [])

If you specify .prior, you‘ll get two separate values every time a change occurs.
Modifying the integerProperty example:

let subscription = obj.publisher(for: \.integerProperty,

options: [.prior])

You would now see the following in the debug console for the integerProperty
subscription:

integerProperty changes to 0
integerProperty changes to 100
integerProperty changes to 100
integerProperty changes to 200

The property first changes from 0 to 100, so you get two values: 0 and 100. Then, it
changes from 100 to 200 so you again get two values: 100 and 200.

raywenderlich.com 234
Combine Chapter 12: Key-Value Observing

ObservableObject
Combine‘s ObservableObject protocol works on Swift objects, not just on objects
derived from NSObject. It teams up with the @Published property wrapper to help
you create classes with a compiler-generated objectWillChange publisher.

It saves you from writing a lot of boilerplate and allows creating objects which self-
monitor their own properties and notify when any of them will change.

Here is an example:

class MonitorObject: ObservableObject {

@Published var someProperty = false
@Published var someOtherProperty = ""
}

let object = MonitorObject()

let subscription = object.objectWillChange.sink {
print("object will change")
}

object.someProperty = true
object.someOtherProperty = "Hello world"

The ObservableObject protocol conformance makes the compiler automatically

generate the objectWillChange property. It is an ObservableObjectPublisher
which emits Void items and Never fails.

You‘ll get objectWillChange firing every time one of the object‘s @Published
variables change. Unfortunately, you can‘t know which property actually changed.
This is designed to work very well with SwiftUI which coalesces events to streamline
screen updates.

raywenderlich.com 235
Combine Chapter 12: Key-Value Observing

Key points
• Key-Value Observing mostly relies on the Objective-C runtime and methods of the
NSObject protocol.

• Many Objective-C classes in Apple frameworks offer some KVO-compliant

properties.

• You can make your own properties observable provided they are in a class
inheriting NSObject, and marked with the @objc dynamic attributes.

• You can also inherit from ObservableObject and use @Published for your
properties. The compiler-generated objectWillChange publisher triggers every
time one of the @Published properties changes (but doesn’t tell you which one
changed).

Where to go from here?

Observing is a lot of fun, but sharing is caring! Keep reading to learn about Resources
in Combine, and how you can save them by sharing them!

raywenderlich.com 236
13 Chapter 13: Resource
Management
By Florent Pillet

In previous chapters, you discovered that rather than duplicate your efforts, you
sometimes want to share resources like network requests, image processing and file
decoding. Anything resource-intensive that you can avoid repeating multiple times is
worth looking into. In other words, you should share the outcome of a single resource
– the values a publisher’s work produces – between multiple subscribers rather than
duplicate that outcome.

Combine offers two operators for you to manage resources: The share() operator
and the multicast(_:) operator.

The share() operator

The purpose of this operator is to let you obtain a publisher by reference rather than
by value. Publishers are usually structs: When you pass a publisher to a function or
store it in several properties, Swift copies it several times. When you subscribe to
each of the copies, the publisher can only do one thing: Start the work it’s designed
to do and deliver the values.

The share() operator returns an instance of the Publishers.Share class. This new
publisher “shares” the upstream publisher. It will subscribe to the upstream
publisher once, with the first incoming subscriber. It will then relay the values it
receives from the upstream publisher to this subscriber and to all those that
subscribe after it.

raywenderlich.com 237
Combine Chapter 13: Resource Management

Note: New subscribers will only receive values the upstream publisher emits
after they subscribe. There’s no buffering or replay involved. If a subscriber
subscribes to a shared publisher after the upstream publisher has completed,
that new subscriber only receives the completion event.

To put this concept into practice, imagine you’re performing a network request, like
you learned how to do in Chapter 9, “Networking.” You want multiple subscribers to
receive the result without requesting multiple times. Your code would look
something like this:

let shared = URLSession.shared

.dataTaskPublisher(for: URL(string: "https://
www.raywenderlich.com")!)
.map(\.data)
.print("shared")
.share()

print("subscribing first")

let subscription1 = shared.sink(

receiveCompletion: { _ in },
receiveValue: { print("subscription1 received: '\($0)'") }
)

print("subscribing second")

let subscription2 = shared.sink(

receiveCompletion: { _ in },
receiveValue: { print("subscription2 received: '\($0)'") }
)

The first subscriber triggers the “work” (in this case, performing the network request)
of share()’s upstream publisher. The second subscriber will simply “connect” to it
and receive values at the same time as the first.

Running this code in a playground, you’d see an output similar to:

subscribing first
shared: receive subscription: (DataTaskPublisher)
shared: request unlimited
subscribing second
shared: receive value: (153217 bytes)
subscription1 received: '153217 bytes'
subscription2 received: '153217 bytes'
shared: receive finished

raywenderlich.com 238
Combine Chapter 13: Resource Management

Using the print operator‘s output, you can see that:

• The first subscription triggers a subscription to the DataTaskPublisher.

• The second subscription doesn’t change anything: The publisher keeps running.
No second request goes out.

• When the request completes, the publisher emits the resulting data to both
subscribers then completes.

To verify that the request is only sent once, you could comment out the share() line
and the output would look similar to this:

subscribing first
shared: receive subscription: (DataTaskPublisher)
shared: request unlimited
subscribing second
shared: receive subscription: (DataTaskPublisher)
shared: request unlimited
shared: receive value: (153217 bytes)
subscription1 received: '153217 bytes'
shared: receive finished
shared: receive value: (153217 bytes)
subscription2 received: '153217 bytes'
shared: receive finished

You can clearly see that when the DataTaskPublisher is not shared, it receives two
subscriptions! And in this case, performs the request twice.

But there’s a problem: What if the second subscriber comes after the request has
completed? You could simulate this case by delaying the second subscription. Don’t
forget to uncomment share() if you’re following along in a playground:

var subscription2: AnyCancellable? = nil

DispatchQueue.main.asyncAfter(deadline: .now() + 5) {
print("subscribing second")

subscription2 = shared.sink(
receiveCompletion: { print("subscription2 completion \($0)")
},
receiveValue: { print("subscription2 received: '\($0)'") }
)
}

raywenderlich.com 239
Combine Chapter 13: Resource Management

Running this, you’d see that subscription2 receives nothing if the delay is longer
than the time it takes for the request to complete:

subscribing first
shared: receive subscription: (DataTaskPublisher)
shared: request unlimited
shared: receive value: (153217 bytes)
subscription1 received: '153217 bytes'
shared: receive finished
subscribing second
subscription2 completion finished

By the time subscription2 is created, the request has already completed and the
resulting data has been emitted. How can you make sure both subscriptions receive
the request result?

The multicast(_:) operator

To share a single subscription to a publisher and replay the values to new subscribers
even after the upstream publisher has completed, you need something like a
shareReplay() operator. Unfortunately, this operator is not part of Combine.
However, you’ll learn how to create one in Chapter 18, “Custom Publishers and
Handling Backpressure.”

In Chapter 9, “Networking,” you used multicast(_:). This operator builds on

share() and uses a Subject of your choice to publish values to subscribers.

The unique characteristic of multicast(_:) is that the publisher it returns is a

ConnectablePublisher. What this means is it won’t subscribe to the upstream
publisher until you call its connect(). This leaves you ample time to set up all the
subscribers you need before letting it connect to the upstream publisher and start
the work.

To adjust the previous example to use multicast(_:) you could write:

// 1
let subject = PassthroughSubject<Data, URLError>() // 2

// 2
let multicasted = URLSession.shared
.dataTaskPublisher(for: URL(string: "https://
www.raywenderlich.com")!)
.map(\.data)
.print("shared")
.multicast(subject: subject)

raywenderlich.com 240
Combine Chapter 13: Resource Management

// 3
let subscription1 = multicasted
.sink(
receiveCompletion: { _ in },
receiveValue: { print("subscription1 received: '\($0)'") }
)

let subscription2 = multicasted

.sink(
receiveCompletion: { _ in },
receiveValue: { print("subscription2 received: '\($0)'") }
)

// 4
multicasted.connect()

// 5
subject.send(Data())

Here’s what this code does:

1. Prepares a subject, which relays the values and completion event the upstream
publisher emits.

2. Prepares the multicasted publisher, using the above subject.

3. Subscribes to the shared — i.e., multicasted — publisher, like earlier in this

chapter.

4. Instructs the publisher to connect to the upstream publisher.

5. Sends empty data just to test that both subscriptions receive the data.

This effectively starts the work, but only after you’ve had time to set up all your
subscriptions. This way, you make sure no subscriber will miss the downloaded data.

The resulting output, if you run this in a playground, would be:

subscribing first
shared: receive subscription: (DataTaskPublisher)
shared: request unlimited
subscription1 received: '0 bytes'
subscription2 received: '0 bytes'
shared: receive cancel

raywenderlich.com 241
Combine Chapter 13: Resource Management

Note: A multicast publisher, like all ConnectablePublishers, also provides an

autoconnect() method, which makes it work like share(): The first time you
subscribe to it, it connects to the upstream publisher and starts the work
immediately. This is useful in scenarios where the upstream publisher emits a
single value and you can use a CurrentValueSubject to share it with
subscribers.

Sharing subscription work, specifically for resource-heavy processes such as

networking, is a must for most modern apps. Not keeping an eye on this could result
not only in memory issues, but also possibly bombarding your server with a ton of
unnecessary network requests.

Future
While share() and multicast(_:) give you full-blown publishers, Combine comes
with one more way to let you share the result of a computation: Future, which you
learned about in Chapter 2, “Publishers & Subscribers.”

You create a Future by handing it a closure which receives a Promise argument. You
further fulfill the promise whenever you have a result available, either successful or
failed. Look at an example to refresh your memory:

let future = Future<Int, Error> { fulfill in

do {
let result = try performSomeWork()
fulfill(.success(result))
} catch {
fulfill(.failure(error))
}
}

This simple synchronous example tries to perform some work and immediately
fulfills the promise with the result of a computation, or with the thrown error in case
of a failure. What’s interesting from a resource perspective is that:

• Future is a class.

• Upon creation, it immediately invokes your closure to start computing the result
and fulfill the promise as soon as possible.

• It stores the result of the fulfilled Promise and delivers it to current and future
subscribers.

raywenderlich.com 242
Combine Chapter 13: Resource Management

In practice, it means that Future is a convenient way to immediately start

performing some work (without waiting for subscriptions) while performing work
only once and delivering the result to any amount of subscribers.

It‘s a good candidate to use for when you need to share the single result a network
request produces!

Note: Even if you never subscribe to a Future, creating it will call your closure
and perform the work. You cannot rely on Deferred to defer closure execution
until a subscriber comes in, because Deferred is a struct and would cause a
new Future to be created every time there is a new subscriber!

Key points
• Sharing subscription work is critical when dealing with resource-heavy processes,
such as networking.

• Use share() when you simply need to share a publisher with multiple subscribers.

• Use multicast(_:) when you need fine control over when the upstream publisher
starts to work and how values propagate to subscribers.

• Use Future to share the single result of a computation to multiple subscribers.

Where to go from here?

Congratulations for finishing the last theoretical mini-chapter for this section!

You‘ll wrap up this section by working on a hands-on project, where you’ll build a
API client to interact with the Hacker News API. Time to move along!

raywenderlich.com 243
14 Chapter 14: In Practice:
Project "News"
By Marin Todorov

In the past few chapters, you learned about quite a few practical applications of the
Combine integration in Foundation types. You learned how to use URLSession‘s data
task publisher to make network calls, you saw how to observe KVO-compatible
objects with Combine and more.

In this chapter, you will combine your solid knowledge about operators with some of
the Foundation integrations you just discovered and will work through a series of
tasks like in the previous “In Practice” chapter. This time around, you will work on
building a Hacker News API client.

“Hacker News,” whose API you are going to be using in this chapter, is a social news
website focused on computers and entrepreneurship. If you haven‘t already, you can
check them out at: https://news.ycombinator.com.

In this chapter, you will work in an Xcode playground focusing only on the API client
itself.

raywenderlich.com 244
Combine Chapter 14: In Practice: Project "News"

In Chapter 15, “In Practice: Combine & SwiftUI,” you will take the completed API and
use it to build a real Hacker News reader app by plugging the network layer into a
SwiftUI-based user interface. Along the way, you will learn the basics of SwiftUI and
how to make your Combine code work with the new declarative Apple framework for
building amazing, reactive app UIs.

Without further ado, let‘s get started!

Getting started with the Hacker News API

Open the included starter playground API.playground in projects/starter and peek
inside. You will find some simple starter code included to help you hit the ground
running and let you focus on Combine code only:

Inside the API type, you will find two nested helper types:

• An enum called Error which features two custom errors your API will throw in
case it cannot reach the server or it cannot decode the server response.

• A second enum called EndPoint which contains the URLs of the two API endpoints
your type is going to be connecting to.

raywenderlich.com 245
Combine Chapter 14: In Practice: Project "News"

Further down, you will find the maxStories property. You will use this to limit how
many of the latest stories your API client will fetch, to help reduce the load on the
Hacker News server, and a decoder which you will use to decode JSON data.

Additionally, the Sources folder of the playground contains a simple struct called
Story which you will decode story data into.

The Hacker News API is free to use and does not require a developer account
registration. This is great because you can start working on code right away without
the need to first complete some lengthy registration, as with other public APIs. The
Hacker News team wins a ton of karma points!

Getting a single story

Your first task is to add a method to API which will contact the server using the
EndPoint type to get the correct endpoint URL and will fetch the data about a single
story. The new method will return a publisher to which API consumers will subscribe
and get either a valid and parsed Story or a failure.

Scroll down the playground source code and find the comment saying // Add your
API code here. Just below that line, insert a new method declaration:

func story(id: Int) -> AnyPublisher<Story, Error> {

return Empty().eraseToAnyPublisher()
}

To avoid compilation errors in your playground, you return an Empty publisher which
completes immediately. As you‘ll finish building the method body, you‘ll remove the
expression and return your new subscription, instead.

As mentioned, this publisher‘s output is a Story and its failure is the custom
API.Error type. As you will see later on, in case there are network errors or other
mishaps, you will need to convert those into one of the API.Error cases to match
the expected return type.

Start modeling the subscription by creating a network request to the single-story

endpoint of the Hacker News API. Inside the new method, above the return
statement, insert:

URLSession.shared
.dataTaskPublisher(for: EndPoint.story(id).url)

raywenderlich.com 246
Combine Chapter 14: In Practice: Project "News"

You start by making a request to Endpoint.story(id).url. The url property of the

endpoint contains the complete HTTP URL to request. The single story URL looks
like this (with a matching ID): https://hacker-news.firebaseio.com/v0/item/
12345.json (Visit https://bit.ly/2nL2ojS if you'd like to preview the API response.)

Next, to parse JSON on a background thread and keep the rest of the app responsive,
let‘s create a new custom dispatch queue. Add a new property to API above the
story(id:) method like so:

private let apiQueue = DispatchQueue(label: "API",

qos: .default,
attributes: .concurrent)

You will use this queue to process JSON responses and, therefore, you need to switch
your network subscription to that queue. Back in story(id:), add the line below
calling dataTaskPublisher(for:):

.receive(on: apiQueue)

Once you‘ve switched to the background queue, you need to fetch the JSON data out
of the response. The dataTaskPublisher(for:) publisher returns an output of type
(Data, URLResponse) as a tuple but for your subscription, you need only the data.

Add another line to the method to map the current output to only the data from the
resulting tuple:

.map(\.data)

The output type of this operator is Data, which you can feed to a decode operator
and try converting the response to a Story.

Append to the subscription:

.decode(type: Story.self, decoder: decoder)

In case anything but a valid story JSON was returned, decode(...) will throw an
error and the publisher will complete with a failure.

You will learn about error handling in detail in Chapter 16, “Error Handling.” In the
current chapter, you will use few operators and get a taste of a few different ways to
handle errors but you will not go into the nitty-gritty of how things work.

raywenderlich.com 247
Combine Chapter 14: In Practice: Project "News"

For the current story(id:) method, you will return an empty publisher in case
things go south for any reason. This is achieved easily by using the catch operator.
Add to the subscription:

.catch { _ in Empty<Story, Error>() }

You ignore the thrown error and return Empty(). This, as you hopefully still
remember, is a publisher that completes immediately without emitting any output
values like so:

Handling the upstream errors this way via catch(_) allows you to:

• Emit the value and complete if you get back a Story.

• Return an Empty publisher which completes successfully without emitting any

values, in case of a failure.

Next, to wrap up the method code and return your neatly designed publisher, you
need to replace the current subscription at the end. Add:

.eraseToAnyPublisher()

You can now remove the temporary Empty you‘ve added before. Find the following
line and remove it:

return Empty().eraseToAnyPublisher()

raywenderlich.com 248
Combine Chapter 14: In Practice: Project "News"

Your code should now compile with no issues, but just to make sure you haven‘t
missed a step in all the excitement, review your progress so far and make sure your
completed code looks like this:

func story(id: Int) -> AnyPublisher<Story, Error> {

URLSession.shared
.dataTaskPublisher(for: EndPoint.story(id).url)
.receive(on: apiQueue)
.map(\.data)
.decode(type: Story.self, decoder: decoder)
.catch { _ in Empty<Story, Error>() }
.eraseToAnyPublisher()
}

Even though your code compiles, this method still won‘t produce any output just yet.
You‘re about to take care of that next.

Now you can instantiate API and try calling into the Hacker News server.

Scroll down just a bit and find the comment line // Call the API here. This is a
good spot to make a test API call. Insert the following code:

let api = API()

var subscriptions = [AnyCancellable]()

Fetch a story by providing a random ID to test with by adding:

api.story(id: 1000)
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

You create a new publisher by calling api.story(id: 1000) and subscribe to it via
sink(...) which prints any output values or completion event. To keep the
subscription alive until the work is done, you store it in subscriptions.

raywenderlich.com 249
Combine Chapter 14: In Practice: Project "News"

As soon as the playground runs again, it will make a network call to hacker-
news.firebaseio.com and print the result in the console:

The returned JSON data from the server is a rather simple structure like this:

{
"by":"python_kiss",
"descendants":0,
"id":1000,
"score":4,
"time":1172394646,
"title":"How Important is the .com TLD?",
"type":"story",
"url":"http://www.netbusinessblog.com/2007/02/19/how-
important-is-the-dot-com/"
}

The Codable conformance of Story parses and stores the values of the following
properties: by, id, time, title and url.

Once the request completes successfully, you‘ll see the following output, or a similar
output in case you changed the 1000 value in the request, in the console:

How Important is the .com TLD?

by python_kiss
http://www.netbusinessblog.com/2007/02/19/how-important-is-the-
dot-com/
-----
finished

The Story type conforms to CustomDebugStringConvertible and it has a custom

debugDescription that returns the title, author name and story URL neatly ordered,
like above.

raywenderlich.com 250
Combine Chapter 14: In Practice: Project "News"

The output ends with a finished completion event. To try what happens in case of
an error, replace the id 1000 with -5 and check the output in the console. You will
only see finished printed because you caught the error and returned Empty().

Nice work! The first method of the API type is completed and you exercised some of
the concepts you covered in previous chapters like calling the network and decoding
JSON. Additionally you got a gentle introduction to basic dispatch queue switching
and some easy error handling. These will be covered in more detail in future
chapters.

Despite what an incredibly nice exercise this task was, you‘re probably hungry for
more. So, in the next section, you will dig deeper and lay some serious code down.

Multiple stories via merging publishers

Getting a single story out of the API server was a relatively straight forward task.
Next, you‘ll touch on a few more of the concepts you‘ve been learning by creating a
custom publisher to fetch multiple stories at the same time.

The new method mergedStories(ids:) will get a story publisher for each of the
given story ids and merge them all together. Add this new method declaration to the
API type after the story(id:) method you implemented earlier:

func mergedStories(ids storyIDs: [Int]) -> AnyPublisher<Story,

Error> {

What this method will essentially do is call story(id:) for each of the given ids and
then flatten the result into a single stream of output values.

First of all, to reduce the number of network calls during development, you will fetch
only the first maxStories ids from the provided list. Start the new method by
inserting the following code:

let storyIDs = Array(storyIDs.prefix(maxStories))

To get started, create the first publisher:

precondition(!storyIDs.isEmpty)

let initialPublisher = story(id: storyIDs[0])

let remainder = Array(storyIDs.dropFirst())

raywenderlich.com 251
Combine Chapter 14: In Practice: Project "News"

By using story(id:), you create the initialPublisher publisher that fetches the
story with the first id in the list.

Next, you will use reduce(_:_:) from the Swift standard library on the remaining
story ids to merge each next story publisher into the initial publisher like so:

To reduce the rest of the stories into the initial publisher add:

return remainder.reduce(initialPublisher) { combined, id in

reduce(_:_:) will start with the initial publisher and provide each of the ids in the
remainder array to the closure to process. Insert this code to create a new publisher
for the given story id in the empty closure, and merge it to the current combined
result:

return combined
.merge(with: story(id: id))
.eraseToAnyPublisher()

The final result is a publisher which emits each successfully fetched story and
ignores any errors that each of the single-story publishers might encounter.

Note: Congratulations, you just created a custom implementation of the

MergeMany publisher. Working through the code yourself was not in vain
though. You learned about operator composition and how to apply operators
like merge and reduce in a real-world use case.

raywenderlich.com 252
Combine Chapter 14: In Practice: Project "News"

With the new API method completed, scroll down to this code and comment or
delete it to speed up the execution of the playground while testing your newer code:

api.story(id: -5)
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

In place of the just deleted code, insert:

api.mergedStories(ids: [1000, 1001, 1002])

.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

Let the playground run one more time with your latest code. This time, you should
see in the console these three story summaries:

How Important is the .com TLD?

by python_kiss
http://www.netbusinessblog.com/2007/02/19/how-important-is-the-
dot-com/
-----

Wireless: India's Hot, China's Not

by python_kiss
http://www.redherring.com/Article.aspx?a=21355
-----

The Battle for Mobile Search

by python_kiss
http://www.businessweek.com/technology/content/feb2007/
tc20070220_828216.htm?campaign_id=rss_daily
-----
finished

Another glorious success along your path of learning Combine! In this section, you
wrote a method that combines any number of publishers and reduces them to a
single one. That‘s very helpful code to have around, as the built-in merge operator
can merge only up to 8 publishers. Sometimes, however, you just don‘t know how
many publishers you‘ll need in advance!

raywenderlich.com 253
Combine Chapter 14: In Practice: Project "News"

Getting the latest stories

In this final chapter section, you will work on creating an API method that fetches
the list of latest Hacker News stories.

This chapter is following a bit of a pattern. First, you reused your single story method
to fetch multiple stories. Now, you are going to reuse the multiple stories method to
fetch the list of latest stories.

Add the new empty method declaration to the API type as follows:

func stories() -> AnyPublisher<[Story], Error> {

return Empty().eraseToAnyPublisher()
}

Like before, you return an Empty object to prevent any compilation errors while you
construct your method body and publisher.

Unlike before, though, this time your returned publisher‘s output is a list of stories.
You will design the publisher to fetch multiple stories and accumulate them in an
array, emitting each intermediary state as the responses come in from the server.

This behavior will allow you to, in the next chapter, bind this new publisher directly
to a List UI control that will automatically animate the stories live on-screen as
they come in from the server.

Begin, as you did previously, by firing off a network request to the Hacker News API.
Insert the following in your new method, above the return statement:

URLSession.shared
.dataTaskPublisher(for: EndPoint.stories.url)

The stories endpoint lets you hit the following URL to get the latest story ids:
https://hacker-news.firebaseio.com/v0/newstories.json.

Again, you need to grab the data component of the emitted result. So, map the
output by adding:

.map(\.data)

The JSON response you will get from the server is a plain list like this:

[1000, 1001, 1002, 1003]

raywenderlich.com 254
Combine Chapter 14: In Practice: Project "News"

You need to parse the list as an array of integer numbers and, if that succeeds, you
can use the ids to fetch the matching stories.

Append to the subscription:

.decode(type: [Int].self, decoder: decoder)

This will map the current subscription output to an [Int] and you will use it to fetch
the corresponding stories one-by-one from the server.

Now is the moment, however, to go back to the topic of error handling for a moment.
When fetching a single story, you just ignore any errors. But, in stories(), let‘s see
how you can do a little more than that.

API.Error is the error type to which you will constrain the errors thrown from
stories(). You have two errors defined as enumeration cases:

• invalidResponse: for when you cannot decode the server response into the
expected type.

• addressUnreachable(URL): for when you cannot reach the endpoint URL.

Currently, your subscription code in stories() can throw two types of errors:

• dataTaskPublisher(for:) could throw different variations of a URLError when a

network problem occurs.

• decode(type:decoder:) could throw a decoding error when the JSON doesn‘t

match the expected type.

Your next task is to handle those various errors in a way that would map them to the
single API.Error type to match the expected failure of the returned publisher.

You will jump the gun yet another time and get a “soft” introduction to another error
handling operator. Append this code to your current subscription, after decode:

.mapError { error -> API.Error in

switch error {
case is URLError:
return Error.addressUnreachable(EndPoint.stories.url)
default:
return Error.invalidResponse
}
}

raywenderlich.com 255
Combine Chapter 14: In Practice: Project "News"

mapError handles any errors occurring upstream and allows you to map them into a
single error type — similar to how you use map to change the type of the output.

In the code above, you switch over any errors and:

• In case error is of type URLError and therefore occurred while trying to reach the
stories server endpoint, you return .addressUnreachable(_).

• Otherwise, you return .invalidResponse as the only other place where an error
could occur. Once successfully fetched, the network response is decoding the JSON
data.

With that, you matched the expected failure type in stories() and can leave it to
the API consumers to handle errors downstream. You will use stories() in the next
chapter. So, you will do a little more with error handling before you get to Chapter
16, “Error Handling,” and dive into the details.

So far, the current subscription fetches a list of ids from the JSON API but doesn‘t do
much on top of that. Next, you will use a few operators to filter unwanted content
and map the id list to the actual stories.

First, filter empty results — in case the API goes bonkers and returns an empty list for
its latest stories. Append:

.filter { !$0.isEmpty }

This will guarantee that downstream operators receive a list of story ids with at least
one element. This is very handy because, as you remember, mergedStories(ids:)
has a precondition ensuring that its input parameter is not empty.

To use mergedStories(ids:) and fetch the story details, you will flatten all the
story publishers by appending a flatMap operator:

.flatMap { storyIDs in
return self.mergedStories(ids: storyIDs)
}

raywenderlich.com 256
Combine Chapter 14: In Practice: Project "News"

Merging all the publishers into a single downstream will produce a continuous
stream of Story values. These are emitted as soon as they are fetched from the
network:

You could leave the current subscription as is right now but you‘d like to design the
API to be easily bindable to a list UI control. This will allow the consumers to simply
subscribe stories() and assign the result to an [Story] property in their view
controller or SwiftUI view.

To achieve that, you will need to aggregate the emitted stories and map the
subscription to return an ever-growing array — instead of single Story values.

It‘s time for some serious magic! Remember the scan operator from Chapter 3,
“Transforming Operators” I know that was some time ago, but, this is the operator
that will help you achieve your current task. So, if needed, jump back to that chapter
and come back here when refreshed on scan.

Append to your current subscription:

.scan([]) { stories, story -> [Story] in

return stories + [story]
}

You let scan(...) start emitting with an empty array. Each time a new story is being
emitted, you append it to the current aggregated result via stories + [story].

raywenderlich.com 257
Combine Chapter 14: In Practice: Project "News"

This addition to the subscription code changes its behavior so that you get the — sort
of — buffered contents each time a new story is fetched from the batch you are
working on:

Finally, it can‘t hurt to sort the stories before emitting output. Story conforms to
Comparable so you don‘t need to implement any custom sorting. You just need to
call sorted() on the result. Append:

.map { $0.sorted() }

Wrap up the current, rather long, subscription by type erasing the returned publisher.
Append one last operator:

.eraseToAnyPublisher()

At this point, you can find the following temporary return statement, and remove it:

return Empty().eraseToAnyPublisher()

Your playground should now finally compile with no errors. However, it still shows
the test data from the previous chapter section. Find and comment out:

api.mergedStories(ids: [1000, 1001, 1002])

.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

raywenderlich.com 258
Combine Chapter 14: In Practice: Project "News"

In its place, insert:

api.stories()
.sink(receiveCompletion: { print($0) },
receiveValue: { print($0) })
.store(in: &subscriptions)

This code subscribes to api.stories() and prints any returned output and
completion events.

Once you let the playground run one more time, you should see a dump of the latest
Hacker News stories in the console. The list is dumped iteratively. Initially, you will
see the story fetched first on its own:

[
More than 70% of America’s packaged food supply is ultra-
processed
by xbeta
https://news.northwestern.edu/stories/2019/07/us-packaged-food-
supply-is-ultra-processed/
-----]

Then, the same one accompanied by a second story:

[
More than 70% of America’s packaged food supply is ultra-
processed
by xbeta
https://news.northwestern.edu/stories/2019/07/us-packaged-food-
supply-is-ultra-processed/
-----,
New AI project expects to map all the word’s reefs by end of
next year
by Biba89
https://www.independent.co.uk/news/science/coral-bleaching-ai-
reef-paul-allen-climate-a9022876.html
-----]

Then, a list of the same stories plus a third one and so on:

[
More than 70% of America’s packaged food supply is ultra-
processed
by xbeta
https://news.northwestern.edu/stories/2019/07/us-packaged-food-
supply-is-ultra-processed/
-----,
New AI project expects to map all the word’s reefs by end of
next year

raywenderlich.com 259
Combine Chapter 14: In Practice: Project "News"

by Biba89
https://www.independent.co.uk/news/science/coral-bleaching-ai-
reef-paul-allen-climate-a9022876.html
-----,
People forged judges’ signatures to trick Google into changing
results
by lnguyen
https://arstechnica.com/tech-policy/2019/07/people-forged-
judges-signatures-to-trick-google-into-changing-results/
-----]

Please note, since you‘re fetching live data from the Hacker News website the stories,
what you see in your console will be different as more and more stories are added
every few minutes.

To see that you are indeed fetching live data, wait a few minutes and re-run the
playground. You should see some new stories show up alongside the ones you
already saw.

Nice effort working through this somewhat longer section of the chapter! You‘ve
completed the development of the Hacker News API client and are ready to move on
to the next chapter. There, you will use SwiftUI to build a proper Hacker News reader
app.

Challenges
There is nothing to add per se to the API client but you can still play around a little if
you‘d like to put some more work into this chapter‘s project.

Challenge 1: Integrating the API client with

UIKit
As already mentioned, in the next chapter, you will learn about SwiftUI and how to
integrate it with your Combine code.

In this challenge, try to build an iOS app that uses your completed API client to
display the latest stories in a table view. You can develop as many details as you want
and add some styling or fun features but the main point to exercise in this challenge
is subscribing the API.stories() and binding the result to a table view — much like
the bindings you worked on in Chapter 8, “In Practice: Project ‘Collage’.”

raywenderlich.com 260
Combine Chapter 14: In Practice: Project "News"

If you successfully work through the challenge as described, you should see the latest
stories “pour in” when you launch the app in the simulator, or on your device:

Key points
• Foundation includes several publishers that mirror counterpart methods in the
Swift standard library and you can even use them interchangeably as you did with
reduce in this chapter.

• Many of the pre-existing APIs, such as Decodable, have also integrated Combine
support. This lets you use one standard approach across all of your code.

• By composing a chain of Combine operators, you can perform fairly complex

operations in a streamlined and easy-to-follow way — especially compared to pre-
Combine APIs!

raywenderlich.com 261
Combine Chapter 14: In Practice: Project "News"

Where to go from here?

Congratulations on completing the “Combine in Action” section! What a ride this
was, wasn‘t it?

You‘ve learned most of what Combine‘s foundations has to offer, so it‘s now times to
pull out the big guns in an entire section dedicated to advanced topics in the
Combine framework, starting with building an app that uses both SwiftUI and
Combine.

raywenderlich.com 262
Section IV: Advanced
Combine

With a huge portion of Combine foundations already in your tool belt, it's time to
learn some of the more advanced concepts and topics Combine has to offer on your
way to true mastery.

You'll start by learning how to use SwiftUI with Combine to build truly reactive and
fluent UI experiences and switch to learn how to properly handle errors in your
Combine apps. You'll then learn about schedulers, the core concept behind
scheduling work in different execution contexts and follow up with how you can
create your own custom publishers and handling the demand of subscribers by
understanding backpressure.

Finally, having a slick code base is great, but it doesn't help much if it's not well
tested, so you'll wrap up this section by learning how to properly test your new
Combine code.

Specifically, you'll cover:

Chapter 15: In Practice: SwiftUI & Combine: SwiftUI is the new user interface
paradigm from Apple and it's designed for an interplay with Combine on a whole new
level. In this chapter you are going to work through a Combine based SwiftUI project.

Chapter 16: Error Handling: This chapter will teach about Combine's powerful
typed error system, and how you can leverage it to handle errors in your app, and
within Combine publishers.

Chapter 17: Schedulers: In this chapter you’ll learn what Schedulers are, how they
relate to RunLoops, Dispatch queues and Threads and how Combine extends
Foundation to integrate with them.

Chapter 18: Custom Publishers & Handling Backpressure: Creating your own
publishers and operators is an advanced topic you’ll learn to master in this chapter,
while also learning about and experimenting with backpressure management.

Chapter 19: Testing: This chapter will introduce you to unit testing techniques for
use with Combine code. You’ll go from testing basics in a playground to applying

raywenderlich.com 263
Combine Section IV: Advanced Combine

what you’ve learned in adding tests to an existing iOS app project.

raywenderlich.com 264
15 Chapter 15: In Practice:
Combine & SwiftUI
By Marin Todorov

SwiftUI is Apple's new paradigm for building app UIs declaratively. It's a big
departure from the existing UIKit and AppKit frameworks. It offers a very lean and
easy to read and write syntax for building user interfaces.

Declarative syntax
The SwiftUI syntax clearly represents the view hierarchy you'd like to build:

HStack(spacing: 10) {
Text("My photo")
Image("myphoto.png")
.padding(20)
.resizable()
}

You can easily visually parse the hierarchy. The HStack view — a horizontal stack —
contains two child views: A Text view and an Image view.

Each of the views might have a number of parameters. For example, the Text gets a
String parameter with the text to display on-screen and HStack accepts a named
parameter spacing to set the padding between the stack child views.

Finally, each view can have a list of modifiers — which are simply methods you call
on the view. In the example above, you use the view modifier padding(20) to add 20
points of padding around the image. Additionally, you also use resizable() to
enable resizing of the image content. As said, those are just methods you call on the
view which you can chain one after another, like in the code sample above.

raywenderlich.com 265
Combine Chapter 15: In Practice: Combine & SwiftUI

Cross-platform
Not only does SwiftUI offer a new way to build UIs but it also unifies the approach to
building cross-platform UIs. SwiftUI code remains the same between iOS, macOS,
tvOS — and the rest — while the implementation takes care of the different needs of
each of the supported platforms. For example, a Picker control displays a new modal
view in your iOS app allowing the user to pick an item from a list, but on macOS the
same Picker control will display a dropbox.

A quick code example of a data form could be something like this:

VStack {
TextField("Name", text: $name)
TextField("Proffesion", text: $profession)
Picker("Type", selection: $type) {
Text("Freelance")
Text("Hourly")
Text("Employee")
}
}

This code will create two separate views on iOS. The Type picker control will be a
button taking the user to a separate screen with a list of options like so:

raywenderlich.com 266
Combine Chapter 15: In Practice: Combine & SwiftUI

On macOS, however, SwiftUI will consider the abundant UI screen space on the mac
and create a single form with a drop-down menu instead:

New memory model

When using UIKit and AppKit, you need to constantly micromanage your data model
and your views to keep them in sync. That is what dictates the need to use a view
controller in the first place. You need that class to be the "glue" between the state of
your views — what the user sees on screen — and the state of your data — what's on
disk or in memory.

When using SwiftUI, on the other hand, you need to adopt a new approach towards
building user interfaces. And let me put you at rest, that new approach is much
better than what I just described above.

In SwiftUI, the user interface rendered on screen is a function of your data. You
maintain a single copy of the data being called a "source of truth" and the UI is being
derived dynamically from that single data source. This way, your UI is always up-to-
date with the state of your app. Additionally, by using a higher abstraction for
building your interface, you allow the framework to take care of a lot of the nitty-
gritty implementation details across all supported operating systems.

Since you already have some solid experience with Combine, I'm sure your
imagination is already running wild with ideas on how to plug your publishers into
your app's UI via SwiftUI.

raywenderlich.com 267
Combine Chapter 15: In Practice: Combine & SwiftUI

Hello, SwiftUI!
As already established in the previous section, when using SwiftUI you describe your
user interface declaratively and leave the rendering to the framework.

Each of the views you declare for your UI — text labels, images, shapes, etc. —
conform to the View protocol. The only requirement of View is a property called
body.

Any time you change your data model, SwiftUI asks each of your views for their
current body representation. This might be changing according to your latest data
model changes. Then, the framework builds the view hierarchy to render on-screen
by calculating only the views affected by changes in your model, resulting in a highly
optimized and effective drawing mechanism.

In effect, SwiftUI makes UI "snapshots" triggered by any changes of your data model
like so:

With this new way to manage your UI, you need to stop thinking of how to update
the user interface. Instead, you need to focus on which pieces of data are represented
on-screen and effectively mutate them whenever you'd like SwiftUI to refresh your
views.

In this chapter, you will work through a number of tasks that cover both
interoperations between Combine and SwiftUI along with some of the SwiftUI basics.

raywenderlich.com 268
Combine Chapter 15: In Practice: Combine & SwiftUI

Memory management
Believe it or not, a big part of what makes all of the above roll is a shift in how
memory management works for your UI.

SwiftUI introduces a new concept with the help of some cool new syntax which
allows you to, instead of duplicating your state in both your data model and your UI,
make your UI a function of your model's state. This allows you to keep your data in
a single place called "source of truth."

No data duplication
Let's look at an example of what that means. When working with UIKit/AppKit you'd,
in broad strokes, have your code separated between a data model, some kind of
controller and a view:

Those three types can have several similar features. They include data storage, they
can be mutated, they can be reference types and more.

Let's say you want to display the current weather on-screen. For the purpose of this
example, let's say the model type is a struct called Weather and the current
conditions are stored in a text property called conditions. To display that
information to the user, you need to create an instance of another type, namely
UILabel, and copy the value of conditions into the text property of the label.

raywenderlich.com 269
Combine Chapter 15: In Practice: Combine & SwiftUI

Now, you have two copies of the value you work with. One is located in your model
type and the other is stored in the UILabel, just for the purpose of displaying it on-
screen:

There is no connection or binding between text and conditions. You simply need
to copy the String value everywhere you need it.

Now you've added a dependency to your UI. The freshness of the information on-
screen depends on Weather.conditions. It's your responsibility to update the
label's text property manually with a new copy of Weather.conditions whenever
the conditions property changes.

SwiftUI removes the need for duplicating your data for the purpose of showing it on-
screen. Being able to offload data storage out of your UI allows you to effectively
manage the data in a single place in your model and never have your app's users see
stale information on-screen.

Less need to "control" your views

As an additional bonus, removing the need for having "glue" code between your
model and your view allows you to get rid of most of your view controller code as
well!

In this chapter, you are will learn:

• Briefly about the basics of SwiftUI syntax for building declarative UIs.

• How to declare various types of UI inputs and connect them to their "sources of
truth."

• How to use Combine to build data models and pipe the data into SwiftUI.

raywenderlich.com 270
Combine Chapter 15: In Practice: Combine & SwiftUI

Experience with SwiftUI

Unfortunately, we can't cover SwiftUI in detail in this chapter. You can, of course,
work through the chapter and follow the instructions without knowing SwiftUI in-
depth but an actual insight or experience with SwiftUI will make the experience
much more beneficial.

That being said, if what you build in this chapter seems exciting and you'd like to
learn more about SwiftUI, consider SwiftUI by Tutorials (https://bit.ly/2L5wLLi) to
get an in-depth tour.

Additionally, iOS Animations by Tutorials (https://bit.ly/2MaW6UB) features two

full-length chapters focusing on creating animations with SwiftUI.

And now, for our feature presentation: Combine with SwiftUI!

Getting started with "News"

The starter project for this chapter includes some code so that you can focus on
Combine and SwiftUI. That said, the actual UI layout has already been, well, laid out.
The syntax layout itself is out of the scope of this chapter.

The project also includes some folders where you will find the following:

• App contains the app and scene delegates.

• Network includes the completed Hacker News API from last chapter.

• Model is where you will find simple model types like Story, FilterKeyword and
Settings. Additionally, this is where ReaderViewModel resides, which is the
model type that the main newsreader view uses.

• View contains the app views and, inside View/Helpers, you will find some simple
reusable components like buttons, badges, etc.

• Finally, in Util there is a helper type that allows you to easily read and write JSON
files to/from disk.

The completed project will display a list of Hacker News stories and allow the user to
manage a keyword filter:

raywenderlich.com 271
Combine Chapter 15: In Practice: Combine & SwiftUI

A first taste of managing view state

Build and run the starter project and you will see an empty table on screen and a
single bar button titled "Settings":

This is where you start. To get a taste of how interacting with the UI via changes to
your data works, you'll make the Settings button present SettingsView when
tapped.

Open View/ReaderView.swift which contains the ReaderView view displaying the

main app interface. Driving the UI via data changes means that you will not be
calling any methods directly or setting any data on UI controls.

raywenderlich.com 272
Combine Chapter 15: In Practice: Combine & SwiftUI

The type already includes a property called presentingSettingsSheet which is a

simple Boolean value. Changing this value will either present or dismiss the settings
view. Scroll down through the source code and find the comment // Set
presentingSettingsSheet to true here.

This comment is located in the Settings button callback so that's the perfect place to
present the Settings view. Replace the comment with:

self.presentingSettingsSheet = true

As soon as you add this line, you will see the following error:

And indeed self is immutable because the view's body is a dynamic property and,
therefore, cannot mutate ReaderView.

Let's talk quickly one more time about memory management. SwiftUI offers a
number of built-in property wrappers to help you indicate that given properties are
part of your state and any changes to those properties should trigger a new UI
"snapshot."

Let's see what that means in practice. Adjust the plain old
presentingSettingsSheet property so it looks as follows:

@State var presentingSettingsSheet = false

The @State property wrapper:

1. Moves the property storage out of the view, so modifying

presentingSettingsSheet does not mutate self.

2. Marks the property as local storage. In other words, it denotes the piece of data
is owned by the view.

3. Adds a publisher, somewhat like @Published does, to ReaderView called

$presentingSettingsSheet which you can use to subscribe to the property or
to bind it to UI controls or other views.

Once you add @State to presentingSettingsSheet, the error will clear as the
compiler knows that you can modify this particular property from a non-mutating
context.

raywenderlich.com 273
Combine Chapter 15: In Practice: Combine & SwiftUI

Finally, to make use of presentingSettingsSheet, you need to declare how the new
state affects the UI. In this case, you will add a sheet(...) view modifier to the view
hierarchy and bind $presentingSettingsSheet to the sheet. Whenever you change
presentingSettingsSheet, SwiftUI will take the current value and either present or
dismiss your view, based on the boolean value.

Find the comment // Present the Settings sheet here and replace it with:

.sheet(isPresented: self.$presentingSettingsSheet, content: {

SettingsView()
})

The sheet(isPresented:content:) modifier takes a Bool publisher and a view to

render whenever the presentation publisher emits true.

Build and run the project. Tap Settings and your new presentation will display the
target view:

Note how you can see the ReaderView's top edge below SettingsView as the
sheet(...) modifier uses the new sheet presentation style in iOS 13.

If you set presentingSettingsSheet to false, that will dismiss SettingsView. But,

for now, let's leave the code as it is. Currently, your app benefits from the default
swipe-down gesture which dismisses presented views automatically.

raywenderlich.com 274
Combine Chapter 15: In Practice: Combine & SwiftUI

Fetching the latest stories

Next, time for you to go back to some Combine code. In this section, you will
Combine-ify the existing ReaderViewModel and connect it to the API networking
type.

Open Model/ReaderViewModel.swift. At the top, insert:

import Combine

This code, naturally, will allow you to use Combine types in

ReaderViewModel.swift. Now, add a new subscriptions property to
ReaderViewModel to store all of your subscriptions:

private var subscriptions = Set<AnyCancellable>()

With all that solid prep work, now it's time to create a new method and engage the
network API. Add the following empty method to ReaderViewModel:

func fetchStories() {

In this method, you will subscribe to API.stories() and store the server response
in the model type. You should be familiar with this method from the previous
chapter.

Add the following inside fetchStories():

api
.stories()
.receive(on: DispatchQueue.main)

You use the receive(on:) operator to receive any output on the main queue.
Arguably, you could leave the thread management to the consumer of the API.
However, since in ReaderViewModel's case that's certainly ReaderView, you optimize
right here and switch to the main queue to prepare for committing changes to the UI.

Next, you will use a sink(...) subscriber to store the stories and any emitted errors
in the model. Append:

.sink(receiveCompletion: { completion in
if case .failure(let error) = completion {
self.error = error
}

raywenderlich.com 275
Combine Chapter 15: In Practice: Combine & SwiftUI

}, receiveValue: { stories in
self.allStories = stories
self.error = nil
})
.store(in: &subscriptions)

First, you check if the completion was a failure. If so, you store the associated error
in self.error. In case you receive values from the stories publisher, you store them
in self.allStories.

This is all the logic you're going to add to the model in this section. The
fetchStories() method is now complete and you can "start-up" your model as soon
as you display ReaderView on screen.

To do that, open App/SceneDelegate.swift and find the place in the code where you
set ReaderView as the main view of the app's window. The code you're looking for is
wrapped in an if, like so:

if let windowScene = scene as? UIWindowScene {

...
}

Inside the if body, at its very end, add the following code:

viewModel.fetchStories()

Right now, ReaderViewModel is not really hooked up to ReaderView so you will not
see any change on-screen. However, to quickly verify that everything works as
expected, do the following: Go back to Model/ReaderViewModel.swift and add a
didSet handler to the allStories property:

private var allStories = [Story]() {

didSet {
print(allStories.count)
}
}

Run the app and observe the Console. You should see a reassuring output like so:

1
2
3
4
...

You can remove the didSet handler you just added in case you don't want to see that
output every time you run the app.

raywenderlich.com 276
Combine Chapter 15: In Practice: Combine & SwiftUI

Using ObservableObject for model types

Speaking of hooking up the model to the ReaderView, you will do exactly that in this
section. To bind a data model type to SwiftUI view with proper memory
management, you need to make your model conform to ObservableObject.

The ObservableObject requires that types conform to a single requirement. They

must have a publisher called objectWillChange which emits any time the type's
state is about to change.

As a huge bonus, ObservableObject provides a default implementation of

objectWillChange. So, for simple use cases, you don't even need to adjust your
existing model code. When you add ObservableObject conformance to your type,
the default protocol implementation will automatically emit any time any of your
@Published properties emit!

That sounds easy enough, and for once, it really is!

First, import SwiftUI at the top of ReaderViewModel.swift:

import SwiftUI

Then, to add ObservableObject conformance to ReaderViewModel, alter the class

definition like so:

class ReaderViewModel: ObservableObject {

If you were to implement some more esoteric behavior for your model, you could add
your own objectWillChange declaration. For this chapter, though, you'll go with the
default.

Next, you need to consider which properties of the data model constitute its state.
The two properties you currently update in your sink(...) subscriber are
allStories and error. You will consider those state-change worthy.

Note: There is also a third property called filter. Ignore it for the moment
and you'll come back to it later on.

Adjust allStories to include the @Published property wrapper like so:

@Published private var allStories = [Story]()

raywenderlich.com 277
Combine Chapter 15: In Practice: Combine & SwiftUI

Then, do the same for error:

@Published var error: API.Error? = nil

Take a moment to enjoy the simplicity of ObservableObject. It's a generic, all-

purpose protocol which — without making any assumptions about how your own
data code works — adds the ability to detect changes in any of your types. It doesn't
get any easier than this!

The final step in this section is, since ReaderViewModel now conforms to
ObservableObject, to actually bind the data model to ReaderView.

Open View/ReaderView.swift and add the @ObservedObject property wrapper to

the line var model: ReaderViewModel like so:

@ObservedObject var model: ReaderViewModel

You don't inject the model when initializing the view anymore. Instead, you bind the
model so that, any time its state changes, your view will receive the latest data and
generate its new UI "snapshot".

The @ObservedObject wrapper does the following:

1. Removes the property storage from the view and uses a binding to the original
model instead. In other words, it doesn't duplicate the data.

2. Marks the property as external storage. In other words, it denotes that the piece
of data is not owned by the view.

3. Like @Published and @State, it adds a publisher to the property so you could
subscribe to it and/or bind to it further down the view hierarchy.

raywenderlich.com 278
Combine Chapter 15: In Practice: Combine & SwiftUI

By adding @ObservedObject, you've made model dynamic. This means it'll get all
updates while your view model fetches stories from the Hacker News server. In fact,
run the app right now and you will see the view refresh as stories are fetched by the
view model:

Neat! As promissed, for once, things not only look simple but they actually are.

Displaying errors
You will also display errors in the same way you display the fetched stories. At
present, the view model stores any errors in its error property which you could bind
to a UI alert on-screen.

Open View/ReaderView.swift and find the comment // Display errors here.

Replace this comment with the following code to bind the model to an alert view:

.alert(item: self.$model.error) { error in

Alert(
title: Text("Network error"),
message: Text(error.localizedDescription),
dismissButton: .cancel()
)
}

raywenderlich.com 279
Combine Chapter 15: In Practice: Combine & SwiftUI

The alert(item:) modifier controls an alert presentation on-screen. It takes a

publisher with an optional output called the item. Whenever that publisher emits a
non-nil value, it presents the alert view.

The model's error property is nil by default and will only be set to a non-nil error
value whenever the model experiences an error fetching stories from the server. This
is an ideal scenario for presenting an alert as it allows you to bind error directly as
alert(item:) input.

To test this, open Network/API.swift and modify the baseURL property to an invalid
URL, for example, https://123hacker-news.firebaseio.com/v0/.

Run the app again and you will see the error alert show up as soon as the request to
the stories endpoint fails:

Before moving on and working through the next section, take a moment to revert
your changes to baseURL so your app once again connects to the server successfully.

Subscribing to an external publisher

Sometimes you don't want to go down the ObservableObject/ObservedObject
route, because all you want to do is subscribe to a single publisher and receive its
values in your SwiftUI view. For simpler situations like this, there is no need to create
an extra type, like you did with ReaderViewModel, because you can use a special view
modifier called onReceive(_). This allows you to subscribe to a publisher directly in
your view code.

You can either inject the external publisher in your view by passing it to its initializer
or create the publisher inside your view. Either way, you are free to decide what you'd
like to do when receiving a new output value. You might ignore it, process it
somehow and/or change the state of the view and trigger a new UI "snapshot."

raywenderlich.com 280
Combine Chapter 15: In Practice: Combine & SwiftUI

If you run the app right now, you will see that each of the stories has a relative time
included alongside the name of the story author:

The relative time there is useful to instantly communicate the "freshness" of the
story to the user. However, once rendered on-screen, the information becomes stale
after a while. If the user has the app open for a long time, "1 minute ago" might be off
by quite some time.

In this section, you will use a timer publisher to trigger UI updates at regular
intervals so each row could recalculate and display correct times.

How the code works right now is as follows:

• ReaderView has a property called currentDate which is set once with the current
date when the view is created.

• Each row in the stories list includes a PostedBy(time:user:currentDate:) view

which compiles the author and time information by using currentDate's value.

To make the information on-screen "refresh" periodically, you will add a new timer
publisher. Every time it emits, you will update currentDate. Additionally, as you
might've guessed already, you will add currentDate to the view's state so it will
trigger a new UI "snapshot" as it changes.

Sounds like a walk in the park, doesn't it?

To work with publishers, start by adding towards the top of ReaderView.swift:

import Combine

raywenderlich.com 281
Combine Chapter 15: In Practice: Combine & SwiftUI

Then, add a new publisher property to ReaderView which creates a new timer
publisher ready to go as soon as anyone subscribes to it:

private let timer = Timer.publish(every: 10, on: .main,

in: .common)
.autoconnect()
.eraseToAnyPublisher()

As you already learned earlier in the book, Timer.publish(every:on:in:) returns a

connectable publisher. This is a kind of "dormant" publisher that specifically requires
subscribers to connect to it to activate it. In your case, however, you will subscribe to
the timer as soon as the view generates its first "snapshot" so you don't need any
complex connectable logic. You use autoconnect() to instruct the publisher to
automatically "awake" upon it being subscribed for the first time.

What's left now is to update currentDate each time the timer emits. You will use a
SwiftUI modifier called onReceive(_), which behaves much like the
sink(receiveValue:) subscriber. Scroll just a tad down and find the comment //
Add timer here and replace it with:

.onReceive(timer) {
self.currentDate = $0
}

The timer emits the current date and time so you just take that value and assign it to
currentDate. Doing that will produce an already familiar error:

Naturally, this happens because you cannot mutate the property from a non-
mutating context. Just as before, you'll solve this predicament by adding
currentDate to the view's local storage state.

Add a @State property wrapper to the property like so:

@State var currentDate = Date()

This way, any update to currentDate will trigger a new UI "snapshot" and will force
each row to recalculate the relative time of the story and update the text if necessary.

raywenderlich.com 282
Combine Chapter 15: In Practice: Combine & SwiftUI

Run the app one more time and leave it open in the Simulator or your device. Make a
mental note of how long ago the top story was posted, here's what I had when I tried
that:

Wait for at least one minute and you will see the visible rows update their
information with the current time. The orange time badge will still show the time
when the story was posted but the text below the title will update with the correct "...
minutes ago" text:

Besides having the publisher a property on your view, you can also inject any
publisher from your Combine model code into the view via the view's initializer or
the environment. Then, it's only a matter of using onReceive(...) in the same way
as above.

Initializing the app's settings

In this part of the chapter, you will move on to making the Settings view work.
Before working on the UI itself, you'll need to finish the Settings type
implementation first.

Open Model/Settings.swift and you'll see that, currently, the type is pretty much
bare bones. It contains a single property holding a list of FilterKeyword values.

raywenderlich.com 283
Combine Chapter 15: In Practice: Combine & SwiftUI

Now, open Model/FilterKeyword.swift. FilterKeyword is a helper model type that

wraps a single keyword to be used as a filter for the stories list in the main reader
view. It conforms to Identifiable, which requires an id property that can be used
to uniquely identify each instance, such as when you use those types in your SwiftUI
code. If you peruse the API.Error and Story definitions in Network/API.swift and
Model/Story.swift, respectively, you'll see that these types also conform to
Identifiable.

Let's go on the merry-go-round one more time. You need to turn the plain, old model
Settings into a modern type that can be used with your Combine and SwiftUI code.

Get started by adding at the top of Model/Settings.swift:

import Combine

Then, add a publisher to keywords by adding the @Published property wrapper to it,
so it looks as follow:

@Published var keywords = [FilterKeyword]()

Now, other types can subscribe to a Settings object's current keywords. You can also
pipe in the keywords list to views that accept a binding.

Finally, to allow Settings to be observed by views or injected into the SwiftUI

environment, make the type conform to ObservableObject like so:

final class Settings: ObservableObject {

There's no need to add anything else to make the ObservableObject conformance

work. The default implementation will emit any time the $keywords publisher does.

This is how, in a few easy steps, you turned Settings into a model type on steroids.
Now, you can plug it into the rest of your reactive code in the app.

To bind the app's Settings, you'll instantiate it in your scene delegate and bind it to
ReaderViewModel. Open App/SceneDelegate.swift and add alongside the existing
import statements:

import Combine

Next, at the top of scene(_:willConnectTo:options:), insert:

let userSettings = Settings()

raywenderlich.com 284
Combine Chapter 15: In Practice: Combine & SwiftUI

As usual, you will also need a cancelable collection to store your subscriptions. Add a
property for that to SceneDelegate, right below the window property:

private var subscriptions = Set<AnyCancellable>()

Now, you can bind Settings.keywords to ReaderViewModel.filter so that the

main view will not only receive the initial list of keywords but also the update list
each time the user edits the list of keywords.

Still in scene(_:willConnectTo:options:), insert after the line let viewModel =

ReaderViewModel():

userSettings.$keywords
.map { $0.map { $0.value } }
.assign(to: \.filter, on: viewModel)
.store(in: &subscriptions)

You subscribe to userSettings.$keywords, which outputs [FilterKeyword], and

map it to [String] by getting each keyword's value property. Then, you assign the
resulting value to viewModel.filter.

Now, whenever you alter the contents of Settings.keywords, the binding to the
view model will ultimately cause the generation of a new UI "snapshot" of
ReaderView because the view model is part of its state.

The binding so far works. However, you still have to add the filter property to be
part of ReaderViewModel's state. You'll do this so that, each time you update the list
of keywords, the new data will be relayed onwards to the view.

To do that, open Model/ReaderViewModel.swift and add the @Published property

wrapper to filter like so:

@Published var filter = [String]()

The complete binding from Settings to the view model and onwards to the view is
now complete!

raywenderlich.com 285
Combine Chapter 15: In Practice: Combine & SwiftUI

This is extremely handy because, in the next section, you will connect the Settings
view to the Settings model and any change the user makes to the keyword list will
trigger the whole chain of bindings and subscriptions to ultimately refresh the main
app view story list like so:

Editing the keywords list

In this last part of the chapter, you will look into the SwiftUI environment. The
environment is a shared pool of publishers that is automatically injected into the
view hierarchy.

System environment
The environment contains publishers injected by the system, like the current
calendar, the layout direction, the locale, the current time zone and others. As you
see, those are all values that could change over time. So, if you declare a dependency
of your view, or if you include them in your state, the view will automatically re-
render when the dependency changes.

To try out observing one of the system settings, open View/ReaderView.swift and
add a new property to ReaderView:

@Environment(\.colorScheme) var colorScheme: ColorScheme

You use the @Environment property wrapper, which defines which key of the
environment should be bound to the colorScheme property. Now, this property is
part of your view's state. Each time the system appearance mode changes between
light and dark, and vice-versa, SwiftUI will re-render your view.

Additionally, you will have access to the latest color scheme in the view's body. So,
you can render it differently in light and dark modes.

raywenderlich.com 286
Combine Chapter 15: In Practice: Combine & SwiftUI

Scroll down and find the line setting the color of the story link
.foregroundColor(Color.blue). Replace that line with:

.foregroundColor(self.colorScheme == .light ? .blue : .orange)

Now, depending on the current value of colorScheme, the link will be either blue or
orange.

Try out this new miracle of code by changing the system appearance to dark. In
Xcode, open Debug ▶ View Debugging ▶ Configure Environment Overrides... or
tap the Environment Overrides button at Xcode's bottom toolbar. Then, toggle the
switch next to Interface Style on.

raywenderlich.com 287
Combine Chapter 15: In Practice: Combine & SwiftUI

Feel free to stay in dark appearance mode. However, I'll switch back to light
appearance for the remainder of the chapter because it will print screenshots better
in the book.

Custom environment objects

As cool as observing the system settings via @Environment(_) is, that's not all that
the SwiftUI environment has to offer. You can, in fact, environment-ify your objects
as well!

This is very handy. Especially when you have deeply nested view hierarchies.
Inserting a model or another shared resource into the environment removes the need
to dependency-inject through a multitude of views until you reach the deeply nested
view that actually needs the data.

Objects you insert in a view's environment are made available automatically to any
child views of that view and all views being linked from that view as well.

This sounds like a great opportunity for sharing your user's Settings with all views
of the app so they can make use of the user's story filter.

The spot in your app where you create your main view is the scene delegate. This is
where you previously created the userSettings instance of Settings and bound its
$keywords to the ReaderViewModel. Now, you will inject userSettings into the
environment as well.

Open App/SceneDelegate.swift and attach the environmentObject modifier to the

creation of ReaderView by replacing the following line:

let rootView = ReaderView(model: viewModel)

With:

let rootView = ReaderView(model: viewModel)

.environmentObject(userSettings)

The environmentObject modifier is a view modifier which inserts the given object
in a view hierarchy's environment. Since you already have an instance of Settings,
you simply send that one off to the environment and you're done.

raywenderlich.com 288
Combine Chapter 15: In Practice: Combine & SwiftUI

Next, you need to add the environment dependency to the views where you want to
use your custom object. Open View/SettingsView.swift and add a new property with
the @EnvironmentObject wrapper:

@EnvironmentObject var settings: Settings

The settings property will automatically be populated with the latest user settings
from the environment.

For your own objects, you do not need to specify a key path like for the system
environment. @EnvironmentObject will match the property type — in this case
Settings — to the objects stored in the environment and find the right one.

Now, you can use settings.keywords like any of your other view states. You can
either get the value directly, subscribe to it, or bind it to other views.

To complete the SettingsView functionality, you'll display the list of keywords and
enable adding, editing and deleting keywords from the list.

Find the following line:

ForEach([FilterKeyword]()) { keyword in

And replace it with:

ForEach(settings.keywords) { keyword in

The updated code will use the filter keywords for the on-screen list. This will,
however, still display an empty list as the user doesn't have a way to add new
keywords.

The starter project includes a view for adding keywords. So, you simply need to
present it when the user taps the + button. The + button action is set to
addKeyword() in SettingsView.

Scroll to the private addKeyword() method and add inside it:

presentingAddKeywordSheet = true

presentingAddKeywordSheet is a published property, much like the one you already

worked with earlier this chapter, to present an alert. You can see the presentation
declaration slightly up in the source: .sheet(isPresented:
$presentingAddKeywordSheet).

raywenderlich.com 289
Combine Chapter 15: In Practice: Combine & SwiftUI

If you run the app right now and navigate to the Settings view, you will see the
following crash in the debugger:

This is because only views that are children to the view where you inserted the
environment object and linked views are receiving Settings automatically. Views
presented with a sheet(...) modifier do not get the environment objects.

This is, however, a neat opportunity to exercise binding objects onwards one more
time. What you'll do is inject the settings as an environment object manually in the
code.

Switch to View/ReaderView.swift and find the spot where you present

SettingsView — it's a single line where you just create a new instance like so:
SettingsView().

The same way you injected the settings into ReaderView, you can inject them here as
well. Add a new property to ReaderView:

@EnvironmentObject var settings: Settings

And then, add the .environmentObject modifier directly under SettingsView():

.environmentObject(self.settings)

Now, you declared a ReaderView dependency on Settings and you passed that
dependency onwards to SettingsView via the environment. In this particular case,
you could've just passed it as a parameter to the init of SettingsView as well.

Before moving on, run the app one more time. You should be able to tap Settings
and see the SettingsView pop up. This means the user settings were correctly
passed down to the presented view via the environment and the runtime is not
complaining anymore.

Now, switch back to View/SettingsView.swift and complete the list editing actions
as initially intended.

Inside sheet(isPresented: $presentingAddKeywordSheet), a new

AddKeywordView is already created for you. It's a custom view included with the
starter project, which allows the user to enter a new keyword and tap a button to add
it to the list.

raywenderlich.com 290
Combine Chapter 15: In Practice: Combine & SwiftUI

AddKeywordView takes a callback, which it will call when the user taps the button to
add the new keyword. In the empty completion callback of AddKeywordView add:

let new = FilterKeyword(value: newKeyword.lowercased())

self.settings.keywords.append(new)
self.presentingAddKeywordSheet = false

You create a new keyword, add it to user settings, and finally dismiss the presented
sheet.

Remember, adding the keyword to the list here will update the settings model object
and in turn, will update the reader view model and refresh RenderView as well. All
automatically as declared in your code.

To wrap up with SettingsView, let's add deleting and moving keywords. Find //
List editing actions and replace it with:

.onMove(perform: moveKeyword)
.onDelete(perform: deleteKeyword)

This code sets moveKeyword() as the handler when the user moves one of the
keywords up or down the list and deleteKeyword() as the handler when the user
swipes right to delete a keyword.

In the currently empty moveKeyword(from:to:) method, add:

guard let source = source.first,

destination != settings.keywords.endIndex else { return }

settings.keywords
.swapAt(source,
source > destination ? destination : destination - 1)

And inside deleteKeyword(at:), add:

settings.keywords.remove(at: index.first!)

raywenderlich.com 291
Combine Chapter 15: In Practice: Combine & SwiftUI

That's really all you need to enable editing in your list! Build and run the app one
final time and you'll be able to fully manage the story filter including adding, moving
and deleting keywords:

Note: At the time of this writing, editing mode is a little clunky. You may have
to tap Edit, partially swipe to delete a row and then tap Edit again to be able
to re-order items.

Additionally, when you navigate back to the story list, you will see that the settings
have been propagated along with your subscriptions and bindings across the
application and the list displays only stories matching your filter. The title will
display the number of matching stories as well:

raywenderlich.com 292
Combine Chapter 15: In Practice: Combine & SwiftUI

Challenges
This chapter includes two completely optional SwiftUI exercises that you can choose
to work through. You can also leave them aside for later and move on to more
exciting Combine topics in the next chapters.

Challenge 1: Displaying the filter in the reader

view
In the first challenge, you will insert a list of the filter's keywords in the story list
header in ReaderView. Currently, the header always displays "Showing all stories".
Change that text to display the list of keywords in case the user has added any, like
so:

Challenge 2: Persisting the filter between app

launches
The starter project includes a helper type called JSONFile which offers two methods:
loadValue(named:) and save(value:named:).

Use this type to:

• Save the list of keywords on disk any time the user modifies the filter by adding a
didSet handler to Settings.keywords.

• Load the keywords from disk in Settings.init().

This way, the user's filter will persist between app launches like in real apps.

If you're not sure about the solution to either of these challenges, or need some help,
feel free to look into the finished project in the projects/challenge folder.

raywenderlich.com 293
Combine Chapter 15: In Practice: Combine & SwiftUI

Key points
With SwiftUI, your UI is a function of your state. You cause your UI to render itself
by committing changes to the data declared as the view's state, among other view
dependencies. You learned various ways to manage state in SwiftUI:

• Use @State to add local state to a view and @ObservedObject to add a dependency
on an external ObservableObject in your Combine code.

• Use onReceive view modifier to subscribe an external publisher directly.

• Use @Environment to add a dependency to one of the system-provided

environment settings and @EnvironmentObject for your own custom environment
objects.

Where to go from here?

Congratulations on getting down and dirty with SwiftUI and Combine! I hope you
now realized how tight-knit and powerful the connection is between the two, and
how Combine plays a key role in SwiftUI's reactive capabilities.

Even though you should always aim to write error-free apps, the world is rarely this
perfect. Which is exactly why you'll spend the next chapter learning about how you
can handle errors in Combine.

raywenderlich.com 294
16 Chapter 16: Error
Handling
By Shai Mishali

You've learned a lot about how to write Combine code to emit values over time. One
thing you might have noticed, though: Throughout most of the code you've written
so far, you didn't deal with errors at all, and mostly dealt the "happy path."

Unless you write error-free apps, this chapter is for you! :]

As you learned in Chapter 1, “Hello, Combine!,” a Combine publisher declares two

generic constraints: Output, which defines the type of values the publisher emits,
and Failure, which defines what kind of failure this publisher can finish with.

Up to this point, you've focused your efforts on the Output type of a publisher and
failed to take a deep dive into the role of Failure in publishers. Well, don't worry,
this chapter will change that!

raywenderlich.com 295
Combine Chapter 16: Error Handling

Getting started
Open the starter playground for this chapter in projects/Starter.playground. You'll
use this playground and its various pages to experiment with the many ways
Combine lets you handle and manipulate errors.

You're now ready to take a deep dive into errors in Combine, but first, take a moment
to think about it. Errors are such a broad topic, where would you even start?

Well, how about starting with the absence of errors?

Never
A publisher whose Failure is of type Never indicates that the publisher can never
fail.

While this might seem a tad strange at first, it provides some extremely powerful
guarantees about these publishers. A publisher with Never failure type lets you focus
on consuming the publisher's values, while being absolutely sure the publisher will
never fail. It can only complete successfully once it's done.

raywenderlich.com 296
Combine Chapter 16: Error Handling

Open the Project Navigator in the starter playground by pressing Command-1,

then select the Never playground page.

Add the following example to it:

example(of: "Never sink") {

Just("Hello")
}

You create a Just with a string value of Hello. Just always declares a Failure of
Never. To confirm this, Command-click the Just initializer and select Jump to
Definition:

Looking at the definition, you can see a type alias for Just's failure:

public typealias Failure = Never

Combine's no-failure guarantee for Never isn't just theoretical, but is deeply rooted
in the framework and its various APIs.

Combine offers several operators that are only available when the publisher is
guaranteed to never fail. The first one is a variation of sink to handle only values.

Go back to the Never playground page and update the above example so it looks like
this:

example(of: "Never sink") {

Just("Hello")
.sink(receiveValue: { print($0) })
.store(in: &subscriptions)
}

Run your playground and you'll see the Just's value printed out:

——— Example of: Never sink ———

Hello

raywenderlich.com 297
Combine Chapter 16: Error Handling

In the above example, you use sink(receiveValue:). This specific overload of sink
lets you ignore the publisher's completion event and only deal with its emitted
values.

This overload is only available for infallible publishers. Combine is smart and safe
when it comes to error handling, and forces you to deal with a completion event if an
error may be thrown — i.e., for a non-failing publisher.

To see this in action, you'll want to turn your Never-failing publisher into one that
may fail. There are a few ways to do this, and you'll start with the most popular one
— the setFailureType operator.

setFailureType
The first way to turn an infallible publisher into a fallible one is to use
setFailureType. This is another operator only available for publishers with a failure
type of Never.

Add the following code and example to your playground page:

enum MyError: Error {

case ohNo
}

example(of: "setFailureType") {
Just("Hello")
}

You start by defining a MyError error type outside the scope of the example. You'll
reuse this error type in a bit. You then start the example by creating a Just similar to
the one you used before.

Now, you can use setFailureType to change the failure type of the publisher to
MyError. Add the following line immediately after the Just:

.setFailureType(to: MyError.self)

To confirm this actually changed the publisher's failure type, start

typing .eraseToAnyPublisher(), and the auto-completion will show you the erased
publisher type:

raywenderlich.com 298
Combine Chapter 16: Error Handling

Delete the .erase... line you started typing before proceeding.

Now it's time to use sink to consume the publisher. Add the following code
immediately after your last call to setFailureType:

// 1
.sink(
receiveCompletion: { completion in
switch completion {
// 2
case .failure(.ohNo):
print("Finished with Oh No!")
case .finished:
print("Finished successfully!")
}
},
receiveValue: { value in
print("Got value: \(value)")
}
)
.store(in: &subscriptions)

You might have noticed two interesting facts about the above code:

1. It's using sink(receiveCompletion:receiveValue:). The

sink(receiveValue:) overload is no longer available since this publisher may
complete with a failure. Combine forces you to deal with the completion event for
such publishers.

2. The failure type is MyError, which lets you target the .failure(.ohNo) case to
deal with that specific error.

Run your playground, and you'll see the following output:

——— Example of: setFailureType ———

Got value: Hello
Finished successfully!

Of course, setFailureType's effect is only a type-system definition. Since the

original publisher is a Just, no error is actually thrown.

You'll learn more about how to actually produce errors from your own publishers
later in this chapter. But first, there are still a few more operators that are specific to
never-failing publishers.

raywenderlich.com 299
Combine Chapter 16: Error Handling

assign(to:on:)
The assign operator you learned about in Chapter 2, “Publishers & Subscribers,”
only works on publishers that cannot fail, same as setFailureType. If you think
about it, it makes total sense. Sending an error to a provided key path results in
either an unhandled error or an undefined behavior.

Add the following example to test this:

example(of: "assign") {
// 1
class Person {
let id = UUID()
var name = "Unknown"
}

// 2
let person = Person()
print("1", person.name)

Just("Shai")
.handleEvents( // 3
receiveCompletion: { _ in print("2", person.name) }
)
.assign(to: \.name, on: person) // 4
.store(in: &subscriptions)
}

In the above piece of code, you:

1. Define a Person class with id and name properties.

2. Create an instance of Person and immediately print its name.

3. Use handleEvents, which you learned about previously, to print the person's
name again once the publisher sends a completion event.

4. Finish up by using assign to set the person's name to whatever the publisher
emits.

Run your playground and look at the debug console:

——— Example of: assign ———

1 Unknown
2 Shai

raywenderlich.com 300
Combine Chapter 16: Error Handling

As expected, assign updates the person's name as soon as Just emits its value,
which works because Just cannot fail. In contrast, what do you think would happen
if the publisher had a non-Never failure type?

Add the following line immediately below Just("Shai"):

.setFailureType(to: Error.self)

In this code, you've set the failure type to a standard Swift error. This means that
instead of being a Publisher<String, Never>, it's now a Publisher<String,
Error>.

Try to run your playground. Combine is very verbose about the issue at hand:

referencing instance method 'assign(to:on:)' on 'Publisher'

requires the types 'Error' and 'Never' be equivalent

Remove the call to setFailureType you just added, and make sure your playground
runs with no compilation errors.

Before you start dealing with errors, there's one final operator related to infallible
publishers you should know: assertNoFailure.

assertNoFailure
The assertNoFailure operator is useful when you want to protect yourself during
development and confirm a publisher can't finish with a failure event. It doesn't
prevent a failure event from being emitted by the upstream. However, it will crash
with a fatalError if it detects an error, which gives you a good incentive to fix it in
development.

Add the following example to your playground:

example(of: "assertNoFailure") {
// 1
Just("Hello")
.setFailureType(to: MyError.self)
.assertNoFailure() // 2
.sink(receiveValue: { print("Got value: \($0) ")}) // 3
.store(in: &subscriptions)
}

raywenderlich.com 301
Combine Chapter 16: Error Handling

In the above code, you:

1. Use Just to create an infallible publisher and set its failure type to MyError.

2. Use assertNoFailure to crash with a fatalError if the publisher completes

with a failure event. This turns the publisher's failure type back to Never.

3. Print out any received values using sink. Notice that since assertNoFailure
sets the failure type back to Never, the sink(receiveValue:) overload is at your
disposal again.

Run your playground, and as expected it should work with no issues:

——— Example of: assertNoFailure ———

Got value: Hello

Now, after setFailureType, add the following line:

.tryMap { _ in throw MyError.ohNo }

You just used tryMap to throw an error once Hello is pushed downstream. You'll
learn more about try-prefixed operators later in this chapter.

Run your playground again and take a look at the console. You'll see output similar
to the following:

Playground execution failed:

error: Execution was interrupted, reason: EXC_BAD_INSTRUCTION

(code=EXC_I386_INVOP, subcode=0x0).

...

frame #0: 0x00007fff232fbbf2

Combine`Combine.Publishers.AssertNoFailure...

The playground crashes because a failure occurred in the publisher. In a way, you can
think of assertFailure() as a guarding mechanism for your code. While not
something you should use in production, it is extremely useful during development
to "crash early and crash hard."

Comment out the call to tryMap before moving on to the next section.

raywenderlich.com 302
Combine Chapter 16: Error Handling

Dealing with failure

Wow, so far you've learned a lot about how to deal with publishers that can't fail at
all... in an error-handling chapter! :] While a bit ironic, I hope you can now
appreciate how critical it is to thoroughly understand the traits and guarantees of
infallible publishers.

With that in mind, it's time for you to learn about some techniques and tools
Combine provides to deal with publishers that actually fail. This includes both built-
in publishers and your own publishers!

But first, how do you actually produce failure events? As mentioned in the previous
section, there are several ways to do this. You just used tryMap, so why not learn
more about how these try operators work?

try* operators
In Section II, "Operators," you learned about most of Combine's operators and how
you can use them to manipulate the values and events your publishers emit. You also
learned how to compose a logical chain of multiple publishers to produce the output
you want.

In these chapters, you learned that most operators have parallel operators prefixed
with try, and that you'll "learn about them later in this book." Well, later is now!

Combine provides an interesting distinction between operators that may throw

errors and ones that may not.

Note: All try-prefixed operators in Combine behave the same way when it
comes to errors. In the essence of time, you'll only experiment with the tryMap
operator throughout this chapter.

First, select the try operators* playground page from the Project navigator. Add the
following code to it:

example(of: "tryMap") {
// 1
enum NameError: Error {
case tooShort(String)
case unknown
}

raywenderlich.com 303
Combine Chapter 16: Error Handling

// 2
let names = ["Scott", "Marin", "Shai", "Florent"].publisher

names
// 3
.map { value in
return value.count
}
.sink(receiveCompletion: { print("Completed with \($0)") },
receiveValue: { print("Got value: \($0)") })
}

In the above example, you:

1. Define a NameError error enum, which you'll use momentarily.

2. Create a publisher emitting four different strings.

3. Map each string to its length.

Run the example and check out the console output:

——— Example of: tryMap ———

Got value: 5
Got value: 5
Got value: 4
Got value: 7
Completed with finished

All names are mapped with no issues, as expected. But then you receive a new
product requirement: Your code should throw an error if it accepts a name shorter
than 5 characters.

Replace the map in the above example with the following:

.map { value -> Int in

// 1
let length = value.count

// 2
guard length >= 5 else {
throw NameError.tooShort(value)
}

// 3
return value.count
}

In the above map, you check that the length of the string is greater or equal to 5.
Otherwise, you try to throw an appropriate error.

raywenderlich.com 304
Combine Chapter 16: Error Handling

However, as soon as you add the above code or attempt to run it, you'll see that the
compiler produces an error:

Invalid conversion from throwing function of type '(_) throws ->

_' to non-throwing function type '(String) -> _'

Since map is a non-throwing method, you can't throw errors from within it. Luckily,
the try* operators are made just for that purpose.

Replace map with tryMap and run your playground again. It will now compile and
produce the following output (truncated):

——— Example of: tryMap ———

Got value: 5
Got value: 5
Completed with failure(...NameError.tooShort("Shai"))

Mapping errors
The differences between map and tryMap go beyond the fact that the latter allows
throwing errors. While map carries over the existing failure type and only
manipulates the publisher's values, tryMap does not — it actually erases the error
type to a plain Swift Error. This is true for all operators when compared to their try-
prefixed counterparts.

Switch to the Mapping errors playground page and add the following code to it:

example(of: "map vs tryMap") {

// 1
enum NameError: Error {
case tooShort(String)
case unknown
}

// 2
Just("Hello")
.setFailureType(to: NameError.self) // 3
.map { $0 + " World!" } // 4
.sink(
receiveCompletion: { completion in
// 5
switch completion {
case .finished:
print("Done!")
case .failure(.tooShort(let name)):
print("\(name) is too short!")
case .failure(.unknown):

raywenderlich.com 305
Combine Chapter 16: Error Handling

print("An unknown name error occurred")

}
},
receiveValue: { print("Got value \($0)") }
)
.store(in: &subscriptions)
}

In the above example, you:

1. Define a NameError to use for this example.

2. Create a Just which only emits the string Hello.

3. Use setFailureType to set the failure type to NameError.

4. Append another string to the published string using map.

5. Finally, use sink's receiveCompletion to print out an appropriate message for

every failure case of NameError.

Run the playground and you'll see the following output:

——— Example of: map vs tryMap ———

Got value Hello World!
Done!

Next, find the switch completion line and Option-click on completion:

Notice that the Completion's failure type is NameError, which is exactly what you
want. The setFailureType operator lets you specifically target NameError failures
such as failure(.tooShort(let name)).

raywenderlich.com 306
Combine Chapter 16: Error Handling

Next, change map to tryMap. You'll immediately notice the playground no longer
compiles. Option-click on completion again:

Very interesting! tryMap erased your strictly-typed error and replaced it with a
general Swift.Error type. This happens even though you didn't actually throw an
error from within tryMap — you simply used it! Why is that?

The reasoning is quite simple when you think about it: Swift doesn't support typed
throws yet, even though discussions around this topic have been taking place in Swift
Evolution since 2015. This means when you use try-prefixed operators, your error
type will always be erased to the most common ancestor: Swift.Error.

So, what can you do about it? The entire point of a strictly-typed Failure for
publishers is to let you deal with — in this example — NameError specifically, and not
any other kind of error.

A naive approach would be to cast the generic error manually to a specific error type,
but that's quite suboptimal. It breaks the entire purpose of having strictly-typed
errors. Luckily, Combine provides a great solution to this problem, called mapError.

Immediately after the call to tryMap, add the following line:

.mapError { $0 as? NameError ?? .unknown }

mapError receives any error thrown from the upstream publisher and lets you map it
to any error you want. In this case, you can utilize it to cast the error back to a
NameError or fall back to a NameError.unknown error. You must provide a fallback
error in this case, because the cast could theoretically fail — even though it won't
here — and you have to return a NameError from this operator.

This restores Failure to its original type and turns your publisher back to a
Publisher<String, NameError>.

raywenderlich.com 307
Combine Chapter 16: Error Handling

Build and run the playground. It should finally compile and work as expected:

——— Example of: map vs tryMap ———

Got value Hello World!
Done!

Finally, replace the entire call to tryMap with:

.tryMap { throw NameError.tooShort($0) }

This call will immediately throw an error from within the tryMap. Check out the
console output once again, and make sure you get the properly-typed NameError:

——— Example of: map vs tryMap ———

Hello is too short!

Designing your fallible APIs

When constructing your own Combine-based code and APIs, you'll often use APIs
from other sources that return publishers that fail with various types. When creating
your own APIs, you would usually want to provide your own errors around that API
as well. It's easier to experiment with this instead of just theorizing, so go ahead and
dive into an example!

In this section, you'll build a quick API that lets you fetch somewhat-funny dad jokes
from the icanhazdadjoke API, available at https://icanhazdadjoke.com/api.

Start by switching to the Designing your fallible APIs playground page and add the
following code to it, which makes up the first portion of the next example:

example(of: "Joke API") {

class DadJokes {
// 1
struct Joke: Codable {
let id: String
let joke: String
}

// 2
func getJoke(id: String) -> AnyPublisher<Joke, Error> {
let url = URL(string: "https://icanhazdadjoke.com/j/\
(id)")!
var request = URLRequest(url: url)
request.allHTTPHeaderFields = ["Accept": "application/
json"]

// 3

raywenderlich.com 308
Combine Chapter 16: Error Handling

return URLSession.shared
.dataTaskPublisher(for: request)
.map(\.data)
.decode(type: Joke.self, decoder: JSONDecoder())
.eraseToAnyPublisher()
}
}
}

In the above code, you created the shell of your new DadJokes class by:

1. Defining a Joke struct. The API response will be decoded into an instance of
Joke.

2. Providing a getJoke(id:) method, which currently returns a publisher that

emits a Joke and can fail with a standard Swift.Error.

3. Using URLSession.dataTaskPublisher(for:) to call the icanhazdadjoke API

and decode the resulting data into a Joke using a JSONDecoder and the decode
operator. You might remember this technique from Chapter 9, “Networking.”

Finally, you'll want to actually use your new API. Add the following directly below
the DadJokes class, while still in the scope of the example:

// 4
let api = DadJokes()
let jokeID = "9prWnjyImyd"
let badJokeID = "123456"

// 5
api
.getJoke(id: jokeID)
.sink(receiveCompletion: { print($0) },
receiveValue: { print("Got joke: \($0)") })
.store(in: &subscriptions)

In this code, you:

4. Create an instance of DadJokes and define two constants with valid and invalid
joke IDs.

5. Call DadJokes.getJoke(id:) with the valid joke ID and print any completion
event or the decoded joke itself.

raywenderlich.com 309
Combine Chapter 16: Error Handling

Run your playground and look at the console:

——— Example of: Joke API ———

Got joke: Joke(id: "9prWnjyImyd", joke: "Why do bears have hairy
coats? Fur protection.")
finished

A polar bear on this book's cover and a bear joke inside? Ah, classic.

So your API currently deals with the happy path perfectly well, but this is an error-
handling chapter. When wrapping other publishers, you need to ask yourself: "What
kinds of errors can result from this specific publisher?"

In this case:

• Calling dataTaskPublisher can fail with a URLError for various reasons, such as
a bad connection or an invalid request.

• The provided joke ID might not exist.

• Decoding the JSON response might fail if the API response changes or its structure
is incorrect.

• Any other unknown error! Errors are plenty and random, so it's impossible to think
of every edge case. For this reason, you always want to have a case to cover an
unknown or unhandled error.

With this list in mind, add the following piece of code inside the DadJokes class,
immediately below the Joke struct:

enum Error: Swift.Error, CustomStringConvertible {

// 1
case network
case jokeDoesntExist(id: String)
case parsing
case unknown

// 2
var description: String {
switch self {
case .network:
return "Request to API Server failed"
case .parsing:
return "Failed parsing response from server"
case .jokeDoesntExist(let id):
return "Joke with ID \(id) doesn't exist"
case .unknown:
return "An unknown error occurred"
}

raywenderlich.com 310
Combine Chapter 16: Error Handling

}
}

This error definition:

1. Outlines all the possible errors that can occur in the DadJokes API.

2. Conforms to CustomStringConvertible, which lets you provide a friendly

description for each error case.

After adding the above Error type, your playground won't compile anymore. This is
because getJoke(id:) returns a AnyPublisher<Joke, Error>. Before, Error
referred to Swift.Error, but now it refers to DadJokes.Error — which is actually
what you want, in this case.

So, how can you take the various possible and differently-typed errors and map them
all into your DadJoke.Error? If you've been following this chapter, you've probably
guessed the answer: mapError is your friend here.

Add the following to getJoke(id:), between the calls to decode and

eraseToAnyPublisher():

.mapError { error -> DadJokes.Error in

switch error {
case is URLError:
return .network
case is DecodingError:
return .parsing
default:
return .unknown
}
}

That's it! This simple mapError uses a switch statement to replace any kind of error
the publisher may throw with a DadJokes.Error. You might ask yourself: "Why
should I wrap these errors?" The answer to this is two-fold:

1. Your publisher is now guaranteed to only fail with a DadJokes.Error, which is

useful when consuming the API and dealing with its possible errors. You know
exactly what you'll get from the type system.

2. You don't leak the implementation details of your API. Think about it, does the
consumer of your API care if you use URLSession to perform a network request
and a JSONDecoder to decode the response? Obviously not! The consumer only
cares about what your API itself defines as errors — not about its internal
dependencies.

raywenderlich.com 311
Combine Chapter 16: Error Handling

There's still one more error you haven't dealt with: a non-existent joke ID. Try
replacing the following line:

.getJoke(id: jokeID)

With:

.getJoke(id: badJokeID)

Run the playground again. This time, you'll get the following error:

failure(Failed parsing response from server)

Interestingly enough, icanhazdadjoke's API doesn't fail with an HTTP code of 404
(Not Found) when you send a non-existent ID — as would be expected of most APIs.
Instead, it sends back a different but valid JSON response:

{
message = "Joke with id \"123456\" not found";
status = 404;
}

Dealing with this case requires a bit of hackery, but it's definitely nothing you can't
handle!

Back in getJoke(id:), replace the call to map(\.data) with the following code:

.tryMap { data, _ -> Data in

// 6
guard let obj = try? JSONSerialization.jsonObject(with: data),
let dict = obj as? [String: Any],
dict["status"] as? Int == 404 else {
return data
}

// 7
throw DadJokes.Error.jokeDoesntExist(id: id)
}

In the above code, you use tryMap to perform extra validation before passing the raw
data to the decode operator:

6. You use JSONSerialization to try and check if a status field exists and has a
value of 404 — i.e., the joke doesn't exist. If that's not the case, you simply return
the data so it's pushed downstream to the decode operator.

7. If you do find a 404 status code, you throw a .jokeDoesntExist(id:) error.

raywenderlich.com 312
Combine Chapter 16: Error Handling

Run your playground again and you'll notice another tiny nitpick you need to solve:

——— Example of: Joke API ———

failure(An unknown error occurred)

The failure is actually treated as an unknown error, and not as a DadJokes.Error,

because you didn't deal with that type inside mapError.

Inside your mapError, find the following line:

return .unknown

And replace it with:

return error as? DadJokes.Error ?? .unknown

If none of the other error types match, you attempt to cast it to a DadJokes.Error
before giving up and falling back to an unknown error.

Run your playground again and take a look at the console:

——— Example of: Joke API ———

failure(Joke with ID 123456 doesn't exist)

This time around, you receive the correct error, with the correct type! Awesome. :]

Before you wrap up this example, there's one final optimization you can make in
getJoke(id:).

As you might have noticed, joke IDs consist of letters and numbers. In the case of our
"Bad ID", you've sent only numbers. Instead of performing a network request, you can
preemptively validate your ID and fail without wasting resources.

Add the following final piece of code at the beginning of getJoke(id:):

guard id.rangeOfCharacter(from: .letters) != nil else {

return Fail<Joke, Error>(error: .jokeDoesntExist(id: id))
.eraseToAnyPublisher()
}

In this code, you start by making sure id contains at least one letter. If that's not the
case, you immediately return a Fail.

raywenderlich.com 313
Combine Chapter 16: Error Handling

Fail is a special kind of publisher that lets you immediately and imperatively fail
with a provided error. It's perfect for these cases where you want to fail early based
on some condition. You finish up by using eraseToAnyPublisher to get the expected
AnyPublisher<Joke, DadJokes.Error> type.

That's it! Run your example again with the invalid ID and you'll get the same error
message. However, it will post immediately and doesn't have to go out to the
network. Great success!

Before moving on, revert your call to getJoke(id:) to use jokeID instead of
badJokeId.

At this point, you can validate your error logic by manually "breaking" your code.
After performing each of the following actions, undo your changes so you can try the
next one:

1. When you create the URL above, add a random letter inside it to break the URL.
Run the playground and you'll see: failure(Request to API Server failed).

2. Comment out the line that starts with request.allHttpHeaderFields and run
the playground. Since the server response will no longer be JSON, but instead just
be plain text, you'll see the output: failure(Failed parsing response from
server).

3. Send a random ID to getJoke(id:), as you did before. Run the playground and
you'll get: failure(Joke with ID {your ID} doesn't exist).

And that's it! You've just built your very own Combine-based, production-class API
layer with its own errors. What more could a person want? :]

Catching and retrying

You learned a ton about error handling for your Combine code, but we've saved the
best for last with two final topics: catching errors and retrying failed publishers.

The great thing about Publisher being a unified way to represent work is that you
have many operators that let you do an incredible amount of work with very few
lines of code.

Go ahead and dive right into the example.

raywenderlich.com 314
Combine Chapter 16: Error Handling

Start by switching to the Catching and retrying page in the Project navigator.
Expand the playground's Sources folder and open PhotoService.swift.

It includes a PhotoService with a fetchPhoto(quality:failingTimes:) method

that you'll use in this section. PhotoService fetches a photo in either high or low
quality using a custom publisher. For this example, asking for a high-quality image
will always fail — so you can experiment with the various techniques to retry and
catch failures as they occur.

Head back to the Catching and retrying playground page and add this bare-bones
example to your playground:

let photoService = PhotoService()

example(of: "Catching and retrying") {

photoService
.fetchPhoto(quality: .low)
.sink(
receiveCompletion: { print("\($0)") },
receiveValue: { image in
image
print("Got image: \(image)")
}
)
.store(in: &subscriptions)
}

The above code should be familiar by now. You instantiate a PhotoService and call
fetchPhoto with a .low quality. Then you use sink to print out any completion
event or the fetched image.

Notice that the instantiation of photoService is outside the scope of the example so
that it doesn't get deallocated immediately.

Run your playground and wait for it to finish. You should see the following output:

——— Example of: Catching and retrying ———

Got image: <UIImage:0x600000790750 named(lq.jpg) {300, 300}>
finished

raywenderlich.com 315
Combine Chapter 16: Error Handling

Tap the Show Result button next to the first line in receiveValue and you'll see a
beautiful low-quality picture of... well, a combine.

Next, change the quality from .low to .high and run the playground again. You'll see
the following output:

——— Example of: Catching and retrying ———

failure(Failed fetching image with high quality)

As mentioned earlier, asking for a high-quality image will fail. This is your starting
point! There are a few things that you could improve here. You'll start by retrying
upon a failure.

Many times, when you request a resource or perform some computation, a failure
might be a one-off occurrence resulting from a bad network connection or another
unavailable resource.

In these cases, you'd usually write a big ol' mechanism to retry different pieces of
work while tracking the number of attempts and deciding what to do if all attempts
fail. Fortunately, Combine makes this much, much simpler.

Like all good things in Combine, there's an operator for that!

The retry operator accepts a number. If the publisher fails, it will resubscribe to the
upstream and retry up to the number of times you specify. If all retries fail, it simply
pushes the error downstream as it would without the retry operator.

It's time for you to try this. Below the line fetchPhoto(quality: .high), add the
following line:

.retry(3)

Wait, is that it?! Yup. That's it.

raywenderlich.com 316
Combine Chapter 16: Error Handling

You get a free retry mechanism for every piece of work wrapped in a publisher,
and it's as easy as calling this simple retry operator.

Before running your playground, add this code between the calls to fetchPhoto and
retry:

.handleEvents(
receiveSubscription: { _ in print("Trying ...") },
receiveCompletion: {
guard case .failure(let error) = $0 else { return }
print("Got error: \(error)")
}
)

This code will help you see when retries occur — it prints out the subscriptions and
failures that occur in fetchPhoto.

Now you're ready! Run your playground and wait for it to complete. You'll see the
following output:

——— Example of: Catching and retrying ———

Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
failure(Failed fetching image with high quality)

As you can see, there are four attempts. The initial attempt, plus three retries
triggered by the retry operator. Because fetching a high-quality photo constantly
fails, the operator exhausts all its retry attempts and pushes the error down to sink.

Replace the following call to fetchPhoto:

.fetchPhoto(quality: .high)

With:

.fetchPhoto(quality: .high, failingTimes: 2)

The faliingTimes parameter will limit the number of times that fetching a high-
quality image will fail. In this case, it will fail the first two times you call it, then
succeed.

raywenderlich.com 317
Combine Chapter 16: Error Handling

Run your playground again, and take a look at the output:

——— Example of: Catching and retrying ———

Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got image: <UIImage:0x600001268360 named(hq.jpg) {1835, 2446}>
finished

As you can see, this time there are three attempts, the initial one plus two more
retries. The method fails for the first two attempts, and then succeeds and returns
this gorgeous, high-quality photo of a combine in a field:

Awesome! But there's still one final feature you'll improve in this service call. Your
product folks asked that you fall back to a low-quality image if fetching a high-
quality image fails. If fetching a low-quality image fails as well, you should fall back
to a hard-coded image.

You'll start with the latter of the two tasks. Combine includes a handy operator called
replaceError(with:) that lets you fall back to a default value of the publisher's
type if an error occurs. This also changes your publisher's Failure type to Never,
since you replace every possible failure with a fallback value.

First, remove the failingTimes argument from fetchPhoto, so it constantly fails as

it did before.

Then add the following line, immediately after the call to retry:

.replaceError(with: UIImage(named: "na.jpg")!)

raywenderlich.com 318
Combine Chapter 16: Error Handling

Run your playground again and take a look at the image result this time around.
After four attempts — i.e., the initial plus three retries — you fall back to a hard-
coded image on disk:

Also, looking at the console output reveals what you'd expect: There are four failed
attempts, followed by the hard-coded fallback image:

——— Example of: Catching and retrying ———

Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Got image: <UIImage:0x6000020e9200 named(na.jpg) {200, 200}>
finished

Now, for the second task and final part of this chapter: Fall back to a low-quality
image if the high-quality image fails. Combine provides the perfect operator for this
task, called catch. It lets you catch a failure from a publisher and recover from it with
a different publisher.

To see this in action, add the following code after retry, but before
replaceError(with:):

.catch { error -> PhotoService.Publisher in

print("Failed fetching high quality, falling back to low
quality")
return photoService.fetchPhoto(quality: .low)
}

raywenderlich.com 319
Combine Chapter 16: Error Handling

Run your playground one final time and take a look at the console:

——— Example of: Catching and retrying ———

Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Trying ...
Got error: Failed fetching image with high quality
Failed fetching high quality, falling back to low quality
Got image: <UIImage:0x60000205c480 named(lq.jpg) {300, 300}>
finished

Like before, the initial attempt plus three retries to fetch the high-quality image fail.
Once the operator has exhausted all retries, catch plays its role and subscribes to
photoService.fetchPhoto, requesting a low-quality image. This results in a
fallback from the failed high-quality request to the successful low-quality request.

Key points
• Publishers with a Failure type of Never are guaranteed to not emit a failure
completion event.

• Many operators only work with infallible publishers. For example:

sink(receiveValue:), setFailureType, assertNoFailure and
assign(to:on:).

• The try-prefixed operators let you throw errors from within them, while non-try
operators do not.

• Since Swift doesn't support typed throws, calling try-prefixed operators erases the
publisher's Failure to a plain Swift Error.

• Use mapError to map a publisher's Failure type, and unify all failure types in your
publisher to a single type.

• When creating your own API based on other publishers with their own Failure
types, wrap all possible errors into your own Error type to unify them and hide
your API's implementation details.

• You can use the retry operator to resubscribe to a failed publisher for an
additional number of times.

raywenderlich.com 320
Combine Chapter 16: Error Handling

• replaceError(with:) is useful when you want to provide a default fallback value

for your publisher, in case of failure.

• Finally, you may use catch to replace a failed publisher with a different fallback
publisher.

Where to go from here?

Congratulations on getting to the end of this chapter. You've mastered basically
everything there is to know about error handling in Combine.

You only experimented with the tryMap operator in the try* operators section of
this chapter. You can find a full list of try-prefixed operators in Apple's official
documentation at https://apple.co/3233VRB.

With your mastery of error handling, it's time to learn about one of the lower-level,
but most crucial topics in Combine: Schedulers. Continue to the next chapter to find
out what schedulers are and how to use them.

raywenderlich.com 321
17 Chapter 17: Schedulers
By Florent Pillet

As you’ve been progressing through this book, you’ve read about this or that
operator taking a scheduler as a parameter. Most often you’d simply use
DispatchQueue.main because it’s convenient, well understood and brings a
reassuring feeling of safety. This is the comfort zone!

As a developer, you have at least a general idea of what a DispatchQueue is. Besides
DispatchQueue.main, you most certainly already used either one of the global,
concurrent queues, or created a serial dispatch queue to run actions serially on.
Don’t worry if you haven’t or don’t remember the details. You’ll re-assess some
important information about dispatch queues throughout this chapter.

But then, why does Combine need a new similar concept? It is now time for you to
dive into the real nature, meaning and purpose of Combine schedulers!

In this chapter, you’ll learn why the concept of schedulers came about. You’ll explore
how Combine makes asynchronous events and actions easy to work with and, of
course, you’ll get to experiment with all the schedulers that Combine provides.

An introduction to schedulers
Per Apple’s documentation, a scheduler is a protocol that defines when and how to
execute a closure. Although the definition is correct, it’s only part of the story.

A scheduler provides the context to execute a future action, either as soon as

possible or at a future date. The action is a closure as defined in the protocol itself.
But the term closure can also hide the delivery of some value by a Publisher,
performed on a particular scheduler.

raywenderlich.com 322
Combine Chapter 17: Schedulers

Did you notice that this definition purposely avoids any reference to threading? This
is because the concrete implementation is the one that defines where the “context”
provided by the scheduler protocol executes!

The exact details of which thread your code will execute on therefore depends on the
scheduler you pick.

Remember this important concept: A scheduler is not equal to a thread. You’ll get
into the details of what this means for each scheduler later in this chapter.

Let’s look at the concept of schedulers from an event flow standpoint:

What you see in the figure above:

• A user action (button press) occurs on the main (UI) thread.

• It triggers some work to process on a background scheduler.

• Final data to display is delivered to subscribers on the main thread, so subscribers

can update the app‘s UI.

You can see how the notion of scheduler is deeply rooted in the notions of
foreground/background execution. Moreover, depending on the implementation you
pick, work can be serialized or parallelized.

Therefore, to fully understand schedulers, you need to look at which classes conform
to the Scheduler protocol.

But first, you need to learn about two important operators related to schedulers!

raywenderlich.com 323
Combine Chapter 17: Schedulers

Note: In the next section, you’ll primarily use DispatchQueue which conforms
to the Scheduler protocol.

Operators for scheduling

The Combine framework provides two fundamental operators to work with
schedulers:

• subscribe(on:) and subscribe(on:options:) create the subscription (start the

work) on the specified scheduler.

• receive(on:)and receive(on:options:) deliver values on the specified

scheduler.

In addition, the following operators take a scheduler and scheduler options as

parameters. You learned about them in Chapter 6, “Time Manipulation Operators:”

• debounce(for:scheduler:options:)
• delay(for:tolerance:scheduler:options:)
• measureInterval(using:options:)
• throttle(for:scheduler:latest:)
• timeout(_:scheduler:options:customError:)
Don’t hesitate to take a look back at Chapter 6 if you need to refresh your memory on
these operators. Then you can look into the two new ones.

raywenderlich.com 324
Combine Chapter 17: Schedulers

Introducing subscribe(on:)
Remember — a publisher is an inanimate entity until you subscribe to it. But what
happens when you subscribe to a publisher? Several steps take place:

1. Publisher receives the subscriber and creates a Subscription.

2. Subscriber receives the subscription and requests values from the publisher
(dotted lines).

3. Publisher starts work (via the Subscription).

4. Publisher emits values (via the Subscription).

5. Operators transform values.

6. Subscriber receives the final values.

Steps one, two and three usually happen on the thread that is current when your
code subscribes to the publisher. But when you use the subscribe(on:) operator, all
these operations run on the scheduler you specified.

raywenderlich.com 325
Combine Chapter 17: Schedulers

Note: You’ll come back to this diagram when looking at receive(on:). You’ll
then understand the two boxes at the bottom with steps labeled five and six.

You may want a publisher to perform some expensive computation in the

background to avoid blocking the main thread. The simple way to do this is to use
subscribe(on:).

It’s time to look at an example!

Open Starter.playground in the projects folder and select the subscribeOn-

receiveOn page. Make sure the Debug area is displayed, then start by adding the
following code:

// 1
let computationPublisher =
Publishers.ExpensiveComputation(duration: 3)

// 2
let queue = DispatchQueue(label: "serial queue")

// 3
let currentThread = Thread.current.number
print("Start computation publisher on thread \(currentThread)")

Here‘s a breakdown of the above code:

1. This playground defines a special publisher in Sources/Computation.swift

called ExpensiveComputation, which simulates a long-running computation that
emits a string after the specified duration.

2. A serial queue you’ll use to trigger the computation on a specific scheduler. As

you learned above, DispatchQueue adopts the Scheduler protocol.

3. You obtain the current execution thread number. In a playground, the main
thread (thread number 1) is the default thread your code runs in. The number
extension to the Thread class is defined in Sources/Thread.swift.

Note: The details of how the ExpensiveComputation publisher is

implemented do not matter for now. You will learn more about creating your
own publishers in the next chapter, “Custom Publishers & Handling
Backpressure.”

raywenderlich.com 326
Combine Chapter 17: Schedulers

Back to the subscribeOn-receiveOn playground page, you’ll need to subscribe to

computationPublisher and display the value it emits:

let subscription = computationPublisher

.sink { value in
let thread = Thread.current.number
print("Received computation result on thread \(thread): '\
(value)'")
}

Execute the playground and look at the output:

Start computation publisher on thread 1

ExpensiveComputation subscriber received on thread 1
Beginning expensive computation on thread 1
Completed expensive computation on thread 1
Received computation result on thread 1 'Computation complete'

Let’s dig into the various steps to understand what happens:

• Your code is running on the main thread. From there, it subscribes to the
computation publisher.

• Publisher receives a subscriber.

• It creates a subscription, then starts the work.

• When work completes, publisher delivers the result through the subscription and
completes.

You can see that all of this happen on thread 1 which is the main thread.

Now, change the publisher subscription to insert a subscribe(on:) call:

let subscription = computationPublisher

.subscribe(on: queue)
.sink { value in...

Execute the playground again to see output similar to the following:

Start computation publisher on thread 1

ExpensiveComputation subscriber received on thread 5
Beginning expensive computation from thread 5
Completed expensive computation on thread 5
Received computation result on thread 5 'Computation complete'

raywenderlich.com 327
Combine Chapter 17: Schedulers

Ah! This is different! Now you can see that you’re still subscribing from the main
thread, but Combine delegates to the queue you provided to perform the
subscription effectively. The queue runs the code on one of its threads. Since the
computation starts and completes on thread 5 and then emits the resulting value
from this thread, your sink receives the value on this thread as well.

Note: Due to the dynamic thread management nature of DispatchQueue, you

may see different thread numbers in this log and further logs in this chapter.
What matters is consistency: The same thread number should be shown at the
same steps.

But what if you wanted to update some on-screen info? You would need to do
something like DispatchQueue.main.async { ... } in your sink closure, just to
make sure you’re performing UI updates from the main thread.

There is a more effective way to do this with Combine!

Introducing receive(on:)
The second important operator you want to know about is receive(on:). It lets you
specify which scheduler should be used to deliver values to subscribers. But what
does this mean?

Insert a call to receive(on:) just before your sink in the subscription:

let subscription = computationPublisher

.subscribe(on: queue)
.receive(on: DispatchQueue.main)
.sink { value in

Then, execute the playground again. Now you see this output:

Start computation publisher on thread 1

ExpensiveComputation subscriber received on thread 4
Beginning expensive computation from thread 4
Completed expensive computation on thread 4
Received computation result on thread 1 'Computation complete'

raywenderlich.com 328
Combine Chapter 17: Schedulers

Note: You may see the second message (“ExpensiveComputation subscriber

received...”) on a different thread than the two next steps. Due to internal
plumbing in Combine, this step and the next may execute asynchronously on
the same queue. Since Dispatch dynamically manages its thread pool, you
may see a different thread number for this line and the next, but you won’t see
thread 1.

Success! Even though the computation works and emits results from a background
thread, you are now guaranteed always to receive values on the main queue. This is
what you need to perform your UI updates safely.

In this introduction to scheduling operators, you used DispatchQueue. Combine

extends it to implement the Scheduler protocol, but it’s not the only one! It’s time
to dive into schedulers!

Scheduler implementations
Apple provides several concrete implementations of the Scheduler protocol:

• ImmediateScheduler: A simple scheduler that executes code immediately on the

current thread, which is the default execution context unless modified using
subscribe(on:), receive(on:) or any of the other operators which take a
scheduler as parameter.

• RunLoop: Tied to Foundation’s Thread object.

• DispatchQueue: Can either be serial or concurrent.

• OperationQueue: A queue that regulates the execution of work items.

In the rest of this chapter, you’ll go over all of these and their specific details.

Note: One glaring omission here is the lack of a TestScheduler, an

indispensable part of the testing portion of any reactive programming
framework. Without such a virtual, simulated scheduler, it’s challenging to test
your Combine code thoroughly. You’ll explore more details about this
particular kind of scheduler in Chapter 19, “Testing.”

raywenderlich.com 329
Combine Chapter 17: Schedulers

ImmediateScheduler
The easiest entry in the scheduler category is also the simplest one the Combine
framework provides: ImmediateScheduler. The name already spoils the details, so
have a look at what it does!

Open the ImmediateScheduler page of the playground. You won’t need the debug
area for this one, but make sure you make the Live View visible. If you’re not sure
how to do that, see the beginning of Chapter 6, “Time Manipulation Operators.”

You’re going to use some fancy new tools built into this playground to follow your
publisher values across schedulers!

Start by creating a simple timer as you did in previous chapters:

let source = Timer

.publish(every: 1.0, on: .main, in: .common)
.autoconnect()
.scan(0) { counter, _ in counter + 1 }

Next, prepare a closure that creates a publisher. You’ll make use of a custom operator
defined in the Sources/Record.swift: recordThread(using:). This operator records
the thread that is current at the time the operator sees a value passing through, and
can record multiple times from the publisher source to the final sink.

Note: This recordThread(using:) operator is for testing purposes only, as

the operator changes the type of data to an internal value type. The details of
its implementation are beyond the scope of this chapter, but the adventurous
reader may find it interesting to look into.

Add this code:

// 1
let setupPublisher = { recorder in
source
// 2
.recordThread(using: recorder)
// 3
.receive(on: ImmediateScheduler.shared)
// 4
.recordThread(using: recorder)
// 5
.eraseToAnyPublisher()
}

raywenderlich.com 330
Combine Chapter 17: Schedulers

// 6
let view = ThreadRecorderView(title: "Using ImmediateScheduler",
setup: setupPublisher)
PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

In the above code, you:

1. Create a publisher that receives a recorder. The recordThread(using:) operator

needs it to record current thread information.

2. At this stage, the timer emitted a value, so you record the current thread. Can you
already guess which one it is?

3. Instruct that values must be delivered on the ImmediateScheduler.

4. Record which thread you’re now on.

5. The closure must return an AnyPublisher type. This is mainly for convenience
in the internal implementation.

6. Prepare and instantiate a ThreadRecorderView which displays the migration of a

published value across threads at various record points.

Execute the playground page and look at the output after a few seconds:

This representation shows each value the source publisher (the timer) emits. On
each line, you see the threads the value is going through. Every time you add a
recordThread(using:) operator, you see an additional thread number logged on
the line.

Here you see that at the two recording points you added, the current thread was the
main thread. This is because the ImmediateScheduler “schedules” immediately on
the current thread.

raywenderlich.com 331
Combine Chapter 17: Schedulers

To verify this, you can do a little experiment! Go back to your setupPublisher

closure definition, and just before the first recordThread line, insert the following:

.receive(on: DispatchQueue.global())

This requests that values the source emits be further made available on the global
concurrent queue. Is this going to yield interesting results? Execute the playground
to find out:

This is completely different! Can you guess why the thread changes all the time?
You’ll learn more about this in the coverage of DispatchQueue in this chapter!

ImmediateScheduler options
In most of the operators accepting a Scheduler in their arguments, you can also find
an options argument which accepts a SchedulerOptions value. In the case of
ImmediateScheduler, this type is defined as Never so when using
ImmediateScheduler, you should never pass a value for the options parameter of
the operator.

ImmediateScheduler pitfalls
One specific thing about ImmediateScheduler is that it is immediate. You won’t be
able to use any of the schedule(after:) variants of the Scheduler protocol
because the SchedulerTimeType you need to specify a delay has no public initializer
and is meaningless for immediate scheduling.

Similar but different pitfalls exist for the second type of Scheduler you’ll learn
about in this chapter: RunLoop.

raywenderlich.com 332
Combine Chapter 17: Schedulers

RunLoop scheduler
Long-time iOS and macOS developers are familiar with RunLoop. Predating
DispatchQueue, it is a way to manage input sources at the thread level, including in
the Main (UI) thread. Your application’s main thread still has an associated RunLoop.
You can also obtain one for any Foundation Thread by calling RunLoop.current
from the current thread.

Note: Nowadays RunLoop is a less useful class, as DispatchQueue is a sensible

choice in most situations. This said, there are still some specific cases where
run loops are useful. For example, Timer schedules itself on a RunLoop. UIKit
and AppKit rely on RunLoop and its execution modes for handling various user
input situations. Describing everything about RunLoop is outside the scope of
this book.

To have a look at RunLoop, open the RunLoop page in the playground. The Timer
source you used earlier is the same, so it’s already written for you. Add this code after
it:

let setupPublisher = { recorder in

source
// 1
.receive(on: DispatchQueue.global())
.recordThread(using: recorder)
// 2
.receive(on: RunLoop.current)
.recordThread(using: recorder)
.eraseToAnyPublisher()
}

let view = ThreadRecorderView(title: "Using RunLoop", setup:

setupPublisher)
PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

1. As you previously did, you first make values go through the global concurrent
queue. Why? Because it’s fun!

2. Then, you ask values to be received on RunLoop.current.

But what is RunLoop.current? It is the RunLoop associated with the thread that was
current when the call was made. The closure is being called by ThreadRecorderView,
from the main thread to set up the publisher and the recorder. Therefore,
RunLoop.current is the main thread’s RunLoop.

raywenderlich.com 333
Combine Chapter 17: Schedulers

Execute the playground to see what happens:

As requested, the first recordThread shows that each value goes through one of the
global concurrent queue’s threads, then continues on the main thread.

A little comprehension challenge

What would happen if you had used subscribe(on: DispatchQueue.global())
instead of receive(on:) the first time? Try it!

You see that everything is recorded on thread one. It may not be evident at first, but
it is entirely logical. Yes, the publisher was subscribed to on the concurrent queue.
But remember that you are using a Timer which is emitting its values... on the main
RunLoop! Therefore, regardless of the scheduler you pick to subscribe to this
publisher on, values will always begin their journey from the main thread.

Scheduling code execution with RunLoop

The Scheduler lets you schedule code that executes as soon as possible, or after a
future date. While it was not possible to use the latter form with
ImmediateScheduler, RunLoop is perfectly capable of deferred execution.

Each scheduler implementation defines its own SchedulerTimeType. It makes things

a little complicated to grasp until you figure out what type of data to use. In the case
of RunLoop, the SchedulerTimeType value is a Date.

You’ll schedule an action that will cancel the ThreadRecorderView’s subscription

after a few seconds. It turns out the ThreadRecorder class has an optional
Cancellable that can be used to stop its subscription to the publisher.

raywenderlich.com 334
Combine Chapter 17: Schedulers

First, you need a variable to hold a reference to the ThreadRecorder. At the

beginning of the page, add this line:

var threadRecorder: ThreadRecorder? = nil

Now you need to capture the thread recorder instance. The best place to do this is on
the setupPublisher closure. But how? You could:

• Add explicit types to the closure, assign the threadRecorder variable and return
the publisher. You’ll need to add explicit types because the poor Swift compiler
“may be unable to infer complex closure return type.“ !!

• Use some operator to capture the recorder at subscription time.

Go wild and do the latter!

Add this line in your setupPublisher closure anywhere between the first and the
last line:

.handleEvents(receiveSubscription: { _ in threadRecorder =
recorder })

Interesting choice to capture the recorder!

Note: You already learned about handleEvents in Chapter 10, “Debugging.” It

has a complex signature and lets you execute code at various points in the
lifecycle of a publisher (in the reactive programming terminology this is called
injecting side effects) without actually interacting with the values it emits. In
this case, you’re intercepting the moment when the recorder subscribes to the
publisher, so as to capture the recorder in your global variable. Not pretty, but
it does the job in a fun way!

Now you’re all set and can schedule some action after a few seconds. Add this code at
the end of the page:

RunLoop.current.schedule(
after: .init(Date(timeIntervalSinceNow: 4.5)),
tolerance: .milliseconds(500)) {
threadRecorder?.subscription?.cancel()
}

raywenderlich.com 335
Combine Chapter 17: Schedulers

This schedule(after:tolerance:) lets you schedule when the provided closure

should execute along with the tolerable drift in case the system can’t precisely
execute the code at the selected time. You add 4.5 seconds to the current date to
allow four values to be sent before the execution.

Run the playground. You can see that the list stops updating after the fourth item.
This is your cancellation mechanism working!

Note: If you only get three values, it might mean your Mac is running a little
slow and cannot accommodate a half-second tolerance, so you can try
bumping the dates out more, e.g., set timeIntervaleSinceNow to 5.0 and
tolerance to 1.0.

RunLoop options
Like ImmediateScheduler, RunLoop does not offer any suitable options for the calls
which take a SchedulerOptions parameter.

RunLoop pitfalls
Usages of RunLoop should be restricted to the main thread’s run loop, and to the
RunLoop available in Foundation threads that you control if needed. That is,
anything you started yourself using a Thread object.

One particular pitfall to avoid is using RunLoop.current in code executing on a

DispatchQueue. This is because DispatchQueue threads can be ephemeral, which
makes them nearly impossible to rely on with RunLoop.

You are now ready to learn about the most versatile and useful scheduler:
DispatchQueue!

DispatchQueue scheduler
Throughout this chapter and previous chapters, you’ve been using DispatchQueue in
various situations. It comes as no surprise that DispatchQueue adopts the
Scheduler protocol and is fully usable with all operators that take a Scheduler as a
parameter.

But first, a quick refresher on dispatch queues. The Dispatch framework is a powerful
component of Foundation that allows you to execute code concurrently on multicore
hardware by submitting work to dispatch queues managed by the system.

raywenderlich.com 336
Combine Chapter 17: Schedulers

A DispatchQueue can be either serial (the default) or concurrent. A serial queue

executes all the work items you feed it, in sequence. A concurrent queue will start
multiple work items in parallel, to maximize CPU usage. Both queue types have
different usages:

• A serial queue is typically used to guarantee that some operations do not overlap.
So, they can use shared resources without locking if all operations occur in the
same queue.

• A concurrent queue will execute as many operations concurrently as possible. So,

it is better suited for pure computation.

Queues and threads

The most familiar queue you work with all the time is DispatchQueue.main. It
directly maps to the main (UI) thread, and all operations executing on this queue can
freely update the user interface. UI updates are only permitted from the main thread.

All other queues, serial or concurrent, execute their code in a pool of threads
managed by the system. Meaning you should never make any assumption about the
current thread in code that runs in a queue. In particular, you should not schedule
work using RunLoop.current because of the way DispatchQueue manages its
threads.

All dispatch queues share the same pool of threads. A serial queue being given work
to perform will use any available thread in that pool. A direct consequence is that
two successive work items from the same queue may use different threads while still
executing sequentially.

This is an important distinction: When using subscribe(on:), receive(on:) or any

of the other operators taking a Scheduler parameter, you should never assume that
the thread backing the scheduler is the same every time.

Using DispatchQueue as a scheduler

It’s time for you to experiment! As usual, you’re going to use a timer to emit values
and watch them migrate across schedulers. But this time around, you’re going to
create the timer using a Dispatch Queue timer.

Open the playground page named DispatchQueue. First, you‘ll create a couple
queues to work with. Add this code to your playground:

let serialQueue = DispatchQueue(label: "Serial queue")

let sourceQueue = DispatchQueue.main

raywenderlich.com 337
Combine Chapter 17: Schedulers

You’ll use sourceQueue to publish values from a timer, and later use serialQueue to
experiment with switching schedulers.

Now add this code:

// 1
let source = PassthroughSubject<Void, Never>()

// 2
let subscription = sourceQueue.schedule(after: sourceQueue.now,
interval: .seconds(1)) {
source.send()
}

1. You’ll use a Subject to emit a value when the timer fires. You don’t care about
the actual output type, so you just use Void.

2. As you learned in Chapter 11, “Timers,” queues are perfectly capable of

generating timers, but there is no Publisher API for queue timers. It is a
surprising omission from the API! You have to use the repeating variant of the
schedule() method from the Schedulers protocol. It starts immediately and
returns a Cancellable. Every time the timer fires, you‘ll send a Void value
through the source subject.

Note: Did you notice how you’re using the now property to specify the starting
time of the timer? This is part of the Scheduler protocol and returns the
current time expressed using the scheduler’s SchedulerTimeType. Each class
implementing the Scheduler protocol defines its own type for this.

Now, you can start exercising scheduler hopping. Setup your Publisher by adding the
following code:

let setupPublisher = { recorder in

source
.recordThread(using: recorder)
.receive(on: serialQueue)
.recordThread(using: recorder)
.eraseToAnyPublisher()
}

Nothing new here, you’ve coded similar patterns several times in this chapter.

raywenderlich.com 338
Combine Chapter 17: Schedulers

Then, as in your the previous examples, set up the display:

let view = ThreadRecorderView(title: "Using DispatchQueue",

setup: setupPublisher)
PlaygroundPage.current.liveView = UIHostingController(rootView:
view)

Execute the playground. Easy enough, you see what was intended:

1. The timer fires on the main queue and sends Void values through the subject.

2. The publisher receive values on your serial queue.

Did you notice how the second recordThread(using:) records changes in the
current thread after the receive(on:) operator? This is a perfect example of how
DispatchQueue makes no guarantee over which thread each work item executes on.
In the case of receive(on:), a work item is a value that hops from the current
scheduler to another.

Now, what would happen if you emitted values from the serial queue and kept the
same receive(on:) operator? Would values still change threads on the go?

Try it! Go back to the beginning of the code and change the sourceQueue definition
to:

let sourceQueue = serialQueue

raywenderlich.com 339
Combine Chapter 17: Schedulers

Now, execute the playground again:

Interesting! Again you see the no-thread-guarantee effect of DispatchQueue, but you
also see that the receive(on:) operator never switches threads! It looks like some
optimization is internally happening to avoid extra switching. You’ll explore this in
this chapter’s challenge!

DispatchQueue options
DispatchQueue is the only scheduler providing a set of options you can pass when
operators take a SchedulerOptions argument. These options mainly revolve around
specifying QoS (Quality of Service) values independently of those already set on the
DispatchQueue. There are some additional flags for work items, but you won’t need
them in the vast majority of situations.

To see how you would specify the QoS though, modify the receive(on:options:) in
your setupPublisher to the following:

.receive(
on: serialQueue,
options: DispatchQueue.SchedulerOptions(qos: .userInteractive)
)

You pass an instance of DispatchQueue.SchedulerOptions to options that

specifies the highest quality of service: .userInteractive. It instructs the OS to
make its best effort to prioritize delivery of values over less important tasks. This is
something you can use when you want to update the user interface as fast as
possible. To the contrary, if there is less pressure for speedy delivery, you could use
the .background quality of service. In the context of this example you won’t see a
real difference since it’s the only task running.

raywenderlich.com 340
Combine Chapter 17: Schedulers

Using these options in real applications helps the OS deciding which task to schedule
first in situations where you have many queues busy at the same time. It really is fine
tuning your application performance!

You’re nearly done with schedulers! Hang on a little bit more. You have one last
scheduler to learn.

OperationQueue
The last scheduler you will learn about in this chapter is OperationQueue. This
system class is defined as a queue that regulates the execution of operations. It is a rich
regulation mechanism that lets you create advanced operations with dependencies.
But in the context of Combine, you will use none of these mechanisms.

Since OperationQueue uses Dispatch under the hood, there is little difference on
the surface in using one of the other. Or is there?

Give it a go in a simple example. Open the OperationQueue playground page and

start coding:

let queue = OperationQueue()

let subscription = (1...10).publisher

.receive(on: queue)
.sink { value in
print("Received \(value)")
}

You’re creating a simple publisher emitting numbers between 1 and 10, making sure
values arrive on the OperationQueue you created. You then print the value in the
sink.

Can you guess what happens? Expand the Debug area and execute the playground:

Received 4
Received 3
Received 2
Received 7
Received 5
Received 10
Received 6
Received 9
Received 1
Received 8

raywenderlich.com 341
Combine Chapter 17: Schedulers

This is puzzling! Items have been emitted in order but arrive out of order! How can
this be? To find out, you can change the print line to display the current thread
number:

print("Received \(value) on thread \(Thread.current.number)")

Execute the playground again:

Received 1 on thread 5
Received 2 on thread 4
Received 4 on thread 7
Received 7 on thread 8
Received 6 on thread 9
Received 10 on thread 10
Received 5 on thread 11
Received 9 on thread 12
Received 3 on thread 13
Received 8 on thread 14

Ah-ha! As you can see see, each value is received on a different thread! If you look up
the documentation about OperationQueue, there is a note about threading which
says that OperationQueue uses the Dispatch framework (hence DispatchQueue) to
execute operations. It means it doesn‘t guarantee it’ll use the same underlying
thread for each delivered value.

Moreover, there is one parameter in each OperationQueue that explains everything:

It’s maxConcurrentOperationCount. It defaults to a system-defined number that
allows an operation queue to execute a large number of operations concurrently.
Since your publisher emits all its items at roughly the same time, they get dispatched
to multiple threads by Dispatch’s concurrent queues!

Make a little modification to your code. After defining queue, add this line:

queue.maxConcurrentOperationCount = 1

Then run the page and look at the debug area:

Received 1 on thread 3
Received 2 on thread 3
Received 3 on thread 3
Received 4 on thread 3
Received 5 on thread 4
Received 6 on thread 3
Received 7 on thread 3
Received 8 on thread 3
Received 9 on thread 3
Received 10 on thread 3

raywenderlich.com 342
Combine Chapter 17: Schedulers

This time, you get true sequential execution — setting

maxConcurrentOperationCount to 1 is equivalent to using a serial queue — and
your values arrive in order.

OperationQueue options
There is no usable SchedulerOptions for OperationQueue. It’s actually type aliased
to RunLoop.SchedulerOptions, which itself provides no option.

OperationQueue pitfalls
You just saw that OperationQueue executes operations concurrently by default. You
need to be very aware of this as it can cause you trouble: By default, an
OperationQueue behaves like a concurrent DispatchQueue.

It can be a good tool, though, when you have significant work to perform every time a
publisher emits a value. You can control the load by tuning the
maxConcurrentOperationCount parameter.

Challenges
Phew, this was a long and complex chapter! Congratulations on making it so far!
Have some brainpower left for a couple of challenges? Let’s do it!

Challenge 1: Stop the timer

This is an easy one. In this chapter’s section about DispatchQueue you created a
cancellable timer to feed your source publisher with values.

Devise two different ways of stopping the timer after 4 seconds. Hint: You’ll need to
use DispatchQueue.SchedulerTimeType.advanced(by:).

Found the solutions? Compare them to the ones in the projects/challenge/

challenge1/ final playground:

1. Use the serial queue’s scheduler protocol schedule(after:_:) method to

schedule the execution of a closure which cancels the subscription.

2. Use serialQueue’s normal asyncAfter(_:_:) method (pre-Combine) to do the

same thing.

raywenderlich.com 343
Combine Chapter 17: Schedulers

Challenge 2: Discover optimization

Earlier in this chapter, you read about an intriguing question: Is Combine optimizing
when you’re using the same scheduler in successive receive(on:) calls, or is it a
Dispatch framework optimization?

To find out, you’ll want to turn over to challenge 2. Your challenge is to devise a
method that will bring an answer to this question. It’s not very complicated, but it’s
not trivial either.

Could you find a solution? Read on to compare yours!

In the Dispatch framework, the initializer for DispatchQueue takes an optional

target parameter. It lets you specify a queue on which to execute your code. In other
words, the queue you create is just a shadow while the real queue on which your code
executes is the target queue.

So the idea to try and guess whether Combine or Dispatch is performing the
optimization is to use two different queues having one targeting the other. So at the
Dispatch framework level, code all executes on the same queue, but (hopefully)
Combine doesn’t notice.

Therefore, if you do this and see all values being received on the same thread, it is
most likely that Dispatch is performing the optimizations for you. The steps you take
to code the solution are:

1. Create the second serial queue, targeting the first one.

2. Add a .receive(on:) for the second serial queue, as well as a .recordThread

step.

The full solution is available in the projects/challenge/challenge2 final

playground.

raywenderlich.com 344
Combine Chapter 17: Schedulers

Key points
• A Scheduler defines the execution context for a piece of work.

• Apple‘s operating systems offer a rich variety of tools to help you schedule code
execution.

• Combine tops these schedulers with the Scheduler protocol to help you pick the
best one for the job in any given situation.

• Every time you use receive(on:), further operators in your publisher execute on
the specified scheduler. That is, unless they themselves take a Scheduler
parameter!

Where to go from here?

You‘ve learned a lot, and your brain must be melting with all this information! The
next chapter is even more involved as it teaches you about creating your own
publishers and dealing with backpressure. Make sure you schedule a much-deserved
break now, and come back refreshed for the next chapter!

raywenderlich.com 345
18 Chapter 18: Custom
Publishers & Handling
Backpressure
By Florent Pillet

At this point in your journey to learn Combine, you may feel like there are plenty of
operators missing from the framework. This may be particularly true if you have
experience with other reactive frameworks, which typically provide a rich ecosystem
of operators, both built-in and third-party. Combine allows you to create your own
publishers. The process can be mind-boggling at first, but rest assured, it’s entirely
within your reach! This chapter will show you how.

A second, related topic you’ll learn about in this chapter is backpressure

management. This will require some explanation: What is this backpressure thing?
Is that some kind of back pain induced by too much leaning over your chair,
scrutinizing Combine code? You’ll learn what backpressure is and how you can create
publishers that handle it.

Creating your own publishers

The complexity of implementing your own publishers can vary from “easy” to “pretty
involved.” For each operator you implement, you’ll reach for the simplest form of
implementation to fulfill your goal. In this chapter, you’ll look at three different ways
of crafting your own publishers:

• Using a simple extension method in the Publisher namespace.

• Implementing a type in the Publishers namespace with a Subscription that

produces values.

• Same as above, but with a subscription that transforms values from an upstream
publisher.

raywenderlich.com 346
Combine Chapter 18: Custom Publishers & Handling Backpressure

Note: It’s technically possible to create a custom publisher without a custom

subscription. If you do this, you lose the ability to cope with subscriber
demands, which makes your publisher illegal in the Combine ecosystem. Early
cancellation can also become an issue. This is not a recommended approach,
and this chapter will teach you how to write your publishers correctly.

Publishers as extension methods

Your first task is to implement a simple operator just by reusing existing operators.
This is as simple as you can get.

To do it, you’ll add a new unwrap() operator, which unwraps optional values and
ignores their nil values. It’s going to be a very simple exercise, as you can reuse the
existing compactMap(_:) operator, which does just that, although it requires you to
provide a closure.

Using your new unwrap() operator will make your code easier to read, and it will
make what you’re doing very clear. The reader won’t even have to look at the
contents of a closure.

You’ll add your operator in the Publisher namespace, as you do with all other
operators.

Open the starter playground for this chapter, which can be found in projects/
Starter.playground and open its Unwrap operator page from the Project
Navigator. Then, add the following code:

extension Publisher {
// 1
func unwrap<T>() -> Publishers.CompactMap<Self, T> where
Output == Optional<T> {
// 2
compactMap { $0 }
}
}

1. The most complicated part of writing a custom operator as a method is the

signature. Read on for a detailed description.

2. Implementation is trivial: Simply use compactMap(_:) on self!

raywenderlich.com 347
Combine Chapter 18: Custom Publishers & Handling Backpressure

The method signature can be mind-boggling to craft. Break it down to see how it
works:

func unwrap<T>()

Your first step is to make the operator generic, as its Output is the wrapped type of
the containing optional.

-> Publishers.CompactMap<Self, T>

The implementation uses a single compactMap(_:), so the return type derives from
this. If you look at Publishers.CompactMap, you see it’s a generic type: public
struct CompactMap<Upstream, Output>. When implementing your custom
operator, Upstream is Self (the publisher you’re extending) and Output is the
wrapped type.

where Output == Optional<T> {

Finally, you constrain your operator to Optional types. You conveniently write it to
match the wrapped type T with your method’s generic type... et voilà!

Note: When developing more complex operators as methods, such as when

using a chain of operators, the signature can quickly become very complicated.
A good technique is to make your operators return an
AnyPublisher<OutputType, FailureType>. In the method, you’ll return a
publisher that ends with eraseToAnyPublisher() to type-erase the signature.

Testing your custom operator

Now you can test your new operator. Add this code below the extension:

let values: [Int?] = [1, 2, nil, 3, nil, 4]

values.publisher
.unwrap()
.sink {
print("Received value: \($0)")
}

raywenderlich.com 348
Combine Chapter 18: Custom Publishers & Handling Backpressure

Run the playground and, as expected, only the non-nil values are printed out to the
debug console:

Received value: 1
Received value: 2
Received value: 3
Received value: 4

Now that you’ve learned about making simple operator methods, it’s time to dive
into richer, more complicated publishers. You can group publishers into two types:

• Publishers that act as "producers" and directly produce values themselves.

• Publishers that act as "transformers," transforming values produced by upstream

publishers.

In this chapter, you’ll learn how to use both, but you first need to understand the
details of what happens when you subscribe to a publisher.

The subscription mechanism

Subscriptions are the unsung heroes of Combine: While you see publishers
everywhere, they are mostly inanimate entities. When you subscribe to a publisher, it
instantiates a subscription which is responsible for receiving demands from the
subscribers and producing the events (for example, values and completion).

Here are the details of the lifecycle of a subscription:

raywenderlich.com 349
Combine Chapter 18: Custom Publishers & Handling Backpressure

1. The subscriber subscribes to the publisher.

2. The publisher creates a Subscription and hands it over to the subscriber

(calling receive(subscription:)).

3. The subscriber requests values from the subscription by sending it the number of
values it wants (calling the subscription’s request(_:) method).

4. The subscription begins the work and starts emitting values. It sends them one by
one to the subscriber (calling the subscriber’s receive(_:) method).

5. Upon receiving a value, the subscriber returns a new Subscribers.Demand,

which adds to the previous total demand.

6. The subscription keeps sending values until the number of values sent reaches
the total requested number.

If the subscription has sent as many values as the subscriber has requested, it should
wait for a new demand request before sending more. You can bypass this mechanism
and keep sending values, but that breaks the contract between the subscriber and the
subscription and can cause undefined behavior in your publisher tree based on
Apple’s definition.

Finally, if there is an error or the subscription’s values source completes, the

subscription calls the subscriber’s receive(completion:) method.

Publishers emitting values

In Chapter 11, “Timers,” you learned about Timer.publish() but found that using
Dispatch Queues for timers was somewhat uneasy. Why not develop your own timer
based on Dispatch’s DispatchSourceTimer?

You’re going to do just that, checking out the details of the Subscription
mechanism while you do.

To get started, open the DispatchTimer publisher page of the playground.

You’ll start by defining a configuration structure, which will make it easy to share the
timer configuration between the subscriber and its subscription. Add this code to the
playground:

struct DispatchTimerConfiguration {
// 1
let queue: DispatchQueue?

raywenderlich.com 350
Combine Chapter 18: Custom Publishers & Handling Backpressure

// 2
let interval: DispatchTimeInterval
// 3
let leeway: DispatchTimeInterval
// 4
let times: Subscribers.Demand
}

If you’ve ever used DispatchSourceTimer, some of these properties should look

familiar to you:

1. You want your timer to be able to fire on the specified queue, but you also want to
make the queue optional if you don’t care. In this case, the timer will fire on a
queue of its choice.

2. The interval at which the timer will fire, starting from the subscription time.

3. The leeway, which is the maximum amount of time after the deadline that the
system may delay the delivery of the timer event.

4. The number of timer events you want to receive. Since you’re making your own
timer, make it flexible and able to deliver a limited number of events before
completing!

Adding the DispatchTimer publisher

You can now start creating your DispatchTimer publisher. It’s going to be
straightforward because all the work occurs inside the subscription!

Add this code below your configuration:

extension Publishers {
struct DispatchTimer: Publisher {
// 5
typealias Output = DispatchTime
typealias Failure = Never

// 6
let configuration: DispatchTimerConfiguration

init(configuration: DispatchTimerConfiguration) {
self.configuration = configuration
}
}
}

raywenderlich.com 351
Combine Chapter 18: Custom Publishers & Handling Backpressure

5. Your timer emits the current time as a DispatchTime value. Of course, it never
fails, so the publisher’s Failure type is Never.

6. Keeps a copy of the given configuration. You don’t use it right now, but you’ll
need it when you receive a subscriber.

Note: You’ll start seeing compiler errors as you write your code. Rest assured
that you’ll remedy these by the time you’re done implementing the
requirements.

Now, implement the Publisher protocol’s required receive(subscriber:) method

by adding this code to the DispatchTimer definition, below your initializer:

// 7
func receive<S: Subscriber>(subscriber: S)
where Failure == S.Failure,
Output == S.Input {
// 8
let subscription = DispatchTimerSubscription(
subscriber: subscriber,
configuration: configuration
)
// 9
subscriber.receive(subscription: subscription)
}

7. The function is a generic one; it needs a compile-time specialization to match

the subscriber type.

8. The bulk of the action will happen inside the DispatchTimerSubscription that
you’re going to define in a short while.

9. As you learned in Chapter 2, “Publishers & Subscribers,” a subscriber receives a

Subscription, which it can then send requests for values to.

That’s really all there is to the publisher! The real work will happen inside the
subscription itself.

Building your subscription

The subscription’s role is to:

• Accept the initial demand from the subscriber.

• Generate timer events on demand.

raywenderlich.com 352
Combine Chapter 18: Custom Publishers & Handling Backpressure

• Add to the demand count every time the subscriber receives a value and returns a
demand.

• Make sure it doesn’t deliver more values than requested in the configuration.

This may sound like a lot of code, but it’s not that complicated!

Start defining the subscription below the extension on Publishers:

private final class DispatchTimerSubscription

<S: Subscriber>: Subscription where S.Input == DispatchTime {
}

The signature itself gives a lot of information:

• This subscription is not visible externally, only through the Subscription

protocol, so you make it private.

• It’s a class because you want to pass it by reference. The subscriber may then add it
to a Cancellable collection, but also keep it around and call cancel()
independently.

• It caters to subscribers whose Input value type is DispatchTime, which is what

this subscription emits.

Adding required properties to your

subscription
Now add these properties to the subscription class’ definition:

// 10
let configuration: DispatchTimerConfiguration
// 11
var times: Subscribers.Demand
// 12
var requested: Subscribers.Demand = .none
// 13
var source: DispatchSourceTimer? = nil
// 14
var subscriber: S?

raywenderlich.com 353
Combine Chapter 18: Custom Publishers & Handling Backpressure

This code contains:

10. The configuration that the subscriber passed.

11. The maximum number of times the timer will fire, which you copied from the
configuration. You’ll use it as a counter that you decrement every time you send a
value.

12. The current demand from the subscriber — you decrement it every time you send
a value.

13. The internal DispatchSourceTimer that will generate the timer events.

14. The subscriber. This makes it clear that the subscription is responsible for
retaining the subscriber for as long as it doesn’t complete, fail or cancel.

Note: This last point is crucial to understand the ownership mechanism in

Combine. A subscription is the link between a subscriber and a publisher.
It keeps the subscriber — for example, an object holding closures, like
AnySubscriber or sink — around for as long as necessary. This explains why,
if you don’t hold on to a subscription, your subscriber never seems to receive
values: Everything stops as soon as the subscription is deallocated. Internal
implementation may of course vary according to the specifics of the publisher
you are coding.

Initializing and canceling your subscription

Now, add the initializer to your subscription definition:

init(subscriber: S,
configuration: DispatchTimerConfiguration) {
self.configuration = configuration
self.subscriber = subscriber
self.times = configuration.times
}

This is pretty straightforward. The initializer sets the given parameters on self. This
includes setting times to the maximum number of times the publisher should
receive timer events, as the configuration specifies. Every time the publisher emits an
event, this counter decrements. When it reaches zero, the timer completes with a
finished event.

raywenderlich.com 354
Combine Chapter 18: Custom Publishers & Handling Backpressure

Now, implement cancel(), a required method that a Subscription must provide:

func cancel() {
source = nil
subscriber = nil
}

Setting DispatchSourceTimer to nil is enough to stop it from running. Setting the

subscriber property to nil releases it from the subscription’s reach. Don’t forget to
do this in your own subscriptions to make sure you don’t retain objects in memory
that are no longer needed.

You can now start coding the core of the subscription: request(_:).

Letting your subscription request values

Do you remember what you learned in Chapter 2, “Publishers & Subscribers?” Once a
subscriber obtains a subscription by subscribing to a publisher, it must request
values from the subscription. This is where all the magic happens. To implement it,
add this method to the class, above the cancel method:

// 15
func request(_ demand: Subscribers.Demand) {
// 16
guard times > .none else {
// 17
subscriber?.receive(completion: .finished)
return
}
}

15. This required method receives demands from the subscriber. Demands are
cumulative: They add up to form a total number of values that the subscriber
requested.

16. Your first test is to verify whether you’ve already sent enough values to the
subscriber, as specified in the configuration. That is, if you’ve sent the maximum
number of expected values, independent of the demands your publisher received.

17. If this is the case, you can notify the subscriber that the publisher has finished
sending values.

raywenderlich.com 355
Combine Chapter 18: Custom Publishers & Handling Backpressure

Continue the implementation of this method by adding this code after the guard
statement:

// 18
requested += demand

// 19
if source == nil, requested > .none {

18. Increment the total number of requested values by adding the new demand.

19. Check whether the timer already exists. If not, and if requested values exist, then
it’s time to start it.

Configuring your timer

Add this code to the body of the if conditional:

// 20
let source = DispatchSource.makeTimerSource(queue:
configuration.queue)
// 21
source.schedule(deadline: .now() + configuration.interval,
repeating: configuration.interval,
leeway: configuration.leeway)

20. Create the DispatchSourceTimer from the optional requested queue.

21. Schedule the timer to fire after every configuration.interval seconds.

Once the timer has started, you’ll never stop it, even if you don’t use it to emit events
to the subscriber. It will keep running until the subscriber cancels the subscription —
or you deallocate the subscription.

You’re now ready to code the core of your timer, which emits events to the
subscriber. Still inside the if body, add this code:

// 22
source.setEventHandler { [weak self] in
// 23
guard let self = self,
self.requested > .none else { return }

// 24
self.requested -= .max(1)
self.times -= .max(1)

raywenderlich.com 356
Combine Chapter 18: Custom Publishers & Handling Backpressure

// 25
_ = self.subscriber?.receive(.now())
// 26
if self.times == .none {
self.subscriber?.receive(completion: .finished)
}
}

22. Set the event handler for your timer. This is a simple closure the timer calls
every time it fires. Make sure to keep a weak reference to self or the subscription
will never deallocate.

23. Verify that there are currently requested values — the publisher could be paused
with no current demand, as you’ll see later in this chapter when you learn about
backpressure.

24. Decrement both counters now that you’re going to emit a value.

25. Send a value to the subscriber.

26. If the total number of values to send meets the maximum that the configuration
specifies, you can deem the publisher finished and emit a completion event!

Activating your timer

Now that you’ve configured your source timer, store a reference to it and activate it
by adding this code after setEventHandler:

self.source = source
source.activate()

That was a lot of steps, and it would be easy to inadvertently misplace some code
along the way. This code should have cleared all the errors in the playground. If it
hasn’t, you can double-check your work by reviewing the above steps or by
comparing your code with the finished version of the playground in projects/
Final.playground.

Last step: Add this extension after the entire definition of

DispatchTimerSubscription, to define an operator that makes it easy to chain this
publisher:

extension Publishers {
static func timer(queue: DispatchQueue? = nil,
interval: DispatchTimeInterval,
leeway: DispatchTimeInterval
= .nanoseconds(0),

raywenderlich.com 357
Combine Chapter 18: Custom Publishers & Handling Backpressure

times: Subscribers.Demand = .unlimited)

-> Publishers.DispatchTimer {
return Publishers.DispatchTimer(
configuration: .init(queue: queue,
interval: interval,
leeway: leeway,
times: times)
)
}
}

Testing your timer

You’re now ready to test your new timer!

Most parameters of your new timer operator, except the interval, have a default
value to make it easier to use in common use cases. These defaults create a timer
that never stops, has minimal leeway and don’t specify which queue it wants to emit
values on.

Add this code after the extension to test your timer:

// 27
var logger = TimeLogger(sinceOrigin: true)
// 28
let publisher = Publishers.timer(interval: .seconds(1),
times: .max(6))
// 29
let subscription = publisher.sink { time in
print("Timer emits: \(time)", to: &logger)
}

27. This playground defines a class, TimeLogger, that’s very similar to the one you
learned to create in Chapter 10, “Debugging.” The only difference is this one can
display either the time difference between two consecutive values, or the elapsed
time since the timer was created. Here, you want to display the time since you
started logging.

28. Your timer publisher will fire exactly six times, once every second.

29. Log each value you receive through your TimeLogger.

raywenderlich.com 358
Combine Chapter 18: Custom Publishers & Handling Backpressure

Run the playground and you‘ll see this nice output — or something similar, since the
timing will vary slightly:

+1.02668s: Timer emits: DispatchTime(rawValue: 183177446790083)

+2.02508s: Timer emits: DispatchTime(rawValue: 183178445856469)
+3.02603s: Timer emits: DispatchTime(rawValue: 183179446800230)
+4.02509s: Timer emits: DispatchTime(rawValue: 183180445857620)
+5.02613s: Timer emits: DispatchTime(rawValue: 183181446885030)
+6.02617s: Timer emits: DispatchTime(rawValue: 183182446908654)

There’s a slight offset at setup — and there can also be some added delay coming
from Playgrounds — and then the timer fires every second, six times.

You can also test canceling your timer, for example, after a few seconds. Add this
code to do so:

DispatchQueue.main.asyncAfter(deadline: .now() + 3.5) {

subscription.cancel()
}

Run the playground again. This time, you only see three values. It looks like your
timer works just fine!

Although it’s barely visible in the Combine API, Subscription does the bulk of the
work, as you just discovered.

Enjoy your success. You’ve got another deep dive coming up next!

Publishers transforming values

You’ve made serious progress in building your Combine skills! You can now develop
your own operators, even fairly complex ones. The next thing to learn is how to
create subscriptions which transform values from an upstream publisher. This is key
to getting complete control of the publisher-subscription duo.

In Chapter 9, “Networking,” you learned about how useful sharing a subscription is.
When the underlying publisher is performing significant work, like requesting data
from the network, you want to share the results with multiple subscribers. However,
you want to avoid issuing the same request multiple times to retrieve the same data.

It can also be beneficial to replay the results to future subscribers if you don’t need
to perform the work again.

Why not try and implement shareReplay(), which can do exactly what you need?

raywenderlich.com 359
Combine Chapter 18: Custom Publishers & Handling Backpressure

This will be an interesting task! To write this operator, you’ll create a publisher that
does the following:

• Subscribes to the upstream publisher upon the first subscriber.

• Replays the last N values to each new subscriber.

• Relays the completion event, if one emitted beforehand.

This will be nontrivial to implement, but you’ve definitely got this! You’ll take it step
by step and, by the end, you’ll have a shareReplay() that you can use in your future
Combine-driven projects.

Open the ShareReplay operator page in the playground to get started.

Implementing a ShareReplay operator

To implement shareReplay() you’ll need:

• A type conforming to the Subscription protocol. This is the subscription each

subscriber will receive. To make sure you can cope with each subscriber’s demands
and cancellations, each one will receive a separate subscription.

• A type conforming to the Publisher protocol. You’ll implement it as a class

because all of its subscribers need to share it.

Start by adding this code to create your subscription class:

// 1
fileprivate final class ShareReplaySubscription<Output, Failure:
Error>: Subscription {
// 2
let capacity: Int
// 3
var subscriber: AnySubscriber<Output,Failure>? = nil
// 4
var demand: Subscribers.Demand = .none
// 5
var buffer: [Output]
// 6
var completion: Subscribers.Completion<Failure>? = nil
}

raywenderlich.com 360
Combine Chapter 18: Custom Publishers & Handling Backpressure

From the top:

1. You use a generic class, not a struct, to implement the subscription: Both the
Publisher and the Subscriber need to access and mutate the subscription.

2. The replay buffer’s maximum capacity will be a constant that you set during
initialization.

3. Keeps a reference to the subscriber for the duration of the subscription. Using the
type-erased AnySubscriber saves you from fighting the type system. :]

4. Tracks the accumulated demands the publisher receives from the subscriber so
that you can deliver exactly the requested number of values.

5. Stores pending values in a buffer until they are either delivered to the subscriber
or thrown away.

6. This keeps the potential completion event around, so that it’s ready to deliver to
new subscribers as soon as they begin requesting values.

Note: If you feel that it’s unnecessary to keep the completion event around
when you’ll just deliver it immediately, rest assured that’s not the case. The
subscriber should receive its subscription first, then receive a completion event
— if one was previously emitted — as soon as it is ready to accept values. The
first request(_:) it makes signals this. The publisher doesn’t know when this
request will happen, so it just hands the completion over to the subscription to
deliver it at the right time.

Initializing your subscription

Next, add the initializer to the subscription definition:

init<S>(subscriber: S,
replay: [Output],
capacity: Int,
completion: Subscribers.Completion<Failure>?)
where S: Subscriber,
Failure == S.Failure,
Output == S.Input {
// 7
self.subscriber = AnySubscriber(subscriber)
// 8
self.buffer = replay
self.capacity = capacity

raywenderlich.com 361
Combine Chapter 18: Custom Publishers & Handling Backpressure

self.completion = completion
}

This initializer receives several values from the upstream publisher and sets them on
this subscription instance. Specifically, it:

7. Stores a type-erased version of the subscriber.

8. Stores the upstream publisher’s current buffer, maximum capacity and

completion event, if emitted.

Sending completion events and outstanding

values to the subscriber
You’ll need a method which relays completion events to the subscriber. Add the
following to the subscription class to satisfy that need:

private func complete(with completion:

Subscribers.Completion<Failure>) {
// 9
guard let subscriber = subscriber else { return }
self.subscriber = nil
// 10
self.completion = nil
self.buffer.removeAll()
// 11
subscriber.receive(completion: completion)
}

This private method does the following:

9. Keeps the subscriber around for the duration of the method, but sets it to nil in
the class. This defensive action ensures any call the subscriber may wrongly issue
upon completion will be ignored.

10. Makes sure that completion is sent only once by also setting it to nil, then
empties the buffer.

11. Relays the completion event to the subscriber.

You’ll also need a method that can emit outstanding values to the subscriber. Add
this method to emit values as needed:

private func emitAsNeeded() {

guard let subscriber = subscriber else { return }
// 12

raywenderlich.com 362
Combine Chapter 18: Custom Publishers & Handling Backpressure

while self.demand > .none && !buffer.isEmpty {

// 13
self.demand -= .max(1)
// 14
let nextDemand = subscriber.receive(buffer.removeFirst())
// 15
if nextDemand != .none {
self.demand += nextDemand
}
}
// 16
if let completion = completion {
complete(with: completion)
}
}

First, this method ensures there is a subscriber. If there is, the method will:

12. Emit values only if it has some in the buffer and there’s an outstanding demand.

13. Decrement the outstanding demand by one.

14. Send the first outstanding value to the subscriber and receive a new demand in
return.

15. Add that new demand to the outstanding total demand, but only if it’s not .none.
Otherwise, you’ll get a crash, because Combine doesn’t treat
Subscribers.Demand.none as zero and adding or subtracting .none will trigger
an exception.

16. If a completion event is pending, send it now.

Things are shaping up! Now, implement Subscription’s all-important requirement:

func request(_ demand: Subscribers.Demand) {

if demand != .none {
self.demand += demand
}
emitAsNeeded()
}

That was an easy one. Remember to check for .none to avoid crashes — and to keep
an eye out to see future versions of Combine fix this issue — and then proceed
emitting.

Note: calling emitAsNeeded() even if the demand is .none guarantees that

you properly relay a completion event that has already occurred.

raywenderlich.com 363
Combine Chapter 18: Custom Publishers & Handling Backpressure

Canceling your subscription

Canceling the subscription is even easier. Add this code:

func cancel() {
complete(with: .finished)
}

As with a subscriber, you’ll need to implement both methods that accept values and a
completion event. Start by adding this method to accept values:

func receive(_ input: Output) {

guard subscriber != nil else { return }
// 17
buffer.append(input)
if buffer.count > capacity {
// 18
buffer.removeFirst()
}
// 19
emitAsNeeded()
}

After ensuring there is a subscriber, this method will:

17. Add the value to the outstanding buffer. You could optimize this for most
common cases, such as unlimited demands, but this will do the job perfectly for
now.

18. Make sure not to buffer more values than the requested capacity. You handle this
on a rolling, first-in-first-out basis – as an already-full buffer receives each new
value, the current first value is removed.

19. Deliver the results to the subscriber.

Finishing your subscription

Now, add the following method to accept completion events and your subscription
class will be complete:

func receive(completion: Subscribers.Completion<Failure>) {

guard let subscriber = subscriber else { return }
self.subscriber = nil
self.buffer.removeAll()
subscriber.receive(completion: completion)
}

raywenderlich.com 364
Combine Chapter 18: Custom Publishers & Handling Backpressure

This method removes the subscriber, empties the buffer – because that’s just good
memory management – and sends the completion downstream.

You’re done with the subscription! Isn’t this fun? Now, it’s time to code the
publisher.

Coding your publisher

Publishers are usually value types implemented as struct in the Publishers
namespace. Sometimes it makes sense to implement a publisher as a class like
Publishers.Multicast, which multicast() returns. For this publisher, you need a
class, though this is the exception to the rule – most often, you’ll use a struct.

Start by adding this code to define your publisher class after your subscription:

extension Publishers {
// 20
final class ShareReplay<Upstream: Publisher>: Publisher {
// 21
typealias Output = Upstream.Output
typealias Failure = Upstream.Failure
}
}

20. You want multiple subscribers to be able to share a single instance of this
operator, so you use a class instead of a struct. It’s also generic, with the final
type of the upstream publisher as a parameter.

21. This new publisher doesn’t change the output or failure types of the upstream
publisher – it simply uses the upstream’s types.

Adding the publisher’s required properties

Now, add the properties that your publisher will need to operate to the definition of
ShareReplay:

// 22
private let lock = NSRecursiveLock()
// 23
private let upstream: Upstream
// 24
private let capacity: Int
// 25
private var replay = [Output]()
// 26
private var subscriptions = [ShareReplaySubscription<Output,

raywenderlich.com 365
Combine Chapter 18: Custom Publishers & Handling Backpressure

Failure>]()
// 27
private var completion: Subscribers.Completion<Failure>? = nil

What this code does:

22. Because you’re going to be feeding multiple subscribers at the same time, you’ll
need a lock to guarantee exclusive access to your mutable variables.

23. Keeps a reference to the upstream publisher. You’ll need it at various points in
the subscription lifecycle.

24. You specify the maximum recording capacity of your replay buffer during
initialization.

25. Naturally, you’ll also need storage for the recorded values.

26. You feed multiple subscribers, so you’ll need to keep them around to notify them
of events. Each subscriber gets its value from a dedicated
ShareReplaySubscription — you’re going to code this in a short while.

27. The operator can replay values even after completion, so you need to remember
whether the upstream publisher completed.

Phew! By the look of it, there’s some more code to write! In the end, you’ll see it’s not
that much, but there is housekeeping to do, like using proper locking, so that your
operator will run smoothly under all conditions.

Initializing and relaying values to your

publisher
First, add the necessary initializer:

init(upstream: Upstream, capacity: Int) {

self.upstream = upstream
self.capacity = capacity
}

Nothing fancy here, just storing the upstream and its capacity. Next, you’ll add a
couple of methods to help split the code into smaller chunks.

Add the method that relays incoming values from upstream to subscribers:

private func relay(_ value: Output) {

// 28

raywenderlich.com 366
Combine Chapter 18: Custom Publishers & Handling Backpressure

lock.lock()
defer { lock.unlock() }

// 29
guard completion == nil else { return }

// 30
replay.append(value)
if replay.count > capacity {
replay.removeFirst()
}
// 31
subscriptions.forEach {
_ = $0.receive(value)
}
}

This code does the following:

28. Since multiple subscribers share this publisher, you must protect access to
mutable variables with locks. Using defer here is not strictly needed, but it’s
good practice just in case you later modify the method, add an early return
statement and forget to unlock your lock.

29. Only relays values if the upstream hasn’t completed yet.

30. Adds the value to the rolling buffer and only keeps the latest values of capacity.
These are the ones to replay to new subscribers.

31. Relays the buffered values to each connected subscriber.

Letting your publisher know when it’s done

Second, add this method to handle completion events:

private func complete(_ completion:

Subscribers.Completion<Failure>) {
lock.lock()
defer { lock.unlock() }
// 32
self.completion = completion
// 33
subscriptions.forEach {
_ = $0.receive(completion: completion)
}
}

raywenderlich.com 367
Combine Chapter 18: Custom Publishers & Handling Backpressure

With this code, you’re:

32. Saving the completion event for future subscribers.

33. Relaying it to each connected subscriber.

You are now ready to start coding the receive method that every publisher must
implement. This method will receive a subscriber. Its duty is to create a new
subscription and then hand it over to the subscriber.

Add this code to begin defining this method:

func receive<S: Subscriber>(subscriber: S)

where Failure == S.Failure,
Output == S.Input {
lock.lock()
defer { lock.unlock() }
}

This standard prototype for receive(subscriber:) specifies that the subscriber,

whatever it is, must have Input and Failure types that match the publisher’s
Output and Failure types. Remember this from Chapter 2, “Publishers &
Subscribers?”

Creating your subscription

Next, add this code to the method to create the subscription and hand it over to the
subscriber:

// 34
let subscription = ShareReplaySubscription(
subscriber: subscriber,
replay: replay,
capacity: capacity,
completion: completion)

// 35
subscriptions.append(subscription)
// 36
subscriber.receive(subscription: subscription)

34. The new subscription references the subscriber and receives the current replay
buffer, the capacity, and any outstanding completion event.

35. You keep the subscription around to pass future events to it.

raywenderlich.com 368
Combine Chapter 18: Custom Publishers & Handling Backpressure

36. You send the subscription to the subscriber, which may — either now or later —
start requesting values.

Subscribing to the publisher and handling its

inputs
You are now ready to subscribe to the upstream publisher. You only need to do it
once: When you receive your first subscriber.

Add this code to receive(subscriber:) – note that you are intentionally not
including the closing } because there’s more code to add:

// 37
guard subscriptions.count == 1 else { return }

let sink = AnySubscriber(

// 38
receiveSubscription: { subscription in
subscription.request(.unlimited)
},
// 39
receiveValue: { [weak self] (value: Output) ->
Subscribers.Demand in
self?.relay(value)
return .none
},
// 40
receiveCompletion: { [weak self] in
self?.complete($0)
}
)

With this code you:

37. Subscribe only once to the upstream publisher.

38. Use the handy AnySubscriber class which takes closures, and immediately
request .unlimited values upon subscription to let the publisher run to
completion.

39. Relay values you receive to downstream subscribers.

40. Complete your publisher with the completion event you get from upstream.

raywenderlich.com 369
Combine Chapter 18: Custom Publishers & Handling Backpressure

Note: You could initially request .max(self.capacity) and receive just that,
but remember that Combine is demand-driven! If you don’t request as many
values as the publisher is capable of producing, you may never get a
completion event!

To avoid retain cycles, you only keep a weak reference to self.

You’re nearly done! Now, all you need to do is subscribe AnySubscriber to the
upstream publisher.

Finish off the definition of this method by adding this code:

upstream.subscribe(sink)

Once again, all errors in the playground should be clear now. Remember that you can
double-check your work by comparing it with the finished version of the playground
in projects/final.

Adding a convenience operator

Your publisher is complete! Of course, you’ll want one more thing: A convenience
operator to help chain this new publisher.

Add it as an extension to the Publishers namespace at the end of your playground:

extension Publisher {
func shareReplay(capacity: Int = .max)
-> Publishers.ShareReplay<Self> {
return Publishers.ShareReplay(upstream: self,
capacity: capacity)
}
}

You now have a fully functional shareReplay(capacity:) operator. This was a lot
of code, and now it’s time to try it out!

Testing your subscription

Add this code to the end of your playground to test your new operator:

// 41
var logger = TimeLogger(sinceOrigin: true)
// 42

raywenderlich.com 370
Combine Chapter 18: Custom Publishers & Handling Backpressure

let subject = PassthroughSubject<Int,Never>()

// 43
let publisher = subject.shareReplay(capacity: 2)
// 44
subject.send(0)

Here’s what this code does:

41. Use the handy TimeLogger object defined in this playground.

42. To simulate sending values at different times, you use a subject.

43. Share the subject and replay the last two values only.

44. Send an initial value through the subject. No subscriber has connected to the
shared publisher, so you shouldn’t see any output.

Now, create your first subscription and send some more values:

let subscription1 = publisher.sink(

receiveCompletion: {
print("subscription2 completed: \($0)", to: &logger)
},
receiveValue: {
print("subscription2 received \($0)", to: &logger)
}
)

subject.send(1)
subject.send(2)
subject.send(3)

Next, create a second subscription and send a couple more values and then a
completion event:

let subscription2 = publisher.sink(

receiveCompletion: {
print("subscription2 completed: \($0)", to: &logger)
},
receiveValue: {
print("subscription2 received \($0)", to: &logger)
}
)

subject.send(4)
subject.send(5)
subject.send(completion: .finished)

These two subscriptions display every event they receive, along with the time that’s
elapsed since start.

raywenderlich.com 371
Combine Chapter 18: Custom Publishers & Handling Backpressure

Add one more subscription with a small delay to make sure it occurs after the
publisher has completed:

var subscription3: Cancellable? = nil

DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
print("Subscribing to shareReplay after upstream completed")
subscription3 = publisher.sink(
receiveCompletion: {
print("subscription3 completed: \($0)", to: &logger)
},
receiveValue: {
print("subscription3 received \($0)", to: &logger)
}
)
}

Remember that a subscription terminates when it’s deallocated, so you’ll want to use
a variable to keep the deferred one around. The one-second delay demonstrates how
the publisher replays data in the future. You’re ready to test! Run the playground to
see the following results in the debug console:

+0.02967s: subscription1 received 1

+0.03092s: subscription1 received 2
+0.03189s: subscription1 received 3
+0.03309s: subscription2 received 2
+0.03317s: subscription2 received 3
+0.03371s: subscription1 received 4
+0.03401s: subscription2 received 4
+0.03515s: subscription1 received 5
+0.03548s: subscription2 received 5
+0.03716s: subscription1 completed: finished
+0.03746s: subscription2 completed: finished
Subscribing to shareReplay after upstream completed
+1.12007s: subscription3 received 4
+1.12015s: subscription3 received 5
+1.12057s: subscription3 completed: finished

Your new operator is working beautifully:

• The 0 value never appears in the logs, because it was emitted before the first
subscriber subscribed to the shared publisher.

• Every value propagates to current and future subscribers.

raywenderlich.com 372
Combine Chapter 18: Custom Publishers & Handling Backpressure

• You created subscription2 after three values have passed through the subject, so
it only sees the last two (values 2 and 3)

• You created subscription3 after the subject has completed, but the subscription
still received the last two values that the subject emitted.

• The completion event propagates correctly, even if the subscriber comes after the
shared publisher has completed.

Verifying your subscription

Fantastic! This works exactly as you wanted. Or does it? How can you verify that the
publisher is being subscribed to only once? By using the print(_:) operator, of
course! You can try it by inserting it before shareReplay.

Find this code:

let publisher = subject.shareReplay(capacity: 2)

And change it to:

let publisher = subject

.print("shareReplay")
.shareReplay(capacity: 2)

Run the playground again and it will yield this output:

shareReplay: receive subscription: (PassthroughSubject)

shareReplay: request unlimited
shareReplay: receive value: (1)
+0.03004s: subscription1 received 1
shareReplay: receive value: (2)
+0.03146s: subscription1 received 2
shareReplay: receive value: (3)
+0.03239s: subscription1 received 3
+0.03364s: subscription2 received 2
+0.03374s: subscription2 received 3
shareReplay: receive value: (4)
+0.03439s: subscription1 received 4
+0.03471s: subscription2 received 4
shareReplay: receive value: (5)
+0.03577s: subscription1 received 5
+0.03609s: subscription2 received 5
shareReplay: receive finished
+0.03759s: subscription1 received completion: finished
+0.03788s: subscription2 received completion: finished
Subscribing to shareReplay after upstream completed
+1.11936s: subscription3 received 4

raywenderlich.com 373
Combine Chapter 18: Custom Publishers & Handling Backpressure

+1.11945s: subscription3 received 5

+1.11985s: subscription3 received completion: finished

All the lines beginning with shareReplay are logs showing what happens with the
original subject. Now you are sure that it’s performing the work only once and
sharing the results with all current and future subscribers. Job very well done!

This chapter taught you several techniques to create your own publishers. It’s been
long and complex, as there was quite some code to write. You’re nearly done now, but
there’s one last topic you’ll want to learn about before moving on.

Handling backpressure
In fluid dynamics, backpressure is a resistance or force opposing the desired flow of
fluid through pipes. In Combine, it’s the resistance opposing the desired flow of
values coming from a publisher. But what is this resistance? Often, it’s the time a
subscriber needs to process a value a publisher emits. Some examples are:

• Processing high-frequency data, like input from sensors.

• Performing large file transfers.

• Rendering complex UI upon data update.

• Waiting for user input.

• More generally, processing incoming data that the subscriber can’t keep up with at
the rate it’s coming in.

The publisher-subscriber mechanism offered by Combine is flexible. It is a pull

design, as opposed to a push one. That means that subscribers ask publishers to emit
values and specify how many they want to receive. This request mechanism is
adaptive: The demand updates every time the subscriber receives a new value. This
allows subscribers to deal with backpressure by "closing the tap" when they don’t
want to receive more data, and "opening it" later when they are ready for more.

Note: Remember, you can only adjust demand in an additive way. You can
increase demand each time the subscriber receives a new value, by returning a
new .max(N) or .unlimited. Or you can return .none, which indicates that
the demand should not increase. However, the subscriber is then "on the hook"
to receive values at least up to the new max demand. For example, if the

raywenderlich.com 374
Combine Chapter 18: Custom Publishers & Handling Backpressure

previous max demand was to receive three values and the subscriber has only
received one, returning .none in the subscriber’s receive(_:) will not "close
the tap." The subscriber will still receive at most two values when the
publisher is ready to emit them.

What happens when more values are available is totally up to your design. You can:

• Control the flow by managing demand to prevent the publisher from sending
more values than you can handle.

• Buffer values until you can handle them — with the risk of exhausting available
memory.

• Drop values you can’t handle right away.

• Some combination of the above, according to your requirements.

Going through all possible combinations and implementations could take several
chapters. In addition to the above, dealing with backpressure can take the form of:

• A publisher with a custom Subscription dealing with congestion.

• A subscriber delivering values at the end of a chain of publishers.

In this introduction to backpressure management, you’ll focus on implementing the

latter. You’re going to create a pausable variant of the sink function, which you
already know well.

Using a pausable sink to handle backpressure

To get started, switch to the PausableSink page of the playground.

As a first step, create a protocol that lets you resume from a pause:

protocol Pausable {
var paused: Bool { get }
func resume()
}

You don’t need a pause() method here, since you’ll determine whether or not to
pause when you receive each value. Of course, a more elaborate pausable subscriber
could have a pause() method you can call at any time! For now, you’ll keep the code
as simple and straightforward as possible.

raywenderlich.com 375
Combine Chapter 18: Custom Publishers & Handling Backpressure

Next, add this code to start defining the pausable Subscriber:

// 1
final class PausableSubscriber<Input, Failure: Error>:
Subscriber, Pausable, Cancellable {
// 2
let combineIdentifier = CombineIdentifier()
}

1. Your pausable subscriber is both Pausable and Cancellable. This is the object
your pausableSink function will return. This is also why you implement it as a
class and not as a struct: You don’t want an object to be copied, and you need
mutability at certain points in its lifetime.

2. A subscriber must provide a unique identifier for Combine to manage and

optimize its publisher streams.

Now add these additional properties:

// 3
let receiveValue: (Input) -> Bool
// 4
let receiveCompletion: (Subscribers.Completion<Failure>) -> Void

// 5
private var subscription: Subscription? = nil
// 6
var paused = false

3. The receiveValue closure returns a Bool: true indicates that it may receive
more values and false indicates the subscription should pause.

4. The completion closure will be called upon receiving a completion event from the
publisher.

5. Keep the subscription around so that it can request more values after a pause.
You need to set this property to nil when you don’t need it anymore to avoid a
retain cycle.

6. You expose the paused property as per the Pausable protocol.

Next, add the following code to PausableSubscriber to implement the initializer

and to conform to the Cancellable protocol:

// 7
init(receiveValue: @escaping (Input) -> Bool,
receiveCompletion: @escaping
(Subscribers.Completion<Failure>) -> Void) {

raywenderlich.com 376
Combine Chapter 18: Custom Publishers & Handling Backpressure

self.receiveValue = receiveValue
self.receiveCompletion = receiveCompletion
}

// 8
func cancel() {
subscription?.cancel()
subscription = nil
}

7. The initializer accepts two closures, which the subscriber will call upon receiving
a new value from the publisher and upon completion. The closures are like the
ones you use with the sink function, with one exception: The receiveValue
closure returns a Boolean to indicate whether the receiver is ready to take more
values or whether you need to put the subscriptions on hold.

8. When canceling the subscription, don’t forget to set it to nil afterwards to avoid
retain cycles.

Now add this code to satisfy Subscriber’s requirements:

func receive(subscription: Subscription) {

// 9
self.subscription = subscription
// 10
subscription.request(.max(1))
}

func receive(_ input: Input) -> Subscribers.Demand {

// 11
paused = receiveValue(input) == false
// 12
return paused ? .none : .max(1)
}

func receive(completion: Subscribers.Completion<Failure>) {

// 13
receiveCompletion(completion)
subscription = nil
}

9. Upon receiving the subscription created by the publisher, store it for later so that
you’ll be able to resume from a pause.

10. Immediately request one value. Your subscriber is pausable and you can’t predict
when a pause will be needed. The strategy here is to request values one by one.

11. When receiving a new value, call receiveValue and update the paused status
accordingly.

raywenderlich.com 377
Combine Chapter 18: Custom Publishers & Handling Backpressure

12. If the subscriber is paused, returning .none indicates that you don’t want more
values right now — remember, you initially requested only one. Otherwise,
request one more value to keep the cycle going.

13. Upon receiving a completion event, forward it to receiveCompletion then set

the subscription to nil since you don’t need it anymore.

Finally, implement the rest of Pausable:

func resume() {
guard paused else { return }

paused = false
// 14
subscription?.request(.max(1))
}

14. If the publisher is "paused", request one value to start the cycle again.

Just as you did with previous publishers, you can now expose your new pausable sink
in the Publishers namespace.

Add this code at the end of your playground:

extension Publisher {
// 15
func pausableSink(
receiveCompletion: @escaping
((Subscribers.Completion<Failure>) -> Void),
receiveValue: @escaping ((Output) -> Bool))
-> Pausable & Cancellable {
// 16
let pausable = PausableSubscriber(
receiveValue: receiveValue,
receiveCompletion: receiveCompletion)
self.subscribe(pausable)
// 17
return pausable
}
}

15. Your pausableSink operator is very close to the sink operator. The only
difference is the return type for the receiveValue closure: Bool.

16. Instantiate a new PausableSubscriber and subscribe it to self, the publisher.

17. The subscriber is the object you’ll use to resume and cancel the subscription.

raywenderlich.com 378
Combine Chapter 18: Custom Publishers & Handling Backpressure

Testing your new sink

You can now try your new sink! To make things simple, simulate cases where the
publisher should stop sending values. Add this code:

let subscription = [1, 2, 3, 4, 5, 6]

.publisher
.pausableSink(receiveCompletion: { completion in
print("Pausable subscription completed: \(completion)")
}) { value -> Bool in
print("Receive value: \(value)")
if value % 2 == 1 {
print("Pausing")
return false
}
return true
}

An array’s publisher usually emits all its values sequentially, one right after the
other. Using your pausable sink, this publisher will pause when values 1, 3 and 5 are
received.

Run the playground and you’ll see:

Receive value: 1
Pausing

To resume the publisher, you need to call resume() asynchronously. This is easy to
do with a timer. Add this code to set up a timer:

let timer = Timer.publish(every: 1, on: .main, in: .common)

.autoconnect()
.sink { _ in
guard subscription.paused else { return }
print("Subscription is paused, resuming")
subscription.resume()
}

Run the playground again and you’ll see the pause/resume mechanism in action:

Receive value: 1
Pausing
Subscription is paused, resuming
Receive value: 2
Receive value: 3
Pausing
Subscription is paused, resuming
Receive value: 4

raywenderlich.com 379
Combine Chapter 18: Custom Publishers & Handling Backpressure

Receive value: 5
Pausing
Subscription is paused, resuming
Receive value: 6
Pausable subscription completed: finished

Congratulations! You now have a functional pausable sink and you’ve gotten a
glimpse into handling backpressure in your code!

Note: What if your publisher can’t hold values and wait for the subscriber to
request them? In this situation, you’d want to buffer values using the
buffer(size:prefetch:whenFull:) operator. This operator can buffer
values up to the capacity you indicate in the size parameter and deliver them
when the subscriber is ready to receive them. The other parameters determine
how the buffer fills up – either at once when subscribing, keeping the buffer
full, or upon request from its subscriber – and what happens when the buffer is
full – i.e., drop the last value(s) it received, drop the oldest one(s) or terminate
with an error.

Key points
Wow, this was a long and complex chapter! You learned a lot about publishers:

• A publisher can be a simple method that leverages other publishers for

convenience.

• Writing a custom publisher usually involves creating an accompanying

Subscription.

• The Subscription is the real link between a Subscriber and a Publisher.

• In most cases, the Subscription is the one that does all the work.

• A Subscriber can control the delivery of values by adjusting its Demand.

• The Subscription is responsible for respecting the subscriber’s Demand. Combine

does not enforce it, but you definitely should respect it as a good citizen of the
Combine ecosystem.

raywenderlich.com 380
Combine Chapter 18: Custom Publishers & Handling Backpressure

Where to go from here?

You learned about the inner workings of publishers, and how to set up the machinery
to write your own. Of course, any code you write — and publishers in particular! —
should be thoroughly tested. Move on to the next chapter to learn all about testing
Combine code!

raywenderlich.com 381
19 Chapter 19: Testing
By Scott Gardner

Studies show that there are two reasons why developers skip writing tests:

1. They write bug-free code.

2. Are you still reading this?

If you cannot say with a straight face that you always write bug-free code — and
presuming you answered yes to number two — this chapter is for you. Thanks for
sticking around!

Writing tests is a great way to ensure intended functionality in your app as you are
developing new features and especially after the fact, to ensure your latest work did
not introduce a regression in some previous code that worked fine.

This chapter will introduce you to writing unit tests against your Combine code, and
you’ll have some fun along the way. You’ll write tests against this handy app:

raywenderlich.com 382
Combine Chapter 19: Testing

ColorCalc was developed using Combine and SwiftUI. It’s got some issues though. If
it only had some good unit tests to help find and fix those issues. Good thing you’re
here!

Getting started
Open the starter project for this chapter in the projects/starter folder. This is
designed to give you the red, green, blue, and opacity — aka alpha — values for the
hex color code you enter in. It will also adjust the background color to match the
current hex if possible and give the color’s name if available. If a color cannot be
derived from the currently entered hex value, the background will be set to white
instead. This is what it’s designed to do. But something is rotten in the state of
Denmark — or more like some things.

Fortunately, you’ve got a thorough QA team that takes their time to find and
document issues. It’s your job to streamline the development-QA process by not only
fixing these issues but also writing some tests to verify correct functionality after the
fix.

Run the app and confirm the following issues reported by your QA team:

Issue 1
• Action: Launch the app.

• Expected: The name label should display aqua.

• Actual: The name label displays Optional(ColorCalc.ColorNam....

Issue 2
• Action: Tap the ← button.

• Expected: The last character is removed in the hex display.

• Actual: The last two characters are removed.

Issue 3
• Action: Tap the ← button.

• Expected: The background turns white.

• Actual: The background turns red.

raywenderlich.com 383
Combine Chapter 19: Testing

Issue 4
• Action: Tap the ⊗ button.

• Expected: The hex value display clears to #.

• Actual: The hex value display does not change.

Issue 5
• Action: Enter hex value 006636.

• Expected: The red-green-blue-opacity display shows 0, 102, 54, 255.

• Actual: The red-green-blue-opacity display shows 0, 62, 32, 155.

You’ll get to the work on writing tests and fixing these issues shortly, but first, you’ll
learn about testing Combine code by — wait for it — testing Combine’s actual code!
Specifically, you’ll test a few operators.

Note: The chapter presumes you have some familiarity with unit testing in
iOS. If not, you can still follow along, and everything will work fine. However,
this chapter will not delve into the details of test-driven development — aka
TDD. If you are seeking to gain a more in-depth understanding of this topic,
check out iOS Test-Driven Development by Tutorials from the
raywenderlich.com library at bit.ly/2mhDfMU.

Testing Combine operators

Throughout this chapter, you’ll employ the Given-When-Then pattern to organize
your test logic:

• Given a condition.

• When an action is performed.

• Then an expected result occurs.

Still in the ColorCalc project, open ColorCalcTests/CombineOperatorsTests.swift.

raywenderlich.com 384
Combine Chapter 19: Testing

To start things off, add a subscriptions property to store subscriptions in, and set it
to an empty array in tearDown(). Your code should look like this:

var subscriptions = Set<AnyCancellable>()

override func tearDown() {

subscriptions = []
}

Testing collect()
Your first test will be for the collect operator. Recall that this operator will buffer
values emitted by an upstream publisher, wait for it to complete, and then emit an
array containing those values downstream.

Employing the Given — When — Then pattern, begin a new test method by adding
this code below tearDown():

func test_collect() {
// Given
let values = [0, 1, 2]
let publisher = values.publisher
}

With this code, you create an array of integers, and then a publisher from that array.

Now, add this code to the test:

// When
publisher
.collect()
.sink(receiveValue: {
// Then
XCTAssert(
$0 == values,
"Result was expected to be \(values) but was \($0)"
)
})
.store(in: &subscriptions)

Here, you use the collect operator and then subscribe to the output from it,
asserting that the output equals the values — and store the subscription.

raywenderlich.com 385
Combine Chapter 19: Testing

You can run unit tests in Xcode in several ways:

1. To run a single test, click the diamond next to the method definition.

2. To run all the tests in a single test class, click the diamond next to the class
definition.

3. To run all the tests in all test targets in a project, press Command-U. Keep in
mind that each test target may contain multiple test classes, each potentially
containing multiple tests.

4. You can also use the Product ▸ Perform Action ▸ Run “TestClassName” menu
— which also has its own keyboard shortcut: Command-Control-Option-U.

Run this test by clicking the diamond next to test_collect(). The project will build
and run in the simulator briefly while it executes the test, and then report if it
succeeded or failed.

As expected, the test will pass and you’ll see the following:

The diamond next to the test definition will also turn green and contain a
checkmark.

You can also show the Console via the View ▸ Debug Area ▸ Activate Console
menu item or by pressing Command-Shift-Y to see details about the test results
(results truncated here):

2019-09-01 14:21:10.233061-0500 ColorCalc[25220:2802318]

Launching with XCTest injected. Preparing to run tests.
...
Test Suite 'Selected tests' passed at 2019-09-01 12:34:56.789.
Executed 1 test, with 0 failures (0 unexpected) in 0.001
(0.003) seconds

To verify that this test is working correctly, change the assertion code to:

XCTAssert(
$0 == values + [1],
"Result was expected to be \(values + [1]) but was \($0)"
)

raywenderlich.com 386
Combine Chapter 19: Testing

You added a 1 to the values array being compared to the array emitted by
collect(), and to the interpolated value in the message.

Rerun the test, and you’ll see it fails, along with the message Result was expected
to be [0, 1, 2, 1] but was [0, 1, 2]. You may need to click on the error to
expand and see the full message or show the Console, and the full message will also
print there.

Undo that last set of changes before moving on, and re-run the test to ensure it
passes.

Note: In the interest of time and space, this chapter will focus on writing tests
that test for positive conditions. However, you are encouraged to experiment
by testing for negative results along the way if you’re interested. Just
remember to return the test to the original passing state before continuing.

This was a fairly simple test. The next example will test a more intricate operator.

Testing flatMap(maxPublishers:)
As you learned in Chapter 3, “Transforming Operators,” the flatMap operator can be
used to flatten multiple upstream publishers into a single publisher, and you can
optionally specify the max number of publishers it will receive and flatten.

Add a new test method for flatMap by adding this code:

func test_flatMapWithMax2Publishers() {
// Given
// 1
let intSubject1 = PassthroughSubject<Int, Never>()
let intSubject2 = PassthroughSubject<Int, Never>()
let intSubject3 = PassthroughSubject<Int, Never>()

// 2
let publisher = CurrentValueSubject<PassthroughSubject<Int,
Never>, Never>(intSubject1)

// 3
let expected = [1, 2, 4]
var results = [Int]()

// 4
publisher
.flatMap(maxPublishers: .max(2)) { $0 }
.sink(receiveValue: {

raywenderlich.com 387
Combine Chapter 19: Testing

results.append($0)
})
.store(in: &subscriptions)
}

You start this test by creating:

1. Three instances of a passthrough subject expecting integer values.

2. A current value subject that itself accepts and publishes integer passthrough
subjects, initialized with the first integer subject.

3. Expected results and an array to hold actual results received.

4. A subscription to the publisher, using flatMap with a max of two publishers. In

the handler, you append each value received to the results array.

That takes care of Given. Now add this code to your test to create the action:

// When
// 5
intSubject1.send(1)

// 6
publisher.send(intSubject2)
intSubject2.send(2)

// 7
publisher.send(intSubject3)
intSubject3.send(3)
intSubject2.send(4)

// 8
publisher.send(completion: .finished)

Because the publisher is a current value subject, it will replay the current value to
new subscribers. So with the above code, you continue that publisher’s work and:

5. Send a new value to the first integer publisher.

6. Send the second integer subject through the current value subject and then send
that subject a new value.

7. Repeat the previous step for the third integer subject, except passing it two
values this time.

8. Send a completion event through the current value subject.

raywenderlich.com 388
Combine Chapter 19: Testing

All that’s left to complete this test is to assert these actions will produce the
expected results. Add this code to create this assertion:

// Then
XCTAssert(
results == expected,
"Results expected to be \(expected) but were \(results)"
)

Run the test by clicking the diamond next to its definition and you will see it passes
with flying colors!

If you have previous experience with reactive programming, you may be familiar with
using a test scheduler, which is a virtual time scheduler that gives you granular
control over testing time-based operations.

At the time of this writing, Combine does not include a formal test scheduler. An
open-source test scheduler called Entwine is already available though, and it’s worth
a look if a formal test scheduler is what you seek.

However, given that this book is focused on using Apple’s native Combine framework,
when you want to test Combine code, then you can definitely use the built-in
capabilities of XCTest. This will be demonstrated in your next test.

Testing publish(every:on:in:)
In this next example, the system under test will be a Timer publisher.

As you might remember from Chapter 11, “Timers,” this publisher can be used to
create a repeating timer without a lot of boilerplate setup code. To test this, you will
use XCTest’s expectation APIs to wait for asynchronous operations to complete.

Start a new test by adding this code:

func test_timerPublish() {
// Given
// 1
func normalized(_ ti: TimeInterval) -> TimeInterval {
return Double(round(ti * 10) / 10)
}

// 2
let now = Date().timeIntervalSinceReferenceDate
// 3
let expectation = self.expectation(description: #function)
// 4
let expected = [0.5, 1, 1.5]

raywenderlich.com 389
Combine Chapter 19: Testing

var results = [TimeInterval]()

// 5
let publisher = Timer
.publish(every: 0.5, on: .main, in: .common)
.autoconnect()
.prefix(3)
}

In this setup code, you:

1. Define a helper function to normalize time intervals by rounding to one decimal

place.

2. Store the current time interval.

3. Create an expectation that you will use to wait for an asynchronous operation to
complete.

4. Define the expected results and an array to store actual results.

5. Create a timer publisher that auto-connects, and only take the first three values
it emits. Refer back to Chapter 11, “Timers” for a refresher on the details of this
operator.

Next, add this code to test this publisher:

// When
publisher
.sink(
receiveCompletion: { _ in expectation.fulfill() },
receiveValue: {
results.append(
normalized($0.timeIntervalSinceReferenceDate - now)
)
}
)
.store(in: &subscriptions)

In the subscription handler above, you use the helper function to get a normalized
version of each of the emitted dates’ time intervals and append then to the results
array.

With that done, it’s time to wait for the publisher to do its work and complete and
then do your verification.

raywenderlich.com 390
Combine Chapter 19: Testing

Add this code to do so:

// Then
// 6
waitForExpectations(timeout: 2, handler: nil)

// 7
XCTAssert(
results == expected,
"Results expected to be \(expected) but were \(results)"
)

Here you:

6. Wait for a maximum of 2 seconds.

7. Assert that the actual results are equal to the expected results.

Run the test, and you’ll get another pass — +1 for the Combine team at Apple,
everything here is working as advertised!

Speaking of which, so far you’ve tested operators built-in to Combine. Why not test a
custom operator, such as the one you created in Chapter 18, “Custom Publishers &
Handling Backpressure?”

Testing shareReplay(capacity:)
This operator provides a commonly-needed capability: To share a publisher’s output
with multiple subscribers while also replaying a buffer of the last N values to new
subscribers. This operator takes a capacity parameter that specifies the size of the
rolling buffer. Once again, refer back to Chapter 18, “Custom Publishers & Handling
Backpressure” for additional details about this operator.

You’ll test both the share and replay components of this operator in the next test.
Add this code to get started:

func test_shareReplay() {
// Given
// 1
let subject = PassthroughSubject<Int, Never>()
// 2
let publisher = subject.shareReplay(capacity: 2)
// 3
let expected = [0, 1, 2, 1, 2, 3, 3]
var results = [Int]()
}

raywenderlich.com 391
Combine Chapter 19: Testing

Similar to previous tests, you:

1. Create a subject to send new integer values to.

2. Create a publisher from that subject, using shareReplay with a capacity of two.

3. Define the expected results and, create an array to store the actual output.

Next, add this code to trigger the actions that should produce the expected output:

// When
// 4
publisher
.sink(receiveValue: { results.append($0) })
.store(in: &subscriptions)

// 5
subject.send(0)
subject.send(1)
subject.send(2)

// 6
publisher
.sink(receiveValue: { results.append($0) })
.store(in: &subscriptions)

// 7
subject.send(3)

From the top, you:

4. Create a subscription to the publisher and store any emitted values.

5. Send some values through the subject that the publisher is share-replaying.

6. Create another subscription and also store any emitted values.

7. Send one more value through the subject.

With that done, all that’s left is to make sure this operator is up-to-snuff is create an
assertion. Add this code to wrap up this test:

XCTAssert(
results == expected,
"Results expected to be \(expected) but were \(results)"
)

This is the same assertion code as the previous two tests.

raywenderlich.com 392
Combine Chapter 19: Testing

Run this test and voila, you have a bonafide member worthy of use in your Combine-
driven projects — Thanks Florent!

By learning how to test this small variety of Combine operators, you’ve picked up the
skills necessary to test most anything Combine can throw at you. In the next section,
you’ll put these skills to practice by testing the ColorCalc app you saw earlier.

Testing production code

At the beginning of the chapter, you observed several issues with the ColorCalc app.
It’s now time to do something about it.

The project is organized using the MVVM pattern, and all the logic you’ll need to test
and fix is contained in the app’s only view model: CalculatorViewModel.

Note: Apps can have issues in other areas such as SwiftUI View files, however,
UI testing is not the focus of this chapter. If you find yourself needing to write
unit tests against your UI code, it could be a sign that your code should be
reorganized to separate responsibilities. MVVM is a useful architectural design
pattern for this purpose. If you’d like to learn more about MVVM with
Combine, check out the tutorial MVVM with Combine Tutorial for iOS at
bit.ly/2kgGVxF.

Open ColorCalcTests/ColorCalcTests.swift, and add the following two properties at

the top of the ColorCalcTests class definition:

var viewModel: CalculatorViewModel!

var subscriptions = Set<AnyCancellable>()

You’ll reset both both properties’ values for every test, viewModel right before and
subscriptions right after each test. Change the setUp() and tearDown() methods
to look like this:

override func setUp() {

viewModel = CalculatorViewModel()
}

override func tearDown() {

subscriptions = []
}

raywenderlich.com 393
Combine Chapter 19: Testing

Issue 1: Incorrect name displayed

With that setup code in place, you can now write your first test against the view
model. Add this code:

func test_correctNameReceived() {
// Given
// 1
let expected = "rwGreen 66%"
var result = ""

// 2
viewModel.$name
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
// 3
viewModel.hexText = "006636AA"

// Then
// 4
XCTAssert(
result == expected,
"Name expected to be \(expected) but was \(result)"
)
}

Here’s what you did:

1. Store the expected name label text for this test.

2. Subscribe to the view model’s $name publisher and save the received value.

3. Perform the action that should trigger the expected result.

4. Assert that the actual result equals the expected one.

Run this test, and it will fail with this message: Name expected to be rwGreen
66% but was Optional(ColorCalc.ColorName.rwGreen)66%. Ah, the Optional
bug bites once again!

Open View Models/CalculatorViewModel.swift. At the bottom of the class

definition is a method called configure(). This method is called in the initializer,
and it’s where all the view model’s subscriptions are set up. First, a hexTextShared
publisher is created to, well, share the hexText publisher.

raywenderlich.com 394
Combine Chapter 19: Testing

How’s that for self-documenting code? Right after that is the subscription that sets
name:

hexTextShared
.map {
let name = ColorName(hex: $0)

if name != nil {
return String(describing: name) +
String(describing: Color.opacityString(forHex: $0))
} else {
return "------------"
}
}
.assign(to: \.name, on: self)
.store(in: &subscriptions)

Review that code. Do you see what’s wrong? Instead of just checking that the local
name instance of ColorName is not nil, it should use optional binding to unwrap
non-nil values. Change the entire map block of code to the following:

.map {
if let name = ColorName(hex: $0) {
return "\(name) \(Color.opacityString(forHex: $0))"
} else {
return "------------"
}
}

Now return to ColorCalcTests/ColorCalcTests.swift and rerun

test_correctNameReceived(). It passes!

Instead of fixing and rerunning the project once to verify the fix, you now have a test
that will verify the code works as expected every time you run tests. You’ve helped to
prevent a future regression that could be easy to overlook and make it into
production. Have you ever seen an app in the App Store displaying
Optional(something...)?

Nice job!

raywenderlich.com 395
Combine Chapter 19: Testing

Issue 2: Tapping backspace deletes two

characters
Still in ColorCalcTests.swift, add this new test:

func test_processBackspaceDeletesLastCharacter() {
// Given
// 1
let expected = "#0080F"
var result = ""

// 2
viewModel.$hexText
.dropFirst()
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
// 3
viewModel.process(CalculatorViewModel.Constant.backspace)

// Then
// 4
XCTAssert(
result == expected,
"Hex was expected to be \(expected) but was \(result)"
)
}

Similarly to the previous test, you:

1. Set the expected result and create a variable to store the actual result.

2. Subscribe to viewModel.$hexText and save the value received while dropping

the initially replayed value.

3. Call viewModel.process(_:) passing a constant string that represents the ←

character.

4. Assert the actual and expected results are equal.

Run the test and, as you might expect, it fails. The message this time is Hex was
expected to be #0080F but was #0080.

raywenderlich.com 396
Combine Chapter 19: Testing

Head back to CalculatorViewModel and find the process(_:) method. Check out
the switch case in that method that deals with the backspace:

case Constant.backspace:
if hexText.count > 1 {
hexText.removeLast(2)
}

This must’ve been left behind by some manual testing during development. The fix
couldn’t be more straightforward: Delete the 2 so that removeLast() is only
removing the last character.

Return to ColorCalcTests, rerun

test_processBackspaceDeletesLastCharacter(), and it passes!

Issue 3: Incorrect background color

Writing unit tests can very much be a rinse-and-repeat activity. This next test
follows the same approach as the previous two. Add this new test to
ColorCalcTests:

func test_correctColorReceived() {
// Given
let expected = Color(hex: ColorName.rwGreen.rawValue)!
var result: Color = .clear

viewModel.$color
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
viewModel.hexText = ColorName.rwGreen.rawValue

// Then
XCTAssert(
result == expected,
"Color expected to be \(expected) but was \(result)"
)
}

raywenderlich.com 397
Combine Chapter 19: Testing

You’re testing the view model’s $color publisher this time, expecting the color’s hex
value to be rwGreen when viewModel.hexText is set to rwGreen. This may seem to
be doing nothing at first, but remember that this is testing that the $color publisher
outputs the correct value for the entered hex value.

Run the test, and it passes!

Did you do something wrong? Absolutely not! Writing tests is meant to be proactive
as much if not more reactive. You now have a test that verifies the correct color is
received for the entered hex. So definitely keep that test to be alerted for possible
future regressions.

Back to the drawing board on this issue though. Think about it. What’s causing the
issue? Is it the entered hex value, or is it... wait a minute, it’s that ← button again!

Add this test that verifies the correct color is received when the ← button is tapped:

func test_processBackspaceReceivesCorrectColor() {
// Given
// 1
let expected = Color.white
var result = Color.clear

viewModel.$color
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
// 2
viewModel.process(CalculatorViewModel.Constant.backspace)

// Then
// 3
XCTAssert(
result == expected,
"Hex was expected to be \(expected) but was \(result)"
)
}

From the top, you:

1. Create local values for the expected and actual results, and subscribe to
viewModel.$color, the same as in the previous test.

2. Process a backspace input this time — instead of explicitly setting the hex text as
in the previous test.

3. Verify the results are as expected.

raywenderlich.com 398
Combine Chapter 19: Testing

Run this test and it fails with the rather long message: Hex was expected to be
DisplayP3(red: 0.0, green: 0.4, blue: 0.21176470588235294, opacity:
1.0) but was red. The last word here is the most important one: red. You may
need to open the Console to see the entire message.

Now you’re cooking with gas! Jump back to CalculatorViewModel and check out the
subscription that sets the color in configure():

colorValuesShared
.map { $0 != nil ? Color(values: $0!) : .red }
.assign(to: \.color, on: self)
.store(in: &subscriptions)

Maybe setting the background to red was another quick development-time test that
was never replaced with the intended value? The design calls for the background to
be white when a color cannot be derived from the current hex value. Make it so by
changing the map implementation to:

.map { $0 != nil ? Color(values: $0!) : .white }

Return to ColorCalcTests, run test_processBackspaceReceivesCorrectColor(),

and it passes.

So far your tests have focused on testing positive conditions. Next you’ll implement a
test for a negative condition.

Testing for bad input

The UI for this app will prevent the user from being able to enter bad data for the hex
value.

However, things can change. For example, maybe the hex Text is changed to a
TextField someday to allow for pasting in values. So it would be a good idea to add
a test now to verify the expected results for when bad data is input for the hex value.

Add this test to ColorCalcTests:

func test_whiteColorReceivedForBadData() {
// Given
let expected = Color.white
var result = Color.clear

viewModel.$color
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

raywenderlich.com 399
Combine Chapter 19: Testing

// When
viewModel.hexText = "abc"

// Then
XCTAssert(
result == expected,
"Color expected to be \(expected) but was \(result)"
)
}

This test is almost identical to the previous one. The only difference is, this time, you
pass bad data to hexText.

Run this test, and it will pass. However, if logic is ever added or changed such that
bad data could be input for the hex value, your test will catch this issue before it
makes it into the hands of your users.

There are still two more issues to test and fix. However, you’ve already acquired the
skills to pay the bills here. So you’ll tackle the remaining issues in the challenges
section below.

Before that, go ahead and run all your existing tests by using the Product ▸ Test
menu or press Command-U and bask in the glory: They all pass!

Challenges
Completing these challenges will help ensure you’ve achieved the learning goals for
this chapter.

Challenge 1: Resolve Issue 4: Tapping clear

does not clear hex display
Currently, tapping ⊗ has no effect. It’s supposed to clear the hex display to #. Write a
test that fails because the hex display is not correctly updated, identify and fix the
offending code, and then rerun your test and ensure it passes.

Tip: The constant CalculatorViewModel.Constant.clear can be used for the ⊗

character.

raywenderlich.com 400
Combine Chapter 19: Testing

Solution
This challenge’s solution will look almost identical to the
test_processBackspaceDeletesLastCharacter() test you wrote earlier. The only
difference is that the expected result is just #, and the action is to pass ⊗ instead of ←.
Here’s what this test should look like:

func test_processClearSetsHexToHashtag() {
// Given
let expected = "#"
var result = ""

viewModel.$hexText
.dropFirst()
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
viewModel.process(CalculatorViewModel.Constant.clear)

// Then
XCTAssert(
result == expected,
"Hex was expected to be \(expected) but was \"\(result)\""
)
}

Following the same step-by-step process you’ve done numerous times already in this
chapter, you would:

• Create local values to store the expected and actual results.

• Subscribe to the $hexText publisher.

• Perform the action that should produce the expected result.

• Assert that expected equals actual.

Running this test on the project as it stands will fail with the message Hex was
expected to be # but was "".

Investigating the related code in the view model, you would’ve found the case that
handles the Constant.clear input in process(_:) only had a break in it. Maybe
the developer who wrote this code was itching to take a break?

The fix is to change break to hexText = "#". Then, the test will pass, and you’ll be
guarded against future regressions in this area.

raywenderlich.com 401
Combine Chapter 19: Testing

Challenge 2: Resolve Issue 5: Incorrect red-

green-blue-opacity display for entered hex
Currently, the red-green-blue-opacity (RGBO) display is incorrect after you change
the initial hex displayed on app launch to something else. This can be the sort of
issue that gets a “could not reproduce” response from development because it “works
fine on my device.” Luckily, your QA team provided the explicit instructions that the
display is incorrect after entering in a value such as 006636, which should result in
the RGBO display being set to 0, 102, 54, 170.

So the test you would create that will fail at first would look like this:

func test_correctRGBOTextReceived() {
// Given
let expected = "0, 102, 54, 170"
var result = ""

viewModel.$rgboText
.sink(receiveValue: { result = $0 })
.store(in: &subscriptions)

// When
viewModel.hexText = "#006636AA"

// Then
XCTAssert(
result == expected,
"RGBO text expected to be \(expected) but was \(result)"
)
}

Narrowing down to the cause of this issue, you would find in

CalculatorViewModel.configure() the subscription code that sets the RGBO
display:

colorValuesShared
.map { values -> String in
if let values = values {
return [values.0, values.1, values.2, values.3]
.map { String(describing: Int($0 * 155)) }
.joined(separator: ", ")
} else {
return "---, ---, ---, ---"
}
}
.assign(to: \.rgboText, on: self)
.store(in: &subscriptions)

raywenderlich.com 402
Combine Chapter 19: Testing

This code currently uses the incorrect value to multiply each of the values returned
in the emitted tuple. It should be 255, not 155, because each red, green, blue and
opacity string should represent the underlying value from 0 to 255.

Changing 155 to 255 resolves the issue, and the test will subsequently pass.

Key points
• Unit tests help ensure your code works as expected during initial development and
that regressions are not introduced down the road.

• You should organize your code to separate the business logic you will unit test
from the presentation logic you will UI test. MVVM is a very suitable pattern for
this purpose.

• It helps to organize your test code using a pattern such as Given-When-Then.

• You can use expectations to test time-based asynchronous Combine code.

• It’s important to test both for positive as well as negative conditions.

Where to go from here?

Excellent job! You’ve tackled testing several different Combine operators and
brought law and order to a previously untested and unruly codebase.

One more chapter to go before you cross the finish line. You’ll finish developing a
complete iOS app that draws on what you’ve learned throughout the book, including
this chapter. Go for it!

raywenderlich.com 403
Section V: Building a
Complete App

Mastery takes practice, and practice you shall!

You've made it through this entire book, an amazing feat by all means. It's time to
truly solidify the knowledge you've acquired throughout this chapter and build an
entire app using Combine and SwiftUI.

Specifically, you'll cover:

Chapter 20: In Practice: Building a Complete App: You’ve gained valuable skills
throughout this book, and in the last section you picked up some advanced Combine
know how too. In this final chapter, the pièce de résistance, you’ll build a complete
app that applies what you’ve learned—but the learning is not done yet! Core Data in
Combine anyone?

raywenderlich.com 404
20 Chapter 20: In Practice:
Building a Complete App
By Scott Gardner

By introducing Combine and integrating it throughout their frameworks, Apple has

made it clear: Declarative and reactive programming in Swift is the prevalent way to
develop tomorrow’s greatest apps for their platforms.

In the last three sections, you acquired some awesome Combine skills. In this final
chapter, you’ll utilize what you’ve learned to finish developing an app that lets you
fetch Chuck Norris jokes and translate them into Spanish — or another language of
your choice. And the learning’s not done yet! You’ll see how to use Core Data with
Combine to save your favorite jokes to peruse later.

raywenderlich.com 405
Combine Chapter 20: In Practice: Building a Complete App

Getting started
Open the starter project found in projects/starter. Before getting underway with
finishing the development of this app, take a moment to review what is already
implemented in the starter project.

Note: This project uses SwiftUI. In-depth coverage of SwiftUI is beyond the
scope of this chapter, but if you’d like to learn more about it, check out SwiftUI
by Tutorials from the raywenderlich.com library.

Select the ChuckNorrisJokes project at the top of the Project navigator:

The project has three targets:

1. ChuckNorrisJokes: The main target, which contains all your UI code.

2. ChuckNorrisJokesModel: You’ll define your models and services here.

Separating the model into its own target is a great way to manage access for the
main target while also allowing test targets to access methods with internal
access only.

3. ChuckNorrisJokesTests: You’ll write several unit tests in this target.

In the main target, ChuckNorrisJokes, open ChuckNorrisJokes/Views/

JokeView.swift. This is the main view of the app. There are two previews available
for this view: an iPhone Xs Max in light mode and an iPhone SE in dark mode.

raywenderlich.com 406
Combine Chapter 20: In Practice: Building a Complete App

You can see previews by clicking the Adjust Editor Options button in the top-right
corner of Xcode and checking Canvas.

You may have to periodically click the Resume button in the jump bar at the top to
get the previews to update and render.

Click the Live Preview button next to each preview to get an interactive running
version that’s similar to running the app in the simulator.

raywenderlich.com 407
Combine Chapter 20: In Practice: Building a Complete App

Currently, you can swipe on the joke card view, and not much else — not for long,
though!

Note: At the time of this writing, SwiftUI previews are a mixed bag. They work
for simple layouts but often have trouble with more complex ones. Apple will,
no doubt, improve this in future releases of Xcode, so this chapter suggests
viewing previews. However, if the preview rendering fails, of if you’re still
running macOS Mojave, you can also build and run the app to a simulator to
check out your progress.

Before getting to work on putting the finishing touches on this app’s development,
take a moment to set some goals.

Setting goals
You’ve received several user stories that go like this: As a user, I want to:

1. See indicators when I swipe a joke card all the way to the left or right, to show
that I have disliked or liked a joke.

2. Save liked jokes to peruse later.

3. See the background color of a joke card change to red or green as I swipe toward
the left or right.

4. Fetch a new joke after I dislike or like the current joke.

5. See an indicator when fetching a new joke.

6. Display an indication if something goes wrong when fetching a joke.

7. Toggle between English and Spanish versions of a joke.

8. Pull up a list of saved jokes.

9. Toggle the list of saved jokes between English and Spanish.

10. Delete saved jokes.

raywenderlich.com 408
Combine Chapter 20: In Practice: Building a Complete App

Additionally, your exceptional work ethic — and your manager — won’t allow you to
check in your work without accompanying unit tests. So this chapter’s challenge
section asks you to write unit tests to ensure your logic is sound, and to help prevent
regressions down the road.

These goals are your mission, should you choose to accept it. Can someone say
Mission Possible?! It’s time to get started!

Every one of the above user stories relies on logic, so you’ll need to implement that
logic before you can wire it up to the UI and start checking off that list.

Implementing JokesViewModel
This app will use a single view model to manage the state that drives several UI
components, triggers fetching a joke and its translation and triggers saving a joke.

In the ChuckNorrisJokesModel target, open View Models/JokesViewModel.swift.

You’ll see a bare-bones implementation that includes:

• Imports of Combine and SwiftUI.

• A DecisionState enum.

• A JSONDecoder instance.

• Two AnyCancellable collections.

• An empty initializer and several empty methods.

Time to fill in all those blanks!

Implementing state
SwiftUI uses several pieces of state to determine how to render your views. Add this
code below the line that creates the decoder:

@Published public var fetching: Bool = false

@Published public var joke: Joke = Joke.starter
@Published public var backgroundColor = Color("Gray")
@Published public var decisionState: DecisionState = .undecided
@Published public var showTranslation = false

raywenderlich.com 409
Combine Chapter 20: In Practice: Building a Complete App

Here, you create several @Published properties, synthesizing a publisher for each of
them. You can access the publishers for these properties with the $ prefix — e.g.,
$fetching. Their names and types give you a good indication of their purpose, but
you’ll put them all to use soon enough and see exactly how to utilize them.

Before you can flesh out the rest of this view model, you’ll need to implement a few
more things.

Implementing services
Open Services/JokesService.swift. You’ll use JokesService to fetch a random joke
from the chucknorris.io database. It will also provide a publisher of the data
returned from a fetch.

To be able to mock this service in unit tests later, you’ll need to finish defining a
protocol outlining the publisher’s requirement. Open Protocols/
JokeServiceDataPublisher.swift. Combine is already imported for you here, as it is
in most of the files that need it throughout this chapter.

Change the protocol definition to the following:

public protocol JokeServiceDataPublisher {

func publisher() -> AnyPublisher<Data, URLError>
}

While you’re in the Protocols folder, open TranslationServiceDataPublisher.swift.

Similarly, this protocol defines the requirements of a publisher of translation service
data. Change the protocol definition to:

public protocol TranslationServiceDataPublisher {

func publisher(for joke: Joke, to languageCode: String)
-> AnyPublisher<Data, URLError>
}

This required method takes a joke instance and a language code to translate the joke
to as parameters.

Now return to Services/TranslationService.swift and add this extension to adopt

and conform to TranslationServiceDataPublisher:

extension TranslationService: TranslationServiceDataPublisher {

public func publisher(for joke: Joke, to languageCode: String)
-> AnyPublisher<Data, URLError> {
URLSession.shared.dataTaskPublisher(
for: url(for: joke, languageCode: languageCode)

raywenderlich.com 410
Combine Chapter 20: In Practice: Building a Complete App

)
.map(\.data)
.eraseToAnyPublisher()
}
}

With this code, you:

1. Create a dataTaskPublisher with a URL constructed from the joke and

languageCode parameter values.

2. map to the data property of the data task publisher’s response.

3. Return a type-erased version of the publisher.

Now, open Services/JokesService.swift and, similarly, implement its conformance to

JokeServiceDataPublisher:

extension JokesService: JokeServiceDataPublisher {

public func publisher() -> AnyPublisher<Data, URLError> {
URLSession.shared
.dataTaskPublisher(for: url)
.map(\.data)
.eraseToAnyPublisher()
}
}

If you build your project’s test target at this point, you’ll get two compiler errors.
These errors point to the stubbed implementations of mock services in the test
target. To silence those errors, first open ChuckNorrisJokesTests/Services/
MockJokesService.swift and add this method to MockJokesService:

func publisher() -> AnyPublisher<Data, URLError> {

// 1
let publisher = CurrentValueSubject<Data, URLError>(data)

// 2
if let error = error {
publisher.send(completion: .failure(error))
}

// 3
return publisher.eraseToAnyPublisher()
}

raywenderlich.com 411
Combine Chapter 20: In Practice: Building a Complete App

Then open Services/MockTranslationService.swift and add this method to

MockTranslationService:

func publisher(for joke: Joke, to languageCode: String) ->

AnyPublisher<Data, URLError> {
// 1
let publisher = CurrentValueSubject<Data, URLError>(data)

// 2
if let error = error {
DispatchQueue.global().asyncAfter(deadline: .now() + 0.1) {
publisher.send(completion: .failure(error))
}
}

// 3
return publisher.eraseToAnyPublisher()
}

In both cases:

1. You create a mock publisher that emits Data values and may fail with a
URLError, initialized with the data property of the mocked service.

2. If you provide an error to your mocked service, send it through the subject.

3. You return the type-erased publisher.

You’ll use the delay in sending an error in the mock translation service publisher in a
unit test later in this chapter.

Finish implementing JokesViewModel

With that handiwork done, return to View Models/JokesViewModel.swift and add
the following two properties after the @Published ones:

private let jokesService: JokeServiceDataPublisher

private let translationService: TranslationServiceDataPublisher

The view model uses the default implementations, while unit tests can use mock
versions of these services.

raywenderlich.com 412
Combine Chapter 20: In Practice: Building a Complete App

Update the initializer to use the default implementations and set each service to its
respective property:

public init(jokesService: JokeServiceDataPublisher =

JokesService(),
translationService: TranslationServiceDataPublisher
= TranslationService()) {
self.jokesService = jokesService
self.translationService = translationService
}

Still in the initializer, add a subscription to the $joke publisher:

$joke
.map { _ in false }
.assign(to: \.fetching, on: self)
.store(in: &subscriptions)

You’ll use the fetching published property to indicate when the app is fetching or
translating a joke.

Fetching jokes
Speaking of fetching, change the implementation of fetchJoke() to match this
code:

public func fetchJoke() {

// 1
fetching = true
// 2
jokeSubscriptions = []

// 3
jokesService.publisher()
// 4
.retry(1)
// 5
.decode(type: Joke.self, decoder: Self.decoder)
// 6
.replaceError(with: Joke.error)
// 7
.receive(on: DispatchQueue.main)
// 8
.handleEvents(receiveOutput: { [unowned self] in
self.joke = $0
})
// 9
.filter { $0 != Joke.error }
// 10
.flatMap { [unowned self] joke in

raywenderlich.com 413
Combine Chapter 20: In Practice: Building a Complete App

self.fetchTranslation(for: joke, to: "es")

}
// 11
.receive(on: DispatchQueue.main)
// 12
.assign(to: \.joke, on: self)
.store(in: &jokeSubscriptions)
}

From the top, you:

1. Set fetching to true.

2. Set jokeSubscriptions to an empty collection to cancel all previously-added

subscriptions.

3. Start a subscription to the joke service publisher.

4. Retry the fetch one time if an error occurs.

5. Pass the data received from the publisher to the decode operator

6. Replace an error with a Joke instance that displays an error message.

7. Receive the result on the main queue.

8. Send the joke through the publisher so it can be displayed while the translation is
fetched.

9. If an error did occur, you prevent sending the error joke for translation.

10. Use flatMap to trigger a fetch of the translation. It effectively transforms the
original publisher of untranslated jokes into a new publisher of translated jokes.

11. Receive the result of that publisher on the main queue.

12. Assign the joke received to the publisher, replacing the existing joke with the one
that now also has a translation.

Note: Feel free to change the language code to another language of your
choice. You can review the list of all supported languages and their codes for
the translation service at bit.ly/yandexlanguages. There are currently over 90
languages available from this free service — thanks, Yandex!

raywenderlich.com 414
Combine Chapter 20: In Practice: Building a Complete App

Fetching translations
The fetchTranslation(for:to:) method will work similarly to fetchJoke().
Change the implementation of fetchTranslation(for:to:) to the following:

func fetchTranslation(for joke: Joke, to languageCode: String)

-> AnyPublisher<Joke, Never> {
// 1
guard joke.languageCode != languageCode else {
return Just(joke).eraseToAnyPublisher()
}

// 2
return translationService.publisher(for: joke, to:
languageCode)
.retry(1)
.decode(type: TranslationResponse.self, decoder:
Self.decoder)
// 3
.compactMap { $0.translations.first }
// 4
.map {
Joke(id: joke.id,
value: joke.value,
categories: joke.categories,
languageCode: languageCode,
translationLanguageCode: languageCode,
translatedValue: $0)
}
// 5
.replaceError(with: Joke.error)
.eraseToAnyPublisher()
}

Here’s what you did with this code, step-by-step:

1. The joke’s language code isn’t set until it receives a translation. If the joke’s
languageCode equals the languageCode parameter, it is already translated, so
you just republish it.

2. Begin a subscription to the translationService’s publisher, retrying once and

decoding the output, just as you did with fetchJoke().

3. The translation response sends an array of translations, so get the first one.

4. Create a new joke from the joke passed into the method and the translation
returned from the translation service.

5. If an error occurs, replace it with the error joke and erase to AnyPublisher to
match the method signature.

raywenderlich.com 415
Combine Chapter 20: In Practice: Building a Complete App

How’s that for composition? Combine really shines at building up a series of

operations in a succinct and readable way, doesn’t it?

Nicely done! You’re almost ready to wire this view model up to the UI and give the
app a whirl. But before you do, you have a couple more steps to take. The next one is
changing the joke’s background color.

Changing the background color

The updateBackgroundColorForTranslation(_:) method should update
backgroundColor based on the position of the joke card view — aka, its translation.
Change its implementation to the following to make that work:

public func updateBackgroundColorForTranslation(_ translation:

Double) {
switch translation {
case ...(-0.5):
backgroundColor = Color("Red")
case 0.5...:
backgroundColor = Color("Green")
default:
backgroundColor = Color("Gray")
}
}

Here, you simply switch over the passed in translation and return a red color if it’s
up to -0.5 (-50%), green if it’s 0.5+ (50%+), and gray if it’s in the middle. These
colors are defined in the main target’s asset catalog in Supporting Files, in case you
want to check them out.

You’ll also use the position of the joke card view to determine whether or not the
user liked the joke, so change the implementation of
updateDecisionStateForTranslation(_:andPredictedEndLocationX:inBounds
:) to:

public func updateDecisionStateForTranslation(

_ translation: Double,
andPredictedEndLocationX x: CGFloat,
inBounds bounds: CGRect) {
switch (translation, x) {
case (...(-0.6), ..<0):
decisionState = .disliked
case (0.6..., bounds.width...):
decisionState = .liked
default:
decisionState = .undecided
}
}

raywenderlich.com 416
Combine Chapter 20: In Practice: Building a Complete App

This method’s signature seems more daunting than it actually is. Here, you switch
over the translation and x values. If the percent is -/+ 60%, you consider that a
definitive decision by the user. Otherwise, they’re still undecided.

You use the x and bounds.width values to prevent a decision state change if the user
is hovering inside a decision state area. In other words, if there’s not enough velocity
to predict an end location beyond these values, they haven’t made a decision yet —
however, if there is enough velocity, it’s a good sign that they intend to complete that
decision.

Preparing for the next joke

You have one more method to go. Change reset() to:

public func reset() {

backgroundColor = Color("Gray")
}

When the user likes or dislikes a joke, the joke card will be reset so that it is ready for
the next joke. The only part you need to manually handle is to reset its background
color to gray.

Making the view model observable

There’s one more thing you’ll do in this view model before moving on: Make it
conform to ObservableObject so that it can be observed throughout the app. Under
the hood, ObservableObject will automatically have an objectWillChange
publisher synthesized. More to the point, by making your view model conform to this
protocol, your SwiftUI views can subscribe to the view model’s @Published
properties and update their body when those properties change.

That took a lot more time to explain than it will to implement. Change the class
definition to the following:

public final class JokesViewModel: ObservableObject {

You’ve finished implementing the view model — the brains of this whole operation!

raywenderlich.com 417
Combine Chapter 20: In Practice: Building a Complete App

Note: At this point in a real setting, you’d probably write all your tests against
this view model, ensure everything passes, check in your work, and go to lunch
or home for the day. Instead, you’ll proceed with using the view model you just
implemented to drive the app’s UI. You’ll circle back to writing the unit tests in
the challenge section.

Wiring JokesViewModel up to the UI

There are two View components on the main screen of the app: a JokeView that’s
essentially the background and a floating JokeCardView. Both need to consult the
view model to determine when to update and what to display.

To implement this, start by opening Views/JokeCardView.swift. The

ChuckNorrisJokesModel module is already imported. To get a handle to the view
model, add this property at the top of the JokeCardView definition:

@ObservedObject var viewModel: JokesViewModel

You decorated this property with the @ObservedObject property wrapper. Used in
conjunction with declaring adoption of ObservableObject, you now get the
objectWillChange publisher. You get a compiler error in this file now, because the
preview provider at the bottom is now missing the view model parameter from the
synthesized initializer for JokeCardView.

The error should point you right to it, but if not, locate the JokeCardView()
initializer at the bottom — inside JokeCardView_Previews — and add a default
initialization of the view model. The resulting struct implementation should look
like this:

struct JokeCardView_Previews: PreviewProvider {

static var previews: some View {
JokeCardView(viewModel: JokesViewModel())
.previewLayout(.sizeThatFits)
}
}

raywenderlich.com 418
Combine Chapter 20: In Practice: Building a Complete App

You have a compiler error in JokeView to deal with now, but that’s also an easy fix.

Open Views/JokeView.swift and add the following at the top of the private
properties, above showJokeView:

@ObservedObject private var viewModel = JokesViewModel()

Now, locate the jokeCardView computed property and change the JokeCardView()
initialization to:

JokeCardView(viewModel: viewModel)

The error disappears. Now, switch back to Views/JokeCardView.swift. At the top the
body implementation, locate the code
Text(ChuckNorrisJokesModel.Joke.starter.value) and change it to:

Text(viewModel.showTranslation ? viewModel.joke.translatedValue
: viewModel.joke.value)

With this code, you pivot on the value of the view model’s showTranslation: If
true, display the joke’s translated value; if false, display the non-translated value.

Displaying a required link

Yandex’s free translation service requires that your app prominently displays the
"Powered by Yandex.Translate" link. So you’ll oblige, but you only want to show the
link when you’re displaying a translation. To make that happen, locate the
Button’s .opacity(0) modifier and change it to:

.opacity(viewModel.showTranslation ? 1 : 0)

The opacity will now be 1 when the view model’s showTranslation is true and 0
when it’s false.

Toggling the original and translated joke

The last thing to implement here is LargeInlineButton’s action. Locate action:
{ } and change it to:

action: { self.viewModel.showTranslation.toggle() }

raywenderlich.com 419
Combine Chapter 20: In Practice: Building a Complete App

This toggles the view model’s showTranslation, which in turn causes this view to
re-render.

Setting the joke card’s background color

Now, head back to JokeView.swift. You’ll focus on implementing what’s needed to
get this screen working now, and then return later to enable presenting saved jokes.

Locate the private var jokeCardView property and change

its .background(Color.white) modifier to:

.background(viewModel.backgroundColor)

The view model now determines the joke card view’s background color. As you may
recall, the view model sets the color based on the translation.

Indicating if a joke was liked or disliked

Next, you’ll want to set a visual indication of whether the user liked or disliked a
joke. Find the two uses of HUDView: One displays the .thumbDown image and the
other displays the .rofl image. These image types are defined in HUDView.swift
and correspond to images drawn using Core Graphics.

Change the two usages of the .opacity(0) modifier as follows:

• For HUDView(imageType: .thumbDown):

.opacity(viewModel.decisionState == .disliked ? hudOpacity : 0)

• For HUDView(imageType: .rofl):

.opacity(viewModel.decisionState == .liked ? hudOpacity : 0)

This code lets you display the correct image for the .liked and .disliked states,
and no image when the state is .undecided.

raywenderlich.com 420
Combine Chapter 20: In Practice: Building a Complete App

Handling decision state changes

Now, find updateDecisionStateForChange(_:) and change it to:

private func updateDecisionStateForChange(_ change:

DragGesture.Value) {
viewModel.updateDecisionStateForTranslation(
translation,
andPredictedEndLocationX: change.predictedEndLocation.x,
inBounds: bounds
)
}

This method calls through to the view model’s

updateDecisionStateForTranslation(_:andPredictedEndLocationX:inBounds
:) method, which you implemented earlier. It passes through the values obtained by
the view based on user interaction with the joke card view.

Right below this method, change updateBackgroundColor() to:

private func updateBackgroundColor() {

viewModel.updateBackgroundColorForTranslation(translation)
}

This method also calls through to a method on the view model, passing in the
translation obtained by the view based on user interaction with the joke card view.

Handling when the user lifts their finger

One more method to implement, then you can take the app for a spin.

The handle(_:) method is responsible for handling when the user lifts their finger
— i.e., touches up. If the user touches up while in an .undecided state, it resets the
position of the joke view card. Otherwise, if the user touches up while in a decided
state — .liked or .disliked — it directs the view model to reset and fetch a new
joke.

Change the implementation of handle(_:) to the following:

private func handle(_ change: DragGesture.Value) {

// 1
let decisionState = viewModel.decisionState

switch decisionState {
// 2
case .undecided:

raywenderlich.com 421
Combine Chapter 20: In Practice: Building a Complete App

cardTranslation = .zero
self.viewModel.reset()
default:
// 3
let translation = change.translation
let offset = (decisionState == .liked ? 2 : -2) *
bounds.width
cardTranslation = CGSize(width: translation.width + offset,
height: translation.height)
showJokeView = false

// 4
reset()
}
}

Breaking down what you did with this code:

1. Create a local copy of the view model’s current decisionState and then switch
over it.

2. If the decision state is .undecided, set the cardTranslation back to zero and
tell the view model to reset — which will cause the background color to be reset
to gray.

3. Otherwise, for .liked or .disliked states, determine the new offset and
translation for the joke card view based on the state, and temporarily hide the
joke card view.

4. Call reset(), which hides and then moves the joke card view back to its original
position, tells the view model to fetch a new joke, and then shows the joke card
view.

There are two things you haven’t touched upon yet that this code affects:

• The cardTranslation property tracks the joke card view’s current translation.
Don’t confuse this with the translation property, which uses this value to
calculate a translation based the screen’s current width, then passes the result to
the view model in several areas.

• The joke card view’s initial y offset is -bounds.height. That is, it sits immediately
above the visible view, ready to animate in from the top when showJokeView
changes to true.

raywenderlich.com 422
Combine Chapter 20: In Practice: Building a Complete App

Finally, in the reset() method immediately below handle(_:), add the following
two lines after setting cardTranslation to .zero:

self.viewModel.reset()
self.viewModel.fetchJoke()

Here, you ask the view model to fetch a new joke whenever reset() is called — i.e.,
when a joke is liked or disliked, or when the view appears.

That, my friends, is all you need to do with JokeView for now.

Trying out your app

To check out your progress thus far, show the preview, click Resume if necessary, and
click the Live Preview play button.

Note: You can also build run the app in a simulator or on a device to check
your progress.

You can swipe all the way left or right to dislike or like a joke, respectively. Doing so
will also display the thumb down or ROFL image and the “fetching” animation. If you
release the card while in an undecided state, the joke card will snap back to its
original position. You can also tap Toggle Language to see the translated version of
the joke.

If your app encounters an error, it will display the error joke. You’ll write a unit test
to verify this later, but if you’d like to see the error joke now, temporarily shut off
your Mac’s Wi-Fi, run the app and swipe left to fetch a new joke. You’ll see the error
joke: "Houston we have a problem — no joke. Check your Internet connection and try
again."

This is, no doubt, a minimal implementation. If you’re feeling ambitious, you can
implement a more robust error-handling mechanism, applying what you learned in
Chapter 16, ”Error Handling.“

raywenderlich.com 423
Combine Chapter 20: In Practice: Building a Complete App

Your progress so far

That takes care of the implementation side of these features:

• 1. See indicators when I swipe a joke card all the way to the left or right, to
show that I have disliked or liked a joke.

• 3. See the background color of a joke card change to red or green as I swipe
toward the left or right.

• 4. Fetch a new joke after I dislike or like the current joke.

• 5. See an indicator when a new joke is being fetched.

• 6. Display an indication if something goes wrong when fetching a joke.

• 7. Toggle between English and Spanish versions of a joke.

Nice job! All that’s left is to:

• 2. Save liked jokes to peruse later.

• 8. Pull up a list of saved jokes.

• 9. Toggle the list of saved jokes between English and Spanish.

• 10. Delete saved jokes.

And what else? Write your unit tests of course! You’ll take care of that in the
challenge. For now, it looks like it’s time to save some jokes.

Implementing Core Data with Combine

The Core Data team has been hard at work these past few years. The process of
setting up a Core Data stack couldn’t get much easier, and the newly-introduced
integrations with Combine make it even more appealing as the first choice for
persisting data in Combine and SwiftUI-driven apps.

raywenderlich.com 424
Combine Chapter 20: In Practice: Building a Complete App

Note: This chapter doesn’t delve into the details of using Core Data. It only
walks you through the necessary steps to use it with Combine. If you’d like to
learn more about Core Data, check out Core Data by Tutorials from the
raywenderlich.com library.

Review the data model

The data model has already been created for you. To review it, open Models/
ChuckNorrisJokes.xcdatamodeld and select JokeManagedObject in the ENTITIES
section. You’ll see the following attributes have been defined, along with a unique
constraint on the id attribute:

The languageCode, translatedValue and translatedLanguageCode are optional,

which you can see by selecting each of them in the Attributes section and then
observing that the Optional checkbox is checked in the Data Model Inspector ▸
Attribute section.

Core Data will auto-generate a class definition for JokeManagedObject. Next, you’ll
create a couple of helper methods in extensions on JokeManagedObject and
collections of JokeManagedObject to save and delete jokes.

Extending JokeManagedObject to save jokes

Right-click on the Models folder in the Project navigator for the main target and
select New File.... Select Swift File, click Next, and save the file with name
JokeManagedObject+.swift. Replace the entire body of this file with the following:

// 1
import Foundation
import SwiftUI
import CoreData
import ChuckNorrisJokesModel

raywenderlich.com 425
Combine Chapter 20: In Practice: Building a Complete App

// 2
extension JokeManagedObject {
// 3
static func save(joke: Joke, inViewContext viewContext:
NSManagedObjectContext) {
// 4
guard joke.id != "error" else { return }
// 5
let fetchRequest = NSFetchRequest<NSFetchRequestResult>(
entityName: String(describing: JokeManagedObject.self))
// 6
fetchRequest.predicate = NSPredicate(format: "id = %@",
joke.id)

// 7
if let results = try? viewContext.fetch(fetchRequest),
let existing = results.first as? JokeManagedObject {
existing.value = joke.value
existing.categories = joke.categories as NSArray
existing.languageCode = joke.languageCode
existing.translationLanguageCode =
joke.translationLanguageCode
existing.translatedValue = joke.translatedValue
} else {
// 8
let newJoke = self.init(context: viewContext)
newJoke.id = joke.id
newJoke.value = joke.value
newJoke.categories = joke.categories as NSArray
newJoke.languageCode = joke.languageCode
newJoke.translationLanguageCode =
joke.translationLanguageCode
newJoke.translatedValue = joke.translatedValue
}

// 9
do {
try viewContext.save()
} catch {
fatalError("\(#file), \(#function), \
(error.localizedDescription)")
}
}
}

Walking through the comments, here’s you do with this code:

1. Import Core Data, SwiftUI and your model module.

2. Extend your auto-generated JokeManagedObject class.

raywenderlich.com 426
Combine Chapter 20: In Practice: Building a Complete App

3. Add a static method to save the passed-in joke using the passed-in view context.
If you’re unfamiliar with Core Data, you can think of the view context as Core
Data’s scratchpad. This one’s associated with the main queue.

4. The error joke used to indicate when a problem occurs has the ID error. There’s
no reason to save that joke, so you guard against it being the error joke before
proceeding.

5. Create a fetch request for the JokeManagedObject entity name.

6. Set the fetch request’s predicate to filter the fetch to jokes with the same ID as
the passed-in joke.

7. Use the viewContext to try to execute the fetch request. If it succeeds, that
means the joke already exists, so update it with the values from the passed-in
joke.

8. Otherwise, if the joke does not exist yet, create a new joke with the values from
the passed-in joke.

9. Attempt to save the viewContext.

That takes care of saving.

Extending collections of JokeManagedObject

to delete jokes
To also make deleting easier, add this extension on Collections of
JokeManagedObject:

extension Collection where Element == JokeManagedObject, Index

== Int {
// 1
func delete(at indices: IndexSet, inViewContext viewContext:
NSManagedObjectContext) {
// 2
indices.forEach { index in
viewContext.delete(self[index])
}

// 3
do {
try viewContext.save()
} catch {
fatalError("\(#file), \(#function), \
(error.localizedDescription)")
}

raywenderlich.com 427
Combine Chapter 20: In Practice: Building a Complete App

}
}

In this extension, you:

1. Implement a method to delete objects at the passed-in indices using the passed-
in view context.

2. Iterate over the indices and call delete(_:) on the viewContext, passing each
element of self — i.e., the collection of JokeManagedObjects.

3. Attempt to save the context.

Create the Core Data stack

There are several ways to set up a Core Data stack. In this chapter, you’ll take
advantage of access control to create a stack that only the SceneDelegate can
access.

Open App/SceneDelegate.swift and start by adding these imports at the top:

import Combine
import CoreData

Next, add the CoreDataStack definition at the bottom of the file:

// 1
private enum CoreDataStack {
// 2
static var viewContext: NSManagedObjectContext = {
let container = NSPersistentContainer(name:
"ChuckNorrisJokes")

container.loadPersistentStores { _, error in
guard error == nil else {
fatalError("\(#file), \(#function), \
(error!.localizedDescription)")
}
}

return container.viewContext
}()

// 3
static func save() {
guard viewContext.hasChanges else { return }

do {

raywenderlich.com 428
Combine Chapter 20: In Practice: Building a Complete App

try viewContext.save()
} catch {
fatalError("\(#file), \(#function), \
(error.localizedDescription)")
}
}
}

With this code, you:

1. Define a private enum called CoreDataStack. Using an enum is useful here,

because CoreDataStack only serves as a namespace — you don’t actually want to
be able to instantiate it.

2. Create a persistent container. This is the actual Core Data stack, encapsulating
the managed object model, persistent store coordinator, and managed object
context. Once you have a container, you return its view context. You’ll use
SwiftUI’s Environment API in a moment to share this context across the app.

3. Create a static save method that only the scene delegate can use to save the
context. It’s always a good idea to verify that the context has changed before you
initiate a save operation.

Now that you have defined the Core Data stack, move up to the
scene(_:willConnectTo:options:) method at the top and change let
contentView = JokeView() to:

let contentView = JokeView()

.environment(\.managedObjectContext,
CoreDataStack.viewContext)

Here, you add the Core Data stack’s view context to the environment, making it
globally available.

When the app is about to move to the background, you want to save the
viewContext — otherwise, any work done in it will be lost. Locate the
sceneDidEnterBackground(_:) method and add this code to the bottom of it:

CoreDataStack.save()

You now have a bona fide Core Data stack and can go about the business of putting it
to good use.

raywenderlich.com 429
Combine Chapter 20: In Practice: Building a Complete App

Fetching jokes
Open Views/JokeView.swift and add this code right before the @ObservedObject
private var viewModel property definition to get a handle to the viewContext
from the environment:

@Environment(\.managedObjectContext) private var viewContext

Now, move to handle(_:) and, at the top of the default case, before let
translation = change.translation, add this code:

if decisionState == .liked {
JokeManagedObject.save(joke: viewModel.joke,
inViewContext: viewContext)
}

With this code, you check if the user liked the joke. If so, you use the helper method
you implemented a little while ago to save it, using the view context you retrieved
from the environment.

Showing saved jokes

Next, find the LargeInlineButton block of code in JokeView’s body and change it
to:

LargeInlineButton(title: "Show Saved") {

self.presentSavedJokes = true
}
.padding(20)

Here, you change the state of presentSavedJokes to true. Next, you’ll use this to
present saved jokes — imagine that!

Append the sheet modifier to the end of the NavigationView block of code:

.sheet(isPresented: $presentSavedJokes) {
SavedJokesView()
.environment(\.managedObjectContext, self.viewContext)
}

This code is triggered whenever $presentSavedJokes emits a new value. When it’s
true, the view will instantiate and present the saved jokes view, passing along the
viewContext to it.

raywenderlich.com 430
Combine Chapter 20: In Practice: Building a Complete App

For your reference, the entire NavigationView should now look like this:

NavigationView {
VStack {
Spacer()

LargeInlineButton(title: "Show Saved") {

self.presentSavedJokes = true
}
.padding(20)
}
.navigationBarTitle("Chuck Norris Jokes")
}
.sheet(isPresented: $presentSavedJokes) {
SavedJokesView()
.environment(\.managedObjectContext, self.viewContext)
}

That’s it for JokeView.

Finishing the saved jokes view

Now, you need to finish implementing the saved jokes view, so open Views/
SavedJokesView.swift. The model has already been imported for you.

First, add this property below the showTranslation property:

@Environment(\.managedObjectContext) private var viewContext

You’ve already set the viewContext a couple times — nothing new here.

Next, replace private var jokes = [String]() with the following:

@FetchRequest(
sortDescriptors: [NSSortDescriptor(
keyPath: \JokeManagedObject.value,
ascending: true
)],
animation: .default
) private var jokes: FetchedResults<JokeManagedObject>

You’ll immediately see a compiler error. You’ll fix that next while also enabling the
ability to delete jokes.

raywenderlich.com 431
Combine Chapter 20: In Practice: Building a Complete App

This gem of a property wrapper from SwiftUI does a lot for you. It:

• Takes a sortDescriptors array to sort fetched objects and updates the List that
will display them with the given animation type.

• Automatically performs fetches for you whenever the persistent store changes,
which you can then use to trigger the view to re-render itself with the updated
data.

Variations of the underlying FetchRequest’s initializers allow you to pass a

fetchRequest like the one you created earlier. However, in this case, you want all
jokes, so the only thing you need to pass are instructions on how to sort the results.

Deleting jokes
Locate the ForEach(jokes, id: \.self) block of code, including the .onDelete
block of code, and changing it to the following:

ForEach(jokes, id: \.self) { joke in

// 1
Text(self.showTranslation ? joke.translatedValue ?? "N/A"
: joke.value ?? "N/A")
.lineLimit(nil)
}
.onDelete { indices in
// 2
self.jokes.delete(at: indices,
inViewContext: self.viewContext)
}

Here, you:

1. Pivot on the value of showTranslation to show either the translated or the

original joke text.

2. Enable swiping to delete a joke and call the delete(at:inViewContext:)

method you defined earlier.

With that, SavedJokesView is now done!

Resume the app preview or build and run the app. Save a few jokes, then tap Show
Saved to display your saved jokes. On the save jokes view, tap Toggle Language to
see your jokes in Spanish — or whatever language you chose for translation. Next, try
swiping left on a few jokes to delete them. Re-run the app and confirm that your
saved jokes are, indeed, still there — and the ones you deleted are not!

raywenderlich.com 432
Combine Chapter 20: In Practice: Building a Complete App

Note: At the time of this writing, there’s an issue with Text views presented in
Lists: Sometimes multi-line strings are truncated even when you’ve
appended .lineLimit(nil) to the view. Passing nil should result in there
being no line limit. However, passing an actual value, such as 5, also doesn’t
work correctly. Expect Apple to resolve this in a future release of Xcode.

Challenge
This is the final challenge of the book. Take it on and finish strong!

Challenge: Write unit tests against

JokesViewModel
In the ChuckNorrisJokesTests target, open Tests/JokesViewModelTests.swift.
You’ll see the following:

• Some preliminary setup code.

• A test that verifies the sample joke can be successfully created, called
test_createJokesWithSampleJokeData.

• Seven test stubs, which you’ll complete to exercise each of the responsibilities of
the view model.

The ChuckNorrisJokesModel module has already been imported for you, giving you
access to the view model — aka the system under test.

First, you’ll need to implement a factory method to vend new view models. It should
take parameters to indicate if it should emit an error for "fetching" a joke and if it
should emit a translation error for "fetching" a translation. It should then return a
new view model that uses the mock services you implemented earlier.

For an extra challenge, see if you can implement this yourself first, then check your
work against this implementation:

private func viewModel(

withJokeError jokeError: Bool = false,
withTranslationError translationError: Bool = false)
-> JokesViewModel {
JokesViewModel(
jokesService: mockJokesService(

raywenderlich.com 433
Combine Chapter 20: In Practice: Building a Complete App

withError: jokeError
),
translationService: mockTranslationService(
withError: translationError
)
)
}

With that method in place, you’re ready to go about filling in each test stub. You
don’t need any new knowledge to write these tests — you learned everything you
need to know in the last chapter.

Some tests are fairly straightforward. Others require a slightly more advanced
implementation, such as using an expectation to wait for asynchronous operations
to complete.

Take your time, and good luck — you’ve got this!

When you’re done — or if you get stuck on anything along the way — you can check
your work against the solution in projects/challenge/final. The tests in this solution
demonstrate one approach — i.e., they’re not etched in stone as the only way. The
most important thing is that your tests pass when the system works as it’s supposed
to, and fail when it does not.

Key points
Here are some of the main things you learned in this chapter:

• Combine works cooperatively with SwiftUI, Core Data and other frameworks to
provide a streamlined and unified approach to managing asynchronous
operations.

• Use @ObservedObject in conjunction with @Published to drive SwiftUI views with

Combine publishers.

• Use @FetchRequest to automatically execute a Core Data fetch when the

persistent store has changed, and to drive UI based on the updated data.

raywenderlich.com 434
Combine Chapter 20: In Practice: Building a Complete App

Where to go from here?

Bravo! Finishing a book of this magnitude is no small accomplishment. We hope you
feel extremely proud of yourself and are excited to put your newly-acquired skills
into action!

In software development, the possibilities are endless. Developers who keep their
skills sharp and up-to-date will create tomorrow’s apps that are truly adored by their
users. You are such a developer.

You may already have an app or an idea that you want to use Combine to develop. If
so, there’s no better experience than real-world experience — and no one ever
learned to swim from a book alone. So dive in!

Not ready to jump into your own project with Combine yet? No worries, there are
several ways you can improve the app you developed in this chapter and further hone
your Combine chops — including, but not limited to, these enhancements:

• Add the ability to sort saved jokes.

• Add the ability to search saved jokes.

• Add the ability to select the translation language on the main JokeView screen, to
use the selected language for jokes fetched in the future.

• Add the ability to share a joke via social media, or even with other users.

• Implement a more robust error-management system that provides different

messages based on the various errors a user might receive.

• Implement displaying saved jokes in a different way, such as by using fellow author
Marin Todorov’s open-source CombineDataSources (bit.ly/31hUqg8) to display
them in a collection view.

Additionally, you can visit the forum for this book at bit.ly/combineBookForum if you
have any questions, discover errata, or just want to see if you can help fellow
Combiners.

Whatever you decide to do with your Combine skills, we wish you good luck — and
don’t hesitate to reach out to us to say hello or to share your accomplishments.

raywenderlich.com 435
C Conclusion

You're finally here! Congratulations on completing this book, and we hope you
enjoyed learning about Combine from the book as much as we've enjoyed making it.

In this book, you've learned about how Combine enables you to write apps in a
declarative and expressive way while also making your app reactive to changes as
they occur. This makes your app code much more versatile and easier to reason
about, along with powerful compositional abilities between different pieces of logic
and data.

You started off as a complete Combine beginner, and look at you now; oh, the things
you've been through—operators, networking, debugging, error handling, schedulers,
custom publishers, testing, and you've even worked with SwiftUI.

This is where we part ways, but we have full confidence in you! We hope you'll
continue experimenting with Combine and constantly enhancing your "Combine
muscles." As the saying goes—"practice makes perfect."

And like anything new you learn—don't forget to enjoy the ride.

If you have any questions or comments about the projects in this book, please stop
by our forums at http://forums.raywenderlich.com.

Thank you again for purchasing this book. Your continued support is what makes the
books, tutorials, videos and other things we do at raywenderlich.com possible. We
truly appreciate it!

— Florent, Marin, Sandra, Scott, Shai, Tyler and Vicki

The Combine: Asynchronous Programming with Swift team

raywenderlich.com 436