Open ShezHsky opened 1 year ago
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.
Views to migrate:
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:
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.