Migration to SwiftUI

[ShezHsky]

Aim to improve the overall architecture of the app (with respect to modern Cocoa development) with the side benefit of making it easier to understand through simplification of layers.

Rather than do a full rewrite (and risk losing time for next year/introducing a slew of bugs) we should do this in stages:

• Port existing views to use SwiftUI, each view consuming a view model dependency. Implementations of the dependency bridge into the existing model. Leave the existing routing tier as it is, with component factories returning UIHostingController objects wrapping the SwiftUI views.
• Drop abstraction layers in model around objects and expose new NSManagedObject subclasses for entities. The model package will continue to own how we create, update and fetch them. Gradually move more behaviour into these objects (as with the current model refactor).
• When our minimum OS dependency hits iOS 15, directly read objects into views using SectionFetchRequest and drop the view models.

All the satellite app services that use the model but do not have a visual presence in the app - e.g. notification scheduling - can continue to be driven with tests using the model. These consumers of the model can act as a sanity check for the APIs as we mov things around.

[ShezHsky]

An alternative to the above is flipping the order slightly - start with introducing a new model layer and develop out the views that way (as a dual-running model using a debug setting), then bin off the old implementation following that. Most views will be pretty trivial to re-implement in SwiftUI, with the exception of News with it's compositional entity types and the login view as it involves a round trip.

[ShezHsky]

Views to migrate:

• News
• Messages
• Message
• Login
• Schedule
• Event
• Event Feedback
• Dealers
• Dealer
• Information
• Info Group
• Info Detail
• Maps
• Map
• Collect-them-all
• Additional services
• Settings/App Icon Picker