> It is necessary to clarify that, to use any **iCloud** location, the user is required to have an actual **iCloud** account and to be logged to that **iCloud** account in the phone.
This application was built as a `SwiftUI` application as the kind of app this assignment defined actually fits the use case to use this young framework, even though `UIKit` has been battle-tested for more than a decade now. The declarative nature of the framework, which is based in describing the behavior of the UI interface, and no by implementing how it should work (like with the imperative approach we were used to), allows the developer for simpler, more maintenable codebases. Of course, the bridge support to native UI framework, like `UIKit` or `AppKit`, is also available for those cases when the developer needs to build tailored UI components and/or more fine-grained control over UI controls. Finally, another advantage worth mentioning, but given the scope of this assignment, is not really relevant is the possibility of porting the app to other platforms, like iPad, Mac, Apple TV, Apple Watch or even Carplay easily, as the framework implementes an encapsulation (or better said, an erasure...) through its APIs of several `UIKit`, `AppKit`, and `WatchKit` components that developer usually need to build their apps.
With choosing the `SwiftUI` framework to build this app, it also comes the question of the type of architecture to use with it. Arguably, my preferred answer to this particular question is **"None"**. Given this framework is highly opinionated (much more opinionated than the view controllers from `UIKit` or `Appkit`), and that it is supported by the power and capabilities that the Swift language itself provides, this framework has lots of extra, helpful features that a SwiftUI `View` can use out of the box (like the `@State`, `@Binding`, `@AppStorage` and `@FetchRequest` property wrappers), I would rather prefer to fully understand how SwiftUI works and use some appropriate, useful design patterns instead. Given my experience, it is preferable to just go with the flow of the technology you use, because the less time spent swimming against the current (or fighting against your framework of choice), the more time developers have to actually solve the problems that actually matter to their apps and, of course, their users.
Now that design patterns have been mentioned, in this exercise some well-known patterns are being used in some degree. For example, the *Singleton* pattern is used to initialise the container in the `DependencyInjection` core library. Both public and internal *Interfaces* that either describe an object or how it should behave are used throughout this codebase, as this pattern is essential to plug the libraries into the modules, and the modules into the actual app and, as a consequence, for testability purposes as developer can easily create mocks, stubs and spies out of them. Then the *Adapter* pattern is used to transform some object into another object like, for example, when transforming some data from a business model instance to a model used exclusively by a UI component or view. Last, but definitely not least, the *Use cases* are a pattern from Android that basically execute a function based on some given input, and provides an output after that particular function is finished. This pattern is particularly useful to encapsulate the logic that a view needs to execute in a simple way, without the need to create view model classes that inherit from the `ObservableObject` class.
This application was built with scalability in terms of the codebase in mind, which tries to address how this codebase could grow in a controllable, organised manner. For this very reason, this application uses the Swift Package Manager (or simply `SPM`) to define the `Cores`, `Libraries` and `Modules` packages. Inside each package, there are targets that encapsulate a some certain functionality or feature with its respective assets inside. Of course, some of these targets also have related test targets that contain test cases with some relevant unit tests. The application takes a bottom-up approach, as the App could use `Cores`, `Libraries` and `Modules` targets but the Modules could use only `Cores` and `Libraries` targets; Libraries could use only `Cores` targets and 3rd party dependencies; and Cores could use only 3rd party dependencies if needed. This approach forces the deveeloper to think about actual separation of concerns, as the different features and dependencies should be grouped as independent, reusable building blocks, and to move the code into the SPM packages out of the main app target, reducing compiling time and overal weight of the application. The only drawback I have encountered with this approach is that the Xcode previews for those views that implemented previews don't work in the current Xcode version.
Of course, this application is not completely done yet and, as mentioned in the assignment text, some more time is definitely required to actually finish the app and polish the code as intended.
Currently, the work that has been left outside of this assignment
- [ ] Better error and connectivity handling;
- [ ] Move duplicated code from Modules to sensible, common Libraries dependencies;
- [ ] Add support for new APIs introduced on iOS 16 (especially for navigation);
- [ ] Improve communication between the public views on the Modules and the core application;
- [ ] Set [Xcode Cloud](https://developer.apple.com/xcode-cloud/) as continuous integration and delivery service to **TestFlight** and to the **App Store**.
