A Declarative UIKit

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