Avi Tsadok - Mastering Swift Package Manager: Build and Test Modular Apps Using Xcode

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/978-1-4842-7048-6. For more detailed information, please visit http://www.apress.com/source-code.

Apress standard

This Apress imprint is published by the registered company APress Media, LLC part of Springer Nature.

The registered company address is: 1 New York Plaza, New York, NY 10004, U.S.A.

Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You dont know where youve been, you dont know where youre going, and you dont know quite where you are.

Danny Thorpe

If you are reading this book, you are probably an iOS developer already. This is not a book for beginners or developers who never touched Xcode in their lives.

And if you did build an app or two, you already worked with frameworks and modules.

In fact, you are using frameworks and libraries every day, even if you are not aware of them.

Foundation, UIKit, Core Data, SwiftUI, StoreKit, and many more are just a few examples of frameworks we use every day.

Apple has over 120 frameworks and libraries in their SDK, and this number is growing with every iOS version released.

Frameworks and libraries are a great way to share and bundle different technologies or services.

Sometimes, when talking about third-party services, its the main and only way to do that.

But frameworks/libraries/modules are not just for Apple to provide us development tools or for companies to share their API with us.

We, as developers, can make use of libraries in our apps and projects.

Separating our apps into modules gives us a different aspect of how projects are built and the internal relationships between them.

Implementing Swift Packages in my projects was a personal revolution I had in my development career.

The technical details on how to do that are not important you can find them in every blog, manual, or Apple developer website.

But instead of looking at my project as an extensive set of classes with unclear relationships, I started to look at it as a group of technologies with clear responsibilities and a defined API.

Each module can be shared, tested, and improved over time.

And for me, it wasnt just a minor change it was a giant leap forward.

My project improved in every level it was more stable, more testable, and even faster.

Its not that Swift Packages have a secret feature that makes your project run better.

The process of creating a Swift Package forces you to take good and healthy steps that eventually improve your projects, such as testing, API design, dependency injection, documentation writing, and many more.

Once I did that, I realized how important it is to modularize my code, be organized, and work with API-driven design.

Building modular apps was always possible in iOS and macOS. We have frameworks and static and dynamic libraries. But in the end, the key is how you manage your dependencies efficiently.

Over the years, Apple focused on driving the MVC pattern forward.

But in the last 23 years, things have changed, and we can see the new direction Apple is taking us:

SwiftUI SwiftUI is Apples declarative framework for building user interfaces, based on some Swift language features and ideas taken from other declarative frameworks such as React and Flutter.

With SwiftUI, Apple is, in fact, dumping MVC. So, what is the new design pattern that were using here? We dont have a controller, but we know we have a view and a model. The view is binding to the model through an observable object which acts as a view model. As a result, we can say that the classic SwiftUI implementation is much like MVVM.

Whats also interesting is that SwiftUI is how Apple wants us to build in all of its platforms, not only iOS.

For Apple, SwiftUI is the future.

Swift Package Manager When Apple introduced Swift Package Manager, we could create a new Swift Package using the command line only. But starting Xcode 11, creating a new Swift Package is built into Xcode, including dependency configuration. We see further improvements in Xcode 12 that allow us to add resources and files to a package and make it much more powerful, almost like a complete framework.

We can conclude that Apple sees Swift Packages as the basic logic unit of all of our apps.

Combine