A dependency mirror refers to an alternate source location which exactly replicates the contents of the original source. [1]

I often end up in the same situation: I need to tweak an internal package that a project depends on. The usual options are:

• Drag and drop the repo into Xcode (Xcode replaces the remote dependency with the local copy)
• Change Package.swift to a local path dependency

Both work, but I prefer a CLI-only workflow. Turns out SPM has a cleaner alternative: dependency mirroring!

Set a Mirror

Point the remote URL to a local repo:

swift package config set-mirror --original "THE_ORIGINAL_URL" --mirror "LOCAL_PATH"

# Example
# swift package config set-mirror --original "https://github.com/apple/swift-argument-parser" \
#   --mirror "/Users/user/Developer/swift-argument-parser"

To confirm:

swift package config get-mirror --original "https://github.com/apple/swift-argument-parser"

Important Notes

• A mirror only changes where SPM fetches the repo from. It still resolves a version, branch, or revision.
• If you want local edits to show up, you must commit them in the mirrored repo.
• Use a branch or revision in Package.swift:

dependencies: [
    .package(url: "https://github.com/apple/swift-argument-parser", branch: "main"),
]

• Mirrors are matched by the exact URL string. If your dependency uses the .git suffix, set a mirror for that URL too.

Remove the Mirror

Once you are done, remove it:

swift package config unset-mirror --original https://github.com/apple/swift-argument-parser

If you added a .git mirror, remove that one as well.

Closing Thoughts

Mirrors are not a drop-in replacement for local path dependencies. You still need to commit changes, but in return you get a clean, repeatable CLI workflow that works across projects without touching Xcode.

Resources

• [1] swift-evolution/proposals/0219-package-manager-dependency-mirroring.md at main - swiftlang/swift-evolution

Instant Platinum is an unofficial client for Fitness Platinum. The audience is tiny: a gym franchise in Kraków and Katowice, Poland. That’s fine. This is mostly for me.

I can’t stand the official app. It’s not terrible, but it’s bloated with things I don’t care about: booking classes, managing goals, shopping (??). I just want to see my entry QR code as soon as I open the app. Today it takes three taps. Not awful, but not great.

So I built my own thing. Enter Instant Platinum: the app figures out which club you’re near and pops up the right QR code instantly. No clicks required. Works on iOS and watchOS.

Open, scan, done.

It took two evenings to put together. I’ll probably never “earn back” the time I spent, but I’ll happily trade those hours for fewer moments of frustration.

Since the initial release, it’s morphed into a fun little hobby project. I recently shipped Platinum Pulse, which I plan to plug in to show historical occupancy inside Instant Platinum. Next up: widgets and shortcuts so the code is ready before I even think about opening the app.

If you by any chance go to Fitness Platinum, go ahead and try it!

$ pod install

❌ ArgumentError - [Xcodeproj] Unable to find compatibility version string for object version `70`.

At the time, I updated CocoaPods to the latest version, confirmed my project format was set to the latest Xcode version (16.3), and tried again. When the issue persisted, I assumed CocoaPods was incompatible with buildable folders and that I would need to migrate to Swift Package Manager (SPM) to use them. This conclusion seemed to be confirmed by several closed GitHub issues where the suggested workaround was to manually convert folders back to groups.

However, it turns out you don’t have to wait to use Xcode’s buildable folders with CocoaPods! The solution is surprisingly simple: set the Project Format in your project’s settings to Xcode 16.0. Any other selection will trigger the Xcodeproj error.

With that single change, you can start taking full advantage of Xcode’s buildable folders in your CocoaPods projects!

References

• Xcodeproj PR #985
• CocoaPods Issue #12671

Assumptions

• Since this was an internal package, I did not need to maintain CocoaPods support. The goal was to replace it entirely with SPM. It is certainly possible to keep both, but that would require some additional work.
• The project I was working on is considered legacy; no one has touched it in about six years. Once this task is complete, I hope no one will need to update it for another half-dozen years. This allowed me to take some shortcuts, like integrating a third-party dependency directly into the codebase instead of spending time updating it to the latest version.
• All internal dependencies of your framework already support SPM.

