HarvardArt displays art pieces from the Harvard Art Museum API. It's a multi-platform project so you can download and build and run the app locally for any supported device (iOS, macOS). The project uses environment variables for the API key; more information on the Harvard Art Museum API key can be found here.
The an app built in SwiftUI to demonstrate CAP (Composable Architecture Pattern) (To understand more details of CAP, please visit the repository).
The idea is for the app to be super composable, follow generally accepted programming guidelines (such as separation of concerns, etc), and be super fast and responsive - hopefully that is quickly noticable. Although an overall basic application, it highlights how you can scale a SwiftUI appliation without having to depend or use any library or framework. The CAP package does include a very lightweight library that is designed to be more protocol driven rather than object driven. This allows you as the developer to customize and dictate how the implementation is actually done.
| Split View | List |
|---|---|
 |
 |
| Split View | List |
|---|---|
 |
 |
Every app should have a control system. For this app, the main control system is Application. This class provides the main view. All initial setup can be found in HarvardArtMuseumsApp's -init.
To ensure separation of concerns, this app uses a protocol approach for views where data sources are needed and all the views are correlated to an enum that acts as the holder for the feature and functionality. All features have Actions that dictate all actions supported for the feature (there can be multiple actions for a feature/view. I chose a single actions enum for simplicity). This ensures that any of the views used can be tested thoroughly (because all user based "main" actions flow through the closure1) but also makes the view very reusable.
You may notice that the main objects that display and control functionality inherit from a protocol called ViewCoordinator. This borrows from some terminology Apple has used since early on in SwiftUI when you needed a "Coordinatorfor advanced functionality inUIViewRepresentables or NSViewRepresentable`s. The view coordinator's main function is to...well, coordinate. It should coordinate between the model, view, and any networking or other additional functionality the view/you may need. This protocol is part of CAP.
All networking occurs through actors conforming to Server that use ServerAPIs for knowing how to communicate to backend servers (both protocols provided by CAP).
#Footnotes 1: It may be best for some user actions to be handled in the view, such as sorting, filtering, etc, while other, more important actions, to be handled in the action handler closure. Again, the point is testability and reusability.