A Declarative UIKit

Exploring novel UIKit subclasses that offer a more declarative and idiomatic approach to UI design in Swift.

Transcript

1. A Declarative UIKit Exploring novel UIKit subclasses that offer a more declarative and idiomatic approach to UI design in Swift.
2. A Declarative UIKit Exploring novel UIKit subclasses that offer a more declarative and idiomatic approach to UI design in Swift.
3. UIKit Considered Harmful (… could be worse!)
4. UIKit • Derived from AppKit • Written predominantly in Objective-C • Heavy usage of the delegate pattern • Historical baggage (from springs & struts to Auto Layout etc.) • Retroactively fits modern conveniences/APIs • Written before Swift was introduced
5. General Problems • Architecturally limited by language constraints of Objective-C • Forces imperative code • Complexity of “correctness” sharply increasingly • Conflates model and rendering • Spawns monolithic controllers (think multiple delegates)
6. Examples of Retrofitting • attributedText in UILabel • UITableViewAutomaticDimension • Size classes • UILayoutGuide • UIStackView (non-rendering class)
7. UITableView • The bane of a UIKit developer’s life • Driven by highly imperative code • Heavily delegate based • Forces centralized UITableViewCell setup code • Requires considerable setup for to work with Auto Layout • Soul-sucking clusterf***
8. What is declarative code? • A method of abstraction • Code that expresses “what” without going into the “how” • The “how” is left as an implementation detail
9. Benefits • Expressivity • Separation of concerns • Decreased developer cognitive load • Requires developer to distinguish between design and implementation - richer/clearer mental model
10. Making Something Declarative • Describe code in terms of the “what”, not the “how” • Decentralize responsibility across smaller, interchangeable units • Turn business logic into a function of data - generic UI components
11. Writing Declarative Swift • Use protocols to separate the “what” from the “how” • Invert traditionally centralized APIs using protocols to diffuse responsibility • Think in terms of a generic scope, don’t make any assumptions • Make heavy use of generic parameters
12. Reimagining UIKit in Swift • Closures over delegates • Heavily usage of protocol-oriented programming (UILayoutGuide could be a protocol!) • Generic parameters for dependency injection (for e.g. appearance classes etc.) • Value types???
13. Making UITableView Declarative • Take a look at UITableViewDataSource - 11 functions • Create descriptor for UITableViewCell • Create descriptor for UITableView sections • Create descriptor for UITableView • Write UITableView subclass to wrap descriptor
14. Design Choices • Protocols over shims • No attempt at creating a generic UITableViewCell UI descriptor - cell descriptors must still vend a UI subclass • Generic type parameters over type erased protocol existentials • Associated types over simply using Array
15. Why is UIKit so bad? • Mobile devices have evolved • Design has evolved • Applications have become increasingly complex • Apple needs to maintain legacy code/support • Based on AppKit and NeXTSTEP • Written in Objective-C
16. Flutter • Closest to an ideal declarative UI framework • Separation of concerns exemplified (model and rendering completely separate) • Composable widget architecture, conceptually simple • Built with a fresh, modern perspective - does not suffer from historical constraints
17. Thank You @vatsal_manot