With that said, let’s get started.

How?

I’ll assume your framework has no internal dependencies that require the same SPM treatment. If it does, start with the bottom-most dependency and work your way up.

External Dependencies

The first step is to update all external dependencies to use SPM.

In my case, one of the dependencies was PromiseKit, which was stuck six major versions behind the latest release. Since the project was considered legacy and no further development was planned, I decided to cut some corners.

Instead of spending time updating PromiseKit from version 1 through 7, I opted to add SPM support to the version my project was currently using. This approach required significantly less work and proved to be the right choice.

Removing the Old Dependency Manager

With all dependencies migrated to SPM, you should now be able to remove the old dependency manager from your project.

Adding a Swift Package Manifest

Next, initialize a new Swift package in your project’s root directory:

swift package init

This will create a Package.swift file. Here is a basic configuration:

// swift-tools-version: 6.1
import PackageDescription

let package = Package(
    name: "MyPackage",
    products: [
        .library(
            name: "MyPackage",
            targets: ["MyPackage"]),
    ],
    targets: [
        .target(
            name: "MyPackage"),
        .testTarget(
            name: "MyPackageTests",
            dependencies: ["MyPackage"]
        ),
    ]
)

Move your project’s source files to Sources/MyPackage and try to build the project. You will likely encounter one of the following errors:

SomeHeaderFile.h:19:9 'AnotherHeaderFile.h' file not found

or

public headers ("include") directory path for 'MyPackage' is invalid or not contained in the target

These errors indicate that the compiler cannot locate your project’s header files. By default, SPM looks for public headers in an include directory.

Create an include directory inside Sources/MyPackage and move all of your project’s public headers there.

If this structure doesn’t suit your project, you can define a custom path for your public headers by specifying publicHeadersPath in your Package.swift:

    targets: [
        .target(
            name: "MyPackage",
            publicHeadersPath: "some/custom/path"
        ),
        .testTarget(
            name: "MyPackageTests",
            dependencies: ["MyPackage"]
        ),
    ]

How do I locate my project’s public headers?

Your project most likely had an Xcode project file (.xcproj) before you started adding SPM support. You can find a list of your public headers in the “Build Phases” tab, under the “Headers” section.

After correctly configuring the public header files, your project might build. If it still doesn’t, you may have other header files that need to be discoverable. If that’s the case, you’ll need to add search paths for your private header files using headerSearchPath in your cSettings:

.target(
    name: "MyPackage",
    cSettings: [
        .headerSearchPath("Payments"),
        .headerSearchPath("Payments/ApplePayPaymentsService"),
        .headerSearchPath("Transactions/Components")
    ]),

It’s up to you whether you want to group all private header files in a single directory (.headerSearchPath("Path/To/My/Private/Headers")) or add all existing directories one by one using their current locations as I did in the snippet above.

With that done, you should now be able to build your project.

Troubleshooting

In my case, after migrating all dependencies to SPM and adding the package manifest, I was able to delete the Xcode project file entirely. If that is not the case for you, you might encounter additional issues.

One common problem is the error fatal error: framework '<some_framework>' not found when trying to import an SPM dependency into an Objective-C codebase in a project managed via an Xcode project file (.xcproj).

In this situation, you may need to experiment with your project settings. This thread on the Apple Developer Forums is an good starting point.

Conclusion

Once these steps are completed, you should be able to build your project. If you add your new package as a dependency via SPM, you can import it like any other Swift package. The same rules apply.

Swift:

import MyPackage

Objective-C:

@import MyPackage;

Resources

What helped me the most was looking at examples of existing Objective-C projects with SPM support. The following repositories are worth exploring:

• PSPDFKit/PDFXKit: A drop-in replacement for Apple’s PDFKit, powered by the PSPDFKit framework.
• AliSoftware/OHHTTPStubs: A library to easily stub your network requests.
• Mantle/Mantle: Model framework for Cocoa and Cocoa Touch

In Xcode projects, you define supported languages at the project level (not scheme level). Because of this structure, each app variant inherits the same language settings.

My task was to force each app variant to support only the language for the region it was released in. The French app should only support French, no matter what the user’s device language is set to, and so on. This decision was made because large portions of the app are web-based and only supported a single language.

Solution

There are multiple ways to solve this problem. What follows is the approach that worked best for my particular use case, given the project’s current structure:

First, create a build configuration file for each of the schemes and define the LOCALIZATIONS_TO_KEEP variable.

LOCALIZATIONS_TO_KEEP = fr

Then, add a new build phase called “Remove unused localizations.” Remember to position it after the “Copy Bundle Resources” build phase:

echo "Keeping only ${LOCALIZATIONS_TO_KEEP}.lproj"
echo "Application .app path: ${CODESIGNING_FOLDER_PATH}"

# Only search in the main app bundle, excluding 
# Frameworks directory and other dependency folders
find "${CODESIGNING_FOLDER_PATH}" -type d -name "*.lproj" \
  -not -path "*/Frameworks/*" \
  -not -path "*/PlugIns/*" \
  -not -path "*/Watch/*" \
  -not -path "*/SwiftPM/*" \
  | grep -v "${LOCALIZATIONS_TO_KEEP}.lproj" \
  | xargs rm -rf

CODESIGNING_FOLDER_PATH is an environment variable used in Xcode build scripts that represents the path to the app bundle being built. It typically points to the directory where the compiled application and its resources are placed before code signing occurs.

You’ll want to exclude locations where third-party dependencies might be located, because you can’t guarantee that they support the same language you want to force the app to use.

You can verify that the script works by navigating to ${CODESIGNING_FOLDER_PATH} in derived data and checking if the script successfully removed all other localization files.

Alternative Solutions

This issue could be solved by setting CFBundleLocalizations and CFBundleDevelopmentRegion IF my project used separate targets instead of separate schemes for different apps.

Alternatively, I could dynamically select Info.plist files for each of the schemes. I opted against this approach since the project already had build configurations defined for each of the schemes.

In this article, I’ll show you how to access a web page’s content, alter it using JavaScript, and display it using your Safari extension’s UI. Specifically, I’ll demonstrate how to display an article’s content in a popover.

I often use Large Language Models (LLMs) to summarize articles when I’m unsure if they’re worth reading. Without the extension we’re about to build, I’d need to manually trigger Safari’s reader mode (⌘ + ⇧ + R), copy all content, and paste it into Claude or ChatGPT. This extension is a handy tool that reduces friction!

Start by creating a new project using the “Safari App Extension” template, or add a Safari Extension target to your project. When prompted, set type to Safari App Extension (the default at the time of writing).

After the initial setup is complete, follow this guide to modify the template so that you can use SwiftUI to build the UI. Follow all the instructions except for one: do not delete script.js. We’ll need it to capture the web page’s content.

Once that’s done, we’ll proceed to get the current web page’s content, modify it to extract the article content, and display it. You can check out the complete sample project here.

1. Getting Active Safari Page (getActiveSafariPage)

let page = try await getActiveSafariPage()

• Uses Safari’s extension API to retrieve the current window, tab, and page
• Returns a SFSafariPage object representing the active browser page

2. Requesting Content (requestAndReceiveContent)

page.dispatchMessageToScript(
    withName: SafariExtensionMessage.Name.getContent.rawValue,
    userInfo: nil)

• Sends a “getContent” message to the injected content script

3. Content Script Processing (script.js)

function getPageContent() {
    // Tries to extract content in this order:
    // 1. Structured article data (JSON-LD)
    // 2. Article elements with specific selectors
    // 3. Fallback to body text
    
    const content = {
        title: document.title,
        body: getReaderContent().trim()
    };
    
    safari.extension.dispatchMessage("pageContent", { content });
}

4. Message Handling (SafariExtensionHandler)

case .pageContent:
    NotificationCenter.default.post(
        name: NSNotification.Name(SafariExtensionMessage.Notification.messageReceived.rawValue),
        object: nil,
        userInfo: userInfo
    )

• Receives the content message from the script
• Posts it to NotificationCenter

5. Content Reception (PopoverViewModel)

for await notification in NotificationCenter.default
    .notifications(named: NSNotification.Name(SafariExtensionMessage.Notification.messageReceived.rawValue))
    .compactMap({ notification in
        // Converts notification data to WebPageContent
    })

• Listens for the notification with the page content
• Converts the received data into a WebPageContent struct
• Returns the structured content to be displayed in the popover

Resources

• How to build a Safari extension with SwiftUI
• SafariReaderModeSample | GitHub

Missing package product `PACKAGE_NAME`

The issue often occurs when the package you’re trying to add is already open in Xcode. To resolve:

1. Close the package in Xcode.
2. Close your main project.
3. Reopen your main project.

I’m not sure what might be causing this issue or why reopening the project is required (a clean build won’t do).

To learn more about local Swift packages read Working with Local Swift Packages.

This setup requires me to frequently switch between multiple projects. Just a few days ago, I was working on the login flow. This involved modifying two Swift packages and one Xcode project.

Remembering whether a given project is a Swift package, a workspace (.xcworkspace), or a standard project (.xcodeproj) is exhausting. This adds unnecessary complexity and slows down the workflow. It would be better if we had a single command to open all of them at once. Here’s a script that does just that:

# The osp (Open Swift project) function first attempts to open a Package.swift file in the current directory; if it doesn't exist, it then searches for and opens either a .xcworkspace or a .xcodeproj directory, or outputs an error message if none are found.

osp() {
# Check for Package.swift in the current directory
if [[ -f "Package.swift" ]]; then
open "Package.swift"
return
fi

# Look for .xcworkspace directories in the current directory
local workspace=$(find . -maxdepth 1 -name "*.xcworkspace" -type d | head -n 1)

if [[ -n "$workspace" ]]; then
open "$workspace"
return
fi

# Look for .xcodeproj directories if no .xcworkspace directories were found
local project=$(find . -maxdepth 1 -name "*.xcodeproj" -type d | head -n 1)
if [[ -n "$project" ]]; then
open "$project"
return
fi

# Output error message if neither file type was found
echo "No project or workspace files found"
}

To use it, simply append it to your .zshrc file and run source ~/.zshrc or restart the shell.

Ideally, I’d completely delete it from my phone, but I still need it for texting. It’s borderline impossible to convince some of my friends to switch to a different platform. Also, some of Instagram’s messaging features are just nice to have.

Learning from experience, the second-best option in this type of situation is to add friction to the process. Having Reels one click away each time I open the app is way too tempting. Since I’m only ever using it to text people, it would be nice to have it open directly on the Messages screen.

How do I get a complete list of deep links the Instagram iOS app supports?

My initial plan was to jailbreak an iPhone, export the Instagram app, and then use a disassembler like Hopper to inspect the binary. On paper, the binary should contain all the supported deep links. It was only a matter of finding them. And learning how to jailbreak devices. And learning how to work with a disassembler. Seems like a lot of work for a simple shortcut, doesn’t it?

“Why don’t you use /.well-known/apple-app-site-association?” a friend of mine suggested after I shared what I was working on. Even though I was well aware of it, this didn’t come to my mind when looking for solutions.

The /.well-known/apple-app-site-association is a file used in iOS app development to configure Universal Links. Universal Links allow iOS apps to link directly to content within the app using standard HTTPS URLs, providing a seamless user experience by opening the app directly instead of a web page when the app is installed.

This was the perfect tool for the job. After inspecting the file, finding the right deep link was trivial. Long story short, here’s the final shortcut:

Instagram DMs | iCloud Shortcuts

Lesson learned: When something seems like over-engineering, it probably is.

I hope this helps some of you to reduce the number of times you start mindlessly scrolling because you couldn’t resist watching just a few reels before checking your messages!

Resources

• https://www.instagram.com/.well-known/apple-app-site-association
• Supporting associated domains | Apple Developer Documentation

Project A
  |
  └──> Swift Package B

To speed up and improve the workflow, you can convert the remote dependency B to a local one. This method works whether Project A is a Swift package or an Xcode project (xcodeproj or xcworkspace).

Xcode Project

In this case, Project A has an Xcode project file.

1. Remove the remote dependency from your project.
2. Re-add it as a local package.

This might seem excessive, as Xcode also supports just dragging and dropping the package into your project, but I’ve found this solution to be flaky. Explicitly removing it works every time, most of the time.

Swift Package

If Project A is a Swift package, you’ll need to convert B’s dependency declaration:

dependencies: [
    .package(url: "https://github.com/TinyCorp/B", exact: "0.52.3"),
    // ...

… into this:

dependencies: [
    .package(path: "path/to/B"),
    // ...

Example: given the following file structure, path is ../B:

.
├── A
│   └── Package.swift (we're here)
└── B
    └── Package.swift

With this setup, you’re now able to edit dependency B directly inside of A. I was genuinely surprised by how well Xcode handles this workflow.

Notes

Make sure the Swift package that you plan to add to your project is not opened in another Xcode window. In some cases, Xcode might fail with a cryptic error when trying to add the local package.

TL;DR

package.targets = package.targets.map { target in
    var plugins = target.plugins ?? []
    plugins.append(.plugin(name: "SwiftLintPlugin", package: "SwiftLint"))
    target.plugins = plugins
    return target
}

The Problem

Last month, I was tasked with adding SwiftFormat and SwiftLint to one of the projects my team maintains. The project is medium-sized and uses Swift Package Manager (SPM) for modularization. It has a separate SPM package for each module. For example:

• FeatureModules // Directory
  • Login // Swift Package
  • MyAccount // Swift Package
  • Dashboard // Swift Package
• Core // Directory
  • DomainModels // Swift Package
  • Networking // Swift Package

Each module typically consists of three targets (e.g., Login, LoginTests, LoginTestUtils). The third target’s sole purpose is to avoid duplicating testing doubles. You can read more about it here.

Adding SwiftFormat to the main project and all SPM packages was pretty straightforward. I decided to integrate it at the CI level to ensure all new code changes are properly formatted. Locally, I left this choice up to the maintainers. They can use it through a post-commit git hook or as an Xcode Extension. Depending on your needs, both solutions work great.

Integrating SwiftLint into the base project was also a breeze. What became problematic was integrating it into all the Swift packages. As I mentioned before, we were using a Swift package for each module. As per the documentation:

Due to limitations with Swift Package Manager plugins, this is only recommended for projects that have a SwiftLint configuration in their root directory, as there is currently no way to pass any additional options to the SwiftLint executable.

This limitation would require us to duplicate our SwiftLint config for each package, making future updates to the SwiftLint config error-prone and time-consuming. The same goes for updating the plugin itself.

Looking For a Solution

I had two problems to solve:

1. Automating the updating of the config file(s).
2. Automating the addition of the SwiftLint plugin to all new Swift packages in the future.

The first problem is easily solvable with a simple bash script. It would still require writing documentation, but let’s say I’m okay with the trade-off.

The second problem got me looking at Sourcery. However, this solution seemed like overkill from the beginning. Introducing Sourcery to a project just because of SPM limitations seemed like a bad idea.

Back to square one!

Solution

I started experimenting with the project structure. Instead of creating a new Swift package for each module, I decided to create a single package that worked as a container for all existing modules. Having all the modules defined in a single Package.swift file makes automating the SwiftLint plugin trivial.

// Inject base plugins into each target
package.targets = package.targets.map { target in
    var plugins = target.plugins ?? []
    plugins.append(.plugin(name: "SwiftLintPlugin", package: "SwiftLint"))
    target.plugins = plugins
    return target
}

This approach not only solved all of my problems but also required very little work. It involved merging all package definitions into a single one and moving some files around.

This solution won’t work for larger projects. Since my app had only a handful of modules, it worked wonderfully. If you’re working on a mid-sized project with tens of packages, you might consider grouping your modules into a handful of packages like FeatureModules, Models, etc.

I hope this issue will have been resolved long before we hit the wall due to the growing number of modules!

Resources

• Swifty Stack

Some test coverage report generation tools do not support “pure” Swift packages. One example is Slather. By pure, I’m referring to packages that contain only the Package.swift file, without any .xcodeproj or .xcworkspace files.

One solution to this problem was to generate a project file for a Swift package on the fly using Fastlane. This solution has one limitation: it’s not possible to generate a project file for a Swift package that contains any resources. When you try doing so, you’ll see Type 'Bundle' has no member “module” error when building.

Solution

What worked was using Fastlane with xcov. Here’s a snippet:

scan(
  package_path: ".",
  # Schemes generated by Xcode have a "-Package" suffix
  scheme: "MyPackage-Package",
  clean: true,
  device: "iPhone 14",
  code_coverage: true,
  result_bundle: true
)
xcov(
  is_swift_package: true
)

Here’s how the xcov output looks like:

+----------------------+--------+
|[32mxcov Coverage Report[0m    |
+----------------------+--------+
| MyPackage            | 13.75% |
| MyPackageTestUtils   | 0.00%  |
| MyPackageTests       | 22.12% |
| Average Coverage     | 11.96% |
+----------------------+--------+

The final piece of the puzzle is displaying the test coverage on the MR page like so:

In order to do that, we’ll need a regex to parse output from xcov. In this case we’re only interested in getting the percentage right beside “MyPackgae”. Here’s a snippet from the .gitlab-ci.yml file:

unit_test:
  stage: tests
  script:
    - bundle exec fastlane unit_test
  coverage: '/\|\s+MyPackage\s+\|\s+\d+\.\d+\%\s+\|/'

Resources

• Support for SPM package projects in fastlane scan
• Code coverage for Swift Packages with Fastlane
• Support for SPM package projects in fastlane scan
• Code coverage | GitLab Docs

Development Assets in Xcode that allow developers to provide test data to use within SwiftUI previews and other code during development. Assets marked for development will only be included in debug builds and removed once you create an archive of your app. This solution is preferred to having larger assets in the production binary size. Developers can add different types of data as Development Assets, such as JSON files for mocked network requests, images to use in SwiftUI previews, Core Data sample databases, and Swift files representing mocked or sample data. Swift files are added differently because they use the dead code stripper to avoid the compiler from failing during archiving.

To define development assets through the XcodeGen config file, use DEVELOPMENT_ASSET_PATHS:

name: MySampleApp
options:
  bundleId: com.example.MySampleApp
  deploymentTarget: 14.0
  organizationName: Example, Inc.
  developmentLanguage: swift
  useTabs: true
  indentWidth: 4
  tabWidth: 4
  swiftVersion: 5.5
  carthageBuildPath: Carthage/Build/iOS

targets:
  - name: MySampleApp
    type: application
    platform: iOS
    deploymentTarget: 14.0
    sources: 
      - path: MySampleApp
    settings:
      ENABLE_BITCODE: NO
      SWIFT_OPTIMIZATION_LEVEL: -Onone
      SWIFT_ACTIVE_COMPILATION_CONDITIONS: DEBUG
      DEVELOPMENT_ASSET_PATHS: 
         Dashboard/PreviewAssets
         List/Views/PreviewAssets
// ...

Resources

• Development Assets in Xcode to enrich SwiftUI Previews
• SwiftUI Preview Data

However, after some time, you might encounter problems like increased complexity, difficulty with integration testing, or code duplication. Today we’ll focus on the last one, specifically, testing doubles duplication. Let’s jump in!

Introduction

When saying “module” I’m always referring to a group of related targets. One example would be DomainModels and DomainModelsTests. The DomainModels target stores the implementation, while DomainModelsTests has unit tests code.

In the sample project for this article, we have the DomainModels package with a single module: DomainModels. Apart from that, we have the FeatureModules package with multiple modules. High-level structure of this setup looks like this:

├── DomainModels
│   ├── DomainModels
│   └── DomainModelsTests
└── FeatureModules
    ├── Dashboard
    ├── DashboardTests
    ├── AccountOverview
    └── AccountOverviewTests

All modules in the FeatureModules package depend on the DomainModels module. Because of that, both DashboardTests and AccountOverviewTests will likely have some duplicate testing doubles. This is not ideal.

There are many possible solutions to that problem. The one that I like the most is creating a separate target in the module just for storing all of its testing doubles. Let’s implement it!

Solution

The solution is fairly simple. We’ll just add the third target to the DomainModels module: DomainModelsFakes and move all the testing doubles from feature modules there.

Although the TestingDoubles postfix may be more appropriate for these modules, I prefer the term Fakes as it conveys the same meaning and is shorter. This choice becomes more practical when considering that there will likely be a significant number of these modules.

With this new addition, the DomainModels module consists of three targets:

• DomainModels
• DomainModelsTests
• DomainModelsFakes

Here’s the package definition:

// swift-tools-version: 5.7
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "DomainModels",
    platforms: [.iOS(.v16), .macOS(.v13)],
    products: [
        .library(
            name: "DomainModels",
            targets: ["DomainModels", "DomainModelsFakes"]),
    ],
    dependencies: [],
    targets: [
        .target(
            name: "DomainModels",
            dependencies: []),
        .target(
            name: "DomainModelsFakes",
            dependencies: ["DomainModels"]),
        .testTarget(
            name: "DomainModelsTests",
            dependencies: ["DomainModels", "DomainModelsFakes"]),
    ]
)

The new target DomainModelsFakes depends on the DomainModels target. We also need to add it as a dependency to the test target to use the testing doubles.

With those changes in place, we can now add DomainModelsFakes as a dependency to feature modules testing targets:

// swift-tools-version: 5.7
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "FeatureModules",
    platforms: [.iOS(.v16), .macOS(.v13)],
    products: [
        .library(
            name: "FeatureModules",
            targets: ["Dashboard", "AccountOverview"]),
    ],
    dependencies: [
        .package(path: "../DomainModels"),
    ],
    targets: [
        .target(
            name: "Dashboard",
            dependencies: [
                .product(name: "DomainModels", package: "DomainModels"),
            ]),
        .testTarget(
            name: "DashboardTests",
            dependencies: [
                "Dashboard",
                .product(name: "DomainModelsFakes", package: "DomainModels"),
          ]),
        .target(
            name: "AccountOverview",
            dependencies: [
                .product(name: "DomainModels", package: "DomainModels"),
            ]),
        .testTarget(
            name: "AccountOverviewTests",
            dependencies: [
                "AccountOverview",
                .product(name: "DomainModelsFakes", package: "DomainModels"),
          ]),
    ]
)

Conclusion

As our project grows, we may encounter problems such as code duplication, which can lead to increased complexity and difficulty with integration testing. In this article, we focused on the issue of testing doubles duplication and provided a solution to address it by creating a separate target in the module to store all testing doubles. By implementing this solution, we can reduce code duplication and improve the maintainability of our codebase. Do let me know if there are any other solutions worth trying out!

Resources

• “Fewer, Smarter, Faster: Scaling Testing @Spotify” by Vivian Santos & Sami Bouchebaba This talk is the where I’ve found this idea. See the video around 12:00 minute mark.
• TestDouble

Assumptions

Before we get started, let’s make a few assumptions about your project and its structure:

• You’re working on a project where modularization is done using SPM.
• You have an SPM package that depends on other packages.

Here’s how my project structure looks like:

Connecting Internal Dependencies

To connect the internal dependencies in your Package.swift file, you need to specify the dependencies for your package and the dependencies for your targets. Here’s an example Package.swift file that configures the FeatureModules package with its internal dependencies:

// swift-tools-version: 5.7
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "FeatureModules",
    platforms: [.iOS(.v16), .macOS(.v13)],
    products: [
        .library(
            name: "FeatureModules",
            targets: ["Dashboard"]),
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
        // .package(url: /* package url */, from: "1.0.0"),
        .package(path: "../DomainModels"),
        .package(path: "../Resources"),
        .package(path: "../Shared"),
        .package(path: "../Storage"),
    ],
    targets: [
        .target(
            name: "Dashboard",
            dependencies: [
                .product(name: "DomainModels", package: "DomainModels"),
                .product(name: "Resources", package: "Resources"),
                .product(name: "Shared", package: "Shared"),
            ]),
        .testTarget(
            name: "DashboardTests",
            dependencies: [
                "Dashboard",
                .product(name: "Storage", package: "Storage"),
          ]),
    ]
)

Conclusion

Connecting internal dependencies in Swift Package Manager is a crucial step when working on modularized projects. By properly configuring the Package.swift file and specifying the dependencies, you can ensure that your code compiles and runs without any issues. Remember to use the .product declaration when specifying dependencies in your target, and to make sure that the package paths are correctly set in the Package.swift file. By following these steps, you can maintain a well-organized project structure and increase code reusability across your codebase.

Resources

• Episode #171: Modularization: Part 1 | Point-Free
• Episode #172: Modularization: Part 2 | Point-Free
• Modularize an iOS App With SPM | Better Programming

I’m currently developing a chat-based app that requires the implementation of coping messages. Essentially, when a user long-presses a message bubble, an edit menu will appear with the option to “Copy.” This feature is a common element across most chat applications.

For the purpose of this article, let’s assume that all message bubbles are constructed using a subclass of UITextView called MessageTextView. To make the “Copy” option appear on a long-press gesture, we’ll first need to add the appropriate gesture recognizer:

let textView = MessageTextView()
let longPressGesture = UILongPressGestureRecognizer(
    target: self, 
    action: #selector(handleLongPressGesture(recognizer:)))
textView.addGestureRecognizer(longPressGesture)

@objc
func handleLongPressGesture(recognizer: UIGestureRecognizer) {}

Next, we’ll move on to the second step, which involves implementing the handleLongPressGesture method:

// 1
guard recognizer.state == .began,
      let recognizerView = recognizer.view,
      let superview = recognizerView.superview else { return }
// 2
textView?.becomeFirstResponder()
// 3
UIMenuController.shared.showMenu(from: superview, rect: recognizerView.frame)

Let’s now break down the steps necessary to implement this feature:

1. First, we need to obtain the recognizerView and its parent view from the recognizer. We’ll need both of these to properly position the edit menu on the screen.
2. Next, we’ll make the edit menu the first responder to ensure that it appears on the screen.
3. Finally, we’ll show the menu.

Note that at this point, all available options will be displayed, so we still need to filter out any unnecessary edit menu options. To do this, we’ll need to override two methods in our MessageTextView:

override public func canPerformAction(
    _ action: Selector, 
    withSender sender: Any?) -> Bool {
    // 1
    action == #selector(copy(_:))
}

@objc
override public func copy(_ sender: Any?) {
    // 2
    UIPasteboard.general.string = text
}

1. We filter out all other options, except for “copy”.
2. As per Apple’s documentation:

UIKit calls this method when the user selects the Copy command from an editing menu. Your implementation should write the selected content to the pasteboard without removing the selection from your interface.

At first glance, it may seem like we’ve completed the implementation of this feature. However, there’s one more detail that we need to address. Currently, if the keyboard is visible on the screen, the edit menu will be displayed in the wrong location. This occurs because we’re calling showMenu(from:rect:) while the keyboard is still visible. Once the keyboard hides, the layout of the conversation view (i.e. the screen where all the messages are displayed) will likely change.

Handling keyboard events

One solution to present the edit menu without hiding the keyboard is by using the UIResponder.next property, as described in this article. However, in my case, this is not feasible due to the modular architecture of the app I’m working on. The message composer (the view where the user composes a message) and conversation view (the view where all the message bubbles are displayed) are separate modules, and iOS doesn’t provide an easy way to obtain a reference to the current first responder.

Therefore, I found that the best solution for this scenario is to listen for the UIResponder.keyboardDidHideNotification and update the edit menu accordingly. To implement this in MessageTextView:

// Text view subclass
NotificationCenter.default.addObserver(
    self,
    selector: #selector(handleKeyboardDidHideNotification(notification:)),
    name: UIResponder.keyboardDidHideNotification,
    object: nil)

@objc
fileprivate func handleKeyboardDidHideNotification(notification: Notification) {
     UIMenuController.shared.update()
}

Conclusion

That’s it! The edit menu will update its position when keyboard hides.

Notes

• UIMenuController has been deprecated in iOS 16. See UIEditMenuInteraction.
• Remember to check out Using the UIMenuController and Manipulating the Responder Chain