Introduction

Importing CommonCrypto in a Swift app target is easier than it used to be, but framework targets have historically been the place where people get stuck. The big reason is that framework targets cannot rely on the usual bridging-header trick the way app targets often do.

So the right answer depends on your toolchain. In modern Xcode and SDKs, try a direct import CommonCrypto first. If that is not available in your environment, the fallback is to expose CommonCrypto as a Clang module rather than trying to force a bridging header into the framework target.

Try the Direct Import First

On current Apple toolchains, this often works directly in Swift:

1import Foundation
2import CommonCrypto
3
4func sha256(_ text: String) -> String {
5    let data = Data(text.utf8)
6    var digest = [UInt8](repeating: 0, count: Int(CC_SHA256_DIGEST_LENGTH))
7
8    data.withUnsafeBytes { buffer in
9        _ = CC_SHA256(buffer.baseAddress, CC_LONG(data.count), &digest)
10    }
11
12    return digest.map { String(format: "%02x", $0) }.joined()
13}
14
15print(sha256("hello"))

If that builds, you are done. This is the cleanest outcome.

Why the Old Bridging-Header Advice Breaks Down

A lot of older posts suggest creating an Objective-C bridging header and importing CommonCrypto there. That advice works for many app targets, but framework targets are the problem case.

If you are building a reusable Swift framework, relying on a bridging header is usually the wrong direction. The framework should see CommonCrypto as a proper module import instead.

That is why modern guidance is either:

• direct import CommonCrypto
• or a module-map based fallback for older toolchains

The Module-Map Fallback

If import CommonCrypto is not available directly, expose it as a Clang module. The concept is:

1. create a module.modulemap
2. point Swift's include search path at the directory containing it
3. import CommonCrypto normally from Swift

A minimal module map looks like this:

1module CommonCrypto [system] {
2    header "CommonCrypto/CommonCrypto.h"
3    export *
4}

The exact file layout and include path depend on how your project is organized, but the important idea is that Swift imports a module, not a bridging header, inside the framework target.

A Practical Framework Setup

A common project structure is:

1MyFramework/
2  Sources/
3  Modules/
4    module.modulemap

Then add the Modules directory to the framework target's import or include search paths so the Swift compiler can resolve import CommonCrypto.

Once the module is visible, your Swift code can stay clean:

import CommonCrypto

That is much better than scattering C-import workarounds throughout the framework.

Example: MD5 Hashing in a Framework Utility

Here is a second example using CommonCrypto from Swift code that could live inside a framework utility type:

1import Foundation
2import CommonCrypto
3
4public enum Digest {
5    public static func md5(_ text: String) -> String {
6        let data = Data(text.utf8)
7        var digest = [UInt8](repeating: 0, count: Int(CC_MD5_DIGEST_LENGTH))
8
9        data.withUnsafeBytes { buffer in
10            _ = CC_MD5(buffer.baseAddress, CC_LONG(data.count), &digest)
11        }
12
13        return digest.map { String(format: "%02x", $0) }.joined()
14    }
15}

The CommonCrypto API is C-based, so the Swift code mainly deals with pointer-safe access to the input bytes and digest buffer.

When to Consider CryptoKit Instead

If your minimum platform versions allow it and you do not specifically need CommonCrypto, CryptoKit is often the more modern Swift-native choice.

But CommonCrypto still appears often in shared codebases, older deployment targets, and framework work where consistency with existing C-based crypto code matters.

Common Pitfalls

The biggest pitfall is using app-target advice for a framework target. A bridging header is often the wrong tool in that situation.

Another common issue is assuming a custom module map is always necessary. On newer Apple toolchains, try import CommonCrypto first because the direct import may already work.

Developers also forget that CommonCrypto is a C API. Importing it successfully is only half the job; the Swift wrapper code still needs careful pointer handling.

Finally, think twice before adding crypto code just to hash strings casually. If the project targets modern Apple platforms and does not require CommonCrypto specifically, CryptoKit may be simpler.

Summary

• In a Swift framework, try import CommonCrypto directly first.
• Framework targets should not depend on the usual bridging-header advice meant for app targets.
• If direct import is unavailable, expose CommonCrypto through a module map instead.
• Once the module is visible, Swift code can call C hashing APIs such as CC_SHA256 or CC_MD5 normally.
• Consider CryptoKit for newer platform targets when CommonCrypto is not a hard requirement.