Aleksandar Vacić @radiantav at Pragma Conf 2019 SwiftUI for UIKit developers

All new UI framework Powered by Swift 5.1 Declarative layout Single point of truth

— Team Rx, after the WWDC 2019 keynote (also team Redux, React etc)

Meanwhile, at team UIKit : !

! Principles & Patterns ① Layout & Rendering ② Navigation ③ Data flow & management ⑤ UIKit ➜ SwiftUI " Interactions ④

• Class-inheritance based • Declarative and/or imperative layout • Obvious, reachable view hierarchy • MVC, Target-Action, Delegate UIKit principles & patterns UIKit

• Lightweight, composable independent views • Exclusively declarative layout • Black box rendering • Reference data semantics, automatic observers SwiftUI principles & patterns SwiftUI

Layout & Rendering

UIKit UIResponder ⤷ UIViewController → MyVC ⤷ UINC & friends ⤷ UIView → MyView ⤷ UIControl → MyControl ⤷ UILabel ⤷ UITextField

SwiftUI MyView: View Text: View Image: View TextField: View Button: View List: View public protocol View { associatedtype Body : View var body: Self.Body { get } }

UIKit final class GreetingView: UIView { var name: String? { didSet { label.text = name } } private var label: UILabel! override init(frame: CGRect) { super.init(frame: frame) let label = UILabel(frame: frame.inset(by: layoutMargins)) addSubview(label) self.label = label } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } }

SwiftUI struct Greeting: View { var name: String var body: some View { Text(name) } }

(1) What do we lose switching from imperative to declarative? (2)When do you really need this ability to (re)build your subview hierarchy at will, at runtime?

SwiftUI’s declarative approach is the correct approach. #

SwiftUI struct Greeting: View { var name: String var body: some View { Text(name) } }

UIKit final class GreetingView: UIView { var name: String? { didSet { label.text = name } } private var label: UILabel! override init(frame: CGRect) { super.init(frame: frame) let label = UILabel(frame: frame.inset(by: layoutMargins)) addSubview(label) self.label = label } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } }

UIKit final class GreetingView: UIView { var name: String? { didSet { label.text = name } } @IBOutlet private var label: UILabel! }

SwiftUI + Instant Previews are far worse tool than UIKit + Interface Builder for beginners.

UIKit

SwiftUI

SwiftUI

SwiftUI

SwiftUI

SwiftUI

Instant Previews in Xcode 11 truly shine 
 once you already know SwiftUI.

SwiftUI’s main advantage over UIKit is ridiculously simple composing of controls. $

Navigation

UIKit let targetVC = TargetController() show(targetVC, sender: self)

SwiftUI let targetView = TargetView() NavigationLink(destination: targetView) { Text("tap me") }

SwiftUI

SwiftUI

SwiftUI let targetView = TargetView() NavigationLink(destination: targetView) { Text("tap me") }

SwiftUI NavigationLink(destination: TargetView()) { Text("tap me") }

p.s. Coordinator pattern rulez! Navigation is equally horrible in both UIKit and SwiftUI. %

Interactions

SwiftUI Text("Tap me!") .onTapGesture { // do something } Image("some-image") .onLongPressGesture { // do something }

UIKit UIResponder ⤷ UIViewController → MyVC ⤷ UIView → MyView

UIKit UIResponder().next UIView().next = .superview UIViewController().next = .parent ?? .view.superview = upwards pathway through the UI hierarchy

UIKit Responder chain is UIKit’s least used superpower.

No content

UIKit extension UIResponder { var fieldsController: FieldsController? { if let c = self as? FieldsController { return c } if let c = next as? FieldsController { return c } return next?.fieldsController } } github.com/radianttap/Fields

UIKit extension UIResponder { @objc func accountPerformLogout( onQueue queue: OperationQueue? = .main, sender: Any? = nil, callback: @escaping (Error?) -> Void = {_ in} ){ coordinatingResponder?.accountPerformLogout( onQueue: queue, sender: sender, callback: callback) } } github.com/radianttap/Coordinator

SwiftUI var body: some View { NavigationView { List { ... } .listStyle(GroupedListStyle()) .navigationBarTitle("Menu") } }

SwiftUI https://developer.apple.com/videos/play/wwdc2019/216/?time=3160 “And then we can use the navigationBarTitle modifier to produce that large beautiful title for our form. Now this modifier is a little bit special. It provides information that’s able to be interpreted by a NavigationView ancestor. …this is an example of one that flows information upwards using something called preferences.” SwiftUI Essentials

SwiftUI https://swiftui-lab.com/communicating-with-the-view-tree-part-1/

Data Flow & Management

View View View isPlaying: Bool isPlaying: Bool https://developer.apple.com/videos/play/wwdc2019/226 Data Flow through SwiftUI

View View View isPlaying: Bool SwiftUI &isPlaying @State @Binding

View View View isPlaying: Bool isPlaying: Bool

component View View View isPlaying: Bool isPlaying: Bool

control component View View View isPlaying: Bool isPlaying: Bool

control component View View View isPlaying: Bool isPlaying: Bool model

controller control component View View View isPlaying: Bool isPlaying: Bool model UIKit Model View Controller

View View View View View View Model Environment https://developer.apple.com/videos/play/wwdc2019/226 Data Flow through SwiftUI

SwiftUI final class SomeService: ObservableObject {} struct MainView: View { @EnvironmentObject var service: SomeService } class SceneDelegate: UIResponder, UIWindowSceneDelegate { lazy var service = SomeService() func scene(_ scene: UIScene, willConnectTo…) { let mainView = MainView().environmentObject(service) } } &

SwiftUI final class DataManager: ObservableObject { @Published private(set) var events: [Event] = [] } struct EventsList: View { @ObservedObject var dataStore: DataManager private var events: [Event] { return dataStore.events } } '

final class DataManager { private(set) var events: [Event] = [] { didSet { NotificationCenter.default.post( name: NSNotification.Name("DataManagerDidUpdateEventsNotification"), object: self ) } } } final class EventsListController: UIViewController { var events: [Event] = [] { didSet { render() } } override func viewDidLoad() { super.viewDidLoad() render() setupNotificationHandlers() } } private extension EventsListController { func render() {} func setupNotificationHandlers() { NotificationCenter.default.addObserver(forName: NSNotification.Name("DataManagerDidUpdateEventsNotification"), object: [weak self] notification in guard let self = self else { return } guard let dataManager = notification.object as? DataManager else { return } self.events = dataManager.events } } UIKit

SwiftUI final class DataManager: ObservableObject { @Published private(set) var events: [Event] = [] } struct EventsList: View { @ObservedObject var dataStore: DataManager private var events: [Event] { return dataStore.events } }

SwiftUI final class DataManager: ObservableObject { let eventsWillChange = ObservableObjectPublisher() private(set) var events: [Event] = [] { willSet { eventsWillChange.send() } } } struct EventsList: View { @ObservedObject var dataStore: DataManager private var events: [Event] { return dataStore.events } } $

Ok. Where we are, then?

SwiftUI is UI framework where you 独declare layout but do not control the render part 独declare data you need but don’t manage them

When you hit roadblock in UIKit, you have options to work around somehow. Not so in SwiftUI, you must wait for next iOS update.

Today, SwiftUI is a pretty solid ver 0.7
 It’s not ready.

SwiftUI is not the framework you want to build your app on, today.

If you start new projects in next 12 months, I recommend to use UIKit, even for iOS 13.

Don’t fear you’ll be left behind, it’s way too early. No one is an expert, yet.

With hope this was useful — Thank you.

SpeakerDeck.com / radianttap aplus.rs Aleksandar Vacić, radianttap.com @radiantav slides dev blog contact / radianttap open source