Swift Composable App Example

1️⃣ Adjust color	2️⃣ Select shape	3️⃣ Preview result

📝 Description

This repository contains an example iOS app built with module composition in mind. It shows how to organize source code into separate modules, where each of them is responsible for providing different functionality in the app.

Instead of splitting the code into separate Xcode's targets that produce frameworks, this project uses Swift Package Manager support in Xcode. There is a single iOS application target in the Xcode project (with corresponding unit tests target) and several Swift packages for each corresponding app feature. Some of the advantages of this setup are:

👍 Easier to maintain project structure. Swift packages do not contain massive configuration in the form of .pbxproj file. The disk's file structure is what you work on in Xcode, and it stays in sync with it. Files are sorted alphabetically. Every folder on the disk automatically becomes a group in Xcode.

👍 Better cooperation in a team. Because there are no entries in .pbxproj for every newly added or moved file, you can avoid hard to resolve conflicts in a version control system.

👍 Easier code reusability. You can easily extract the package and use it in another project. Everything you need is to copy the package directory from one project to another.

👍 Easier to manage dependencies (as long as you use Swift Package Manager). All the libraries your code depends on are defined in Package.swift file. Linking between your libraries is also easy and defined in the same file. The only thing you have to do in Xcode is embedding all your package libraries in the app target.

👍 Easier module separation. It's straightforward to create a new module and extract a piece of your source code to it. You can focus on the app architecture and save the time you would spend creating and configuring Xcode targets. As a result, you can achieve better composition and separation in your codebase.

🛠 Tech Stack

• Xcode 12.4
• Swift 5.3

🧰 Frameworks

• SwiftUI
• ComposableArchitecture
• SnapshotTesting

🚀 Quick start

Open ComposableApp.xcodeproj in Xcode. You can run the app using the ComposableApp build scheme. Other schemes are for building and testing individual modules of the project.

🏛 Architecture

The following diagram explains how the project is structured:

+---------------+               +--------------+       +---------------+
|      App      +<--------------+    Common    +<--+---+   Library A   |
+----+-----+----+               +---+---+---+--+   |   +---------------+
     ^     ^                        |   |   |      |
     |     |    +---------------+   |   |   |      |   +---------------+
     |     +----+   Feature A   +<--+   |   |      +---+   Library B   |
     |          +---------------+       |   |      |   +---------------+
     |                                  |   |      |
     |          +---------------+       |   |      |   +---------------+
     +----------+   Feature B   +<------+   |      +---+   Library C   |
                +---------------+           |          +---------------+
                       ^                    |    
                       |                    |
                +---------------+           |
                +   Feature C   +<----------+
                +---------------+

• App - The application module
• Feature - Feature-specific module
• Common - A module containing shared logic and linking external dependencies
• Library - External dependency
• A ← B - Module A depends on module B

For easy module separation this project uses ComposableArchitecture library by Point-Free.

🎯 Xcode project

All Swift package libraries are embedded in the App target. The only exception is the Testing library used by unit test targets only and not embedded in the app.

📦 Common package

Every other Swift package library in the project depends on the Common library. The purpose of this library is to contain source code that can be shared across the whole codebase and to link external libraries. It's a single place where external dependencies are defined.

📦 Tabs package

Tabs library depends on Color, Shape and Preview libraries, which contain screens presented in the tabbed user interface. It also binds the logic of these screens and handles communication between them.

📦 Color package

This package is a feature module that contains a color picker screen in isolation from other modules.

📦 Shape package

This package is a feature module that contains a shape picker screen in isolation from other modules.

📦 Preview package

This package is a feature module that contains a shape preview screen. Preview library depends on Color and Shape libraries and uses models defined by them.

📦 Testing package

Every other Swift package unit tests target depends on the Testing library. This way, it's a single place where external test dependencies are defined.

🧪 Tests

There is a unit testing target that tests the main app target. This one is managed by Xcode in a traditional way. All Swift packages in the project contain a test target in addition to a library product target. You can run tests for them from Xcode by selecting a given module build scheme.

The project contains snapshot tests of SwiftUI views. These were recorded using iPhone 12 simulator and should be run using it. Otherwise, you can experience snapshot test failures caused by screen resolution mismatch.

☕️ Do you like the project?

📄 License

Copyright © 2021 Dariusz Rybicki Darrarski

License: MIT