$ 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

Recently, however, I needed to brush up on Objective-C for a job I was interviewing for.

Below is a list of strategies that helped me quickly get back up to speed with Objective-C in about 6–8 hours. The list is fairly comprehensive—it should refresh your memory and might even teach you something new. That said, if you’re completely new to the language, YMMV.

Language Fundamentals: Objective-C for Swift Developers by Paul Hudson

I can’t recommend this book enough. It’s only 150 pages long and covers a wide range of language features and quirks you’ve likely forgotten—block syntax, anyone?

One tip: have a playground project open in Xcode while you read. If you’re not sure how to create an Objective-C project in Xcode 16, use this guide.

LeetCode Challenges

LeetCode doesn’t support Objective-C directly in its web interface, but that’s not an issue in the age of LLMs!

Since my goal was to refresh my knowledge of basic language features, I focused primarily on easy challenges. By “basic language features,” I mean working with strings, arrays, and simple data structures.

I definitely didn’t want to spend time solving complex problems like counting islands in a binary matrix (looking at you, “Number of Islands II,” problem #305).

I selected a few easy problems and worked through them in Xcode. Claude was particularly helpful in generating test cases to validate my solutions.

Working with Large Codebases

The final exercise was exploring a larger project written entirely in Objective-C. I started with the App Delegate and used an LLM to answer questions about anything that seemed unclear. I focused on understanding how common patterns were implemented—things like singletons, callback-based APIs, and delegate patterns.

Here are some projects I recommend checking out:

• Adium
• A curated list of awesome iOS ecosystem libraries written in Objective-C

That’s it! I was genuinely surprised by how much fun this process turned out to be—and also by how much I’d forgotten about Objective-C. Hopefully, this time around, the block syntax will stick with me longer!

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.

It looks like Objective-C is still an option in the default iOS project template. You can access it after setting the Interface to “Storyboard”. I hadn’t realized these dropdown menus were interconnected.

All credit goes to Douglas for spotting this!

tl;dr use macOS → Application → Game or Command Line Tool

Recently I wanted to refresh my memory on Objective-C. My first thought was to open Xcode, create a new project with language set to Objective-C and play with it. To my surprise, none of the iOS Application project templates allow you to select any other language than Swift.

I (mistakenly) assumed that Apple must have removed Objective-C from all templates altogether. I ended up searching for some open-source Objective-C project that I could use as a starting point.

Later on I learned that Objective-C language options are still alive and well in some templates for macOS.

Since there’s no straightforward way to disable SwiftLint across all local packages in a project, I decided on the simplest solution: automating the process of temporarily commenting out SwiftLint from the dependencies list.

In my projects, to ensure the SwiftLint plugin is automatically added to all package targets, I append the following code to each Swift package manifest:

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

Here’s the shell script I use to comment out SwiftLint across all packages and create a temporary commit. You can add this to your shell configuration file:

Make sure your git working tree is clean before running this script. Otherwise, it will include your existing changes in the commit.

# .zshrc

# Disable SwiftLint
dsl() {
    find . \( -path '*/.*' -prune \) -o -type f -name "Package.swift" -print | while read -r file; do
        sed -i '' 's|plugins.append(.plugin(name: "SwiftLintBuildToolPlugin", package: "SwiftLintPlugins"))|//plugins.append(.plugin(name: "SwiftLintBuildToolPlugin", package: "SwiftLintPlugins"))|' "$file" && \
        echo "Updated: $file"
    done
    git add -A && git commit -m "temp: disable swiftlint"
}

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.