SwiftUI Performance for Demanding Apps

Talk given at SwiftLeeds, UK, 2023

SwiftUI is powerful and flexible, but sometimes confusing. Things like modifiers order, inline views, `body` complexity, and POD views, can all seriously affect our performance. In this talk, we will learn the best ways to use SwiftUI for resource-heavy and dynamic UIs, while maintaining the golden 60fps.

In 2022, we (Adobe Bēhance) rebuilt our navigation infra, and our main Feed, in SwiftUI. We also insisted the app must run great on the worst phone we support - iPhone 6S Plus. Getting there was a journey.

We will start by comparing SwiftUI to UIKit: We know there’s no more View Controller, and views are mere “function of their state”, but what does it mean?

Next, we will dive into specific scenarios and see how this new way of thinking is critical for achieving great performance. We will learn things like:
- Avoiding redundant view diffing.
- Controlling view update lifecycle.
- How to “hide” complex state to improve performance.
- Avoiding SwiftUI’s pitfalls, like nested publishers and environment memory leaks.
- And more…

Transcript

1. Aviel Gross | 2022 SwiftUI Perf for Demanding Apps EVERY-VIEW EVERYWHERE ALL AT ONCE 1 / 2023 @avielgr __aviel aviel@mastodon.social
2. Luc Bern rdi - D t Flow Through SwiftUI, WWDC19 “Views, as a function of state” 3
4. What Does It Mean? 6
5. How can this help us write UI code quickly? 7
7. from Imperative to Declarative The journey ! 9
9. Good ol’ UIKit 11
10. UIView Controller View " Delegate Delegate Delegate State State State View UIView " Delegate Delegate Delegate State State State Long lived Passing events 12
11. UIKit UIKit UIViewController Coordinates everything Long lived References are kept (for performance, navigation, etc.) Views & VCs own their state Know their layout size Do event passing 13
12. New Hotness: Swi UI 14
13. State State State View View View View View View View View View " No delegates No View Controller 15
14. SwiftUI UIKit SwiftUI UIViewController Coordinates everything Doesn’t exist! Long lived Short lived views (recreated by the OS many times) References are kept (for performance, navigation, etc.) References make no sense (even if it wasn’t a struct!) Views & VCs own their state View does not own state (not even @State!) Know their size Control their size Do event passing No events, just state mutations (usually) 16
15. why tho 17
20. The Declarative Approach • We change state, not views • ❌ someLabel.text = “Sent” • ✅ sent = true • Views subscribe to, or depend on, state • ✅ @Binding var sent: Bool 22
21. How Does That Work? 23
23. New state or dependencies 25
24. Current View What’s On Screen equal? body body equal? Step A: Step B: *simpli ed, ignores some things (more on this later…) New State & Deps 26
25. Current View What’s On Screen *simpli ed, and ignores some things (more a er the break…) equal? Step A: Yes: 27 %
26. New State & Deps Current View What’s On Screen equal? body body equal? Step A: Step B: *simpli ed, and ignores some things (more a er the break…) No: 28
27. Current View What’s On Screen *simpli ed, and ignores some things (more a er the break…) Yes: body body equal? Step B: 29 %
28. New State & Deps *simpli ed, and ignores some things (more a er the break…) No: body body equal? Step B: Curr View Rendered On Screen 30 %
29. /// Step A: Structure of State & Dependencies func stateAndDependencies() -> Any... /// Step B: Create Body func body(_ state: ...) -> some Thing 31 Imagine View is a function:
30. Where Does Business Logic Go? 32
31. Where Does Business Logic Go? To Nowhere!* *well obviously somewhere - but not in the view… 33
32. • View Controllers usually have 2 kinds of logic: 1. Pass events / changes between views. 2. Handle / serve data (CRUD - Create, Read, Update, Delete) 34
33. • View Controllers usually have 2 kinds of logic: 1. Pass events / changes between views. 2. Handle / serve data (CRUD - Create, Read, Update, Delete) SwiftUI #1 is redundant #2 shouldn’t ever lived in the VC, now forced to live somewhere else 35
34. FeedProvider @StateObject CurrentUser @Environment(\.user) Network Cache CoreData NavigationRouter @EnvironmentObject UserDefaults SwiftUI Views 36
35. Performance 37
36. 1. Less Di ng 2. Fast Di ng 3. Expected Behavior 38
37. 1. Less Di ng 2. Fast Di ng 3. Expected Behavior Fast Di ng Less Di ng Behavior 39
38. SomeView body Keep View body Simple Content Content Fast Di ng Avoid Prefer data SomeView body 40
39. Keep View body Simple struct CupcakeView: View { @State var cupcakes: [Item] var body: some View { let sortedItems = complexSort(cupcakes) List(sortedItems) { ... } } Fast Di ng Avoid 41
40. Keep View body Simple class CupcakesProvider: ObservableObject { @Published var cupcakes: [Item] func provideItemsSomehow() async { let items = await fetchItems() let sortedItems = complexSort(items) self.cupcakes = sortedItems } } Fast Di ng Prefer 42
41. Keep View body Simple class CupcakesProvider: ObservableObject { @Published var cupcakes: [Item] func provideItemsSomehow() async { … } } struct CupcakeView: View { @StateObject var provider = CupcakesProvider() var body: some View { List(provider.cupcakes) { ... .task { provider.provideItemsSomehow() } } } Fast Di ng Prefer 43
42. Keep View body Simple @Observable class CupcakesProvider { var cupcakes: [Item] func provideItemsSomehow() async { … } } struct CupcakeView: View { @State var provider = CupcakesProvider() var body: some View { List(provider.cupcakes) { ... .task { provider.provideItemsSomehow() } } } Fast Di ng Prefer 44
43. HStack { if gotCupcake { CupcakeView() } // ... } HStack Optional // … Prefer “No Effect” Modi iers over Conditional Views CupcakeView Behavior Fast Di ng Avoid 45
44. HStack { if gotCupcake { CupcakeView() } else { CupcakeView() .opacity(0.5) } // ... } HStack ConditionalContent // … CupcakeView Opacity Modi ier CupcakeView Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng Avoid 46
45. HStack { CupcakeView() .opacity(gotCupcake ? 1 : 0) // ... } HStack Opacity Modi ier // … CupcakeView Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng Prefer 47
46. HStack { CupcakeView() .opacity(gotCupcake ? 1 : 0) // ... } HStack Opacity Modi ier // … CupcakeView Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng WWDC21 Demystify Swi!Ul 48
47. Behavior Fast Di ng “When you introduce a branch, pause for a second and consider whether you're representing multiple views or two states of the same view.” - Raj Ramamurthy / WWDC21 49
48. Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng 50 List { ForEach(items) { item in if !item.isEmpty { Text(item) } } } Optional Text View Size Avoid Size 0-1
49. Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng 51 List { ForEach(items) { item in Text(item) .opacity(item.isEmpty ? 0 : 1) } } View Size Opacity Modi ier Text Size 1 Note: Empty items will get a row too!
50. Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng 52 List { ForEach(items.filter(\.isNotEmpty)) { item in Text(item) } } Text View Size Prefer Size 1
51. Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng 53 List { ForEach(filteredItems) { item in Text(item) } } Text View Size Prefer Size 1
52. Prefer “No Effect” Modi iers over Conditional Views Behavior Fast Di ng 54 List { ForEach(filteredItems) { item in Text(item) } } Text View Size WWDC23 Demystify Swi!Ul performance Rens Breur rensbr.eu/blog/swi!ui-diffing
53. Fast Di ng Split State Into Custom View Types Less Di ng var body: some View { } struct BigView: View { @State private var @StateObject private var let Avoid 55
54. Fast Di ng Split State Into Custom View Types Less Di ng Avoid 56 (lldb) po print(type(of: body)) TupleView<(ModifiedContent<HStack<TupleView<(_ConditionalContent<Text, Button<Text>>, Image)>>, _BackgroundStyleModifier<Color>>, VStack<TupleView<(Text, ModifiedContent<Text, _PaddingLayout>)>>, ModifiedContent<List<Never, Section<EmptyView, ForEach<ClosedRange<Int>, Int, ModifiedContent<Text, _OverlayModifier<_ShapeView<Rectangle, Color>>>>, EmptyView>>, _PaddingLayout>)>
55. Fast Di ng Split State Into Custom View Types Less Di ng var body: some View { foo bar biz } var foo: some View { } var bar: some View { } var biz: some View { } Avoid 57
56. struct BarView: View { } struct BizView: View { } struct FooView: View { } Fast Di ng Split State Into Custom View Types Less Di ng var body: some View { FooView( ) BarView( ) BizView( ) } Prefer 58
57. Fast Di ng Split State Into Custom View Types Less Di ng 59 (lldb) po print(type(of: body)) TupleView<(FooView, BarView, BizView)> Prefer
58. Fast Di ng Utilize POD* or Equality Less Di ng *Pl in Ol’ D t & Spicy section warning! Disclaimers: 1. None of this is part of the o cial SwiftUI API 2. Underscore functions should not be used in production 3. Any of this might change in the future 4. I am not a tax advisor and this is not tax advice 60
59. Fast Di ng Utilize POD* or Equality Less Di ng Speed memcmp ' Equality (“==“) (if implemented…) ( Re lection ) *Pl in Ol’ D t 61
60. Fast Di ng Utilize POD* or Equality Less Di ng POD Non-POD struct CupcakeCard: View { let imagePath: String let price: Int let id: String // ... struct CupcakesList: View { @State var data = CakeProvider() @Binding var user: UserInfo @Environment(\.network) var api // ... Check: _isPOD(CupcakesView.self) *Pl in Ol’ D t 62
61. Non-POD View always uses re ection unless it’s Equatable ) ( Fast Di ng Utilize POD* or Equality Less Di ng *Pl in Ol’ D t 63 POD View always uses memcmp unless wrapped in EquatableView ' (
62. Fast Di ng Utilize POD* or Equality Less Di ng *Pl in Ol’ D t Is POD? Equatable? == Re lection Wrapped In EquatableView? memcmp Equatable? No No No No Yes Yes Yes Yes ( ) ' 64
63. Fast Di ng Utilize POD or Equality Less Di ng As-is (not in EquatableView) inside EquatableView memcmp ' ✔ Equality (“==“) ( Ignored ✔ Re lection ) Never POD View POD View always uses memcmp unless wrapped in EquatableView 65
64. Fast Di ng Utilize POD or Equality Less Di ng As-is (not in EquatableView) inside EquatableView memcmp ' Never Equality (“==“) ( ✔ ✔ (redundant) Re lection ) ✔ Non-POD View Non-POD View always uses re ection unless it’s Equatable 66
65. Fast Di ng Utilize POD* or Equality Less Di ng Confused? So are we! Here’s another perspective: Equatable lets you avoid re ection EquatableView lets you force == *Pl in Ol’ D t 67
66. What Can We Do About It? 68
67. split “Dependencies” from “State” 69
68. Image this scenario… 70
69. Fast Di ng Utilize POD* or Equality Less Di ng *Pl in Ol’ D t struct ExpensiveView: View { let value: Int /// <- dependencies @State private var model = Model() /// <- state var body: some View { ... } } Non-POD 71
70. Fast Di ng Utilize POD* or Equality Less Di ng *Pl in Ol’ D t struct ExpensiveView: View { let value: Int /// <- dependencies var body: some View { ExpensiveViewInternal(value: value) } } private struct ExpensiveViewInternal: View { let value: Int @State private var model = Model() /// <- state var body: some View { ... } } Non-POD POD 72
71. 1. Keep View body Simple 2. “No Effect” Modi iers > Conditional Views 3. Split State Into Custom View Types 4. Utilize POD or Equality In Summary ✍ 73
72. Great Swi UI 74
73. Great SwiftUI • , Behavior • - Structure • . Performance 75
74. , Behavior • Code correctness: • Make the code do what you want it to do… • …or what you think it should be doing. 76
75. - Structure • Code layout: • Where logic goes… • How to build the body… • Make your code: • Flexible to change • Easy to reason about • Easy to delete 77
76. . Performance • Compile fast • Run fast • Increase stability 78
77. Great SwiftUI Guide / 0 1 79
78. 80 SwiftUI.wtf
79. Questions! 2 What’s memcmp Why POD Views exist 81 @avielgr __aviel aviel@mastodon.social
80. Thank You! 3 82 @avielgr __aviel aviel@mastodon.social