# DylibForge: relinking static archives into dynamic libraries without source code

**URL:** <https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200>\
**Category:** Community Showcase\
**Tags:** spm, library, ios, linking, dynamic-linking\
**Created:** [July 10, 2026, 5:48pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200 "2026-07-10T17:48:55Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![loupehope](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/loupehope/32/45914_2.png) [@loupehope](https://forums.swift.org/u/loupehope)\
**Post date:** [July 10, 2026, 5:48pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200/1 "2026-07-10T17:48:55Z")

</div>

Static linkage is a common choice for Swift package products in iOS projects. For example, Tuist links package products statically by default.

It is often appropriate for release builds but can introduce friction during development. For LLDB to import Swift modules from statically linked archives during expression evaluation, the relevant module AST paths must be available, for example, through `-add_ast_path`. Otherwise, evaluating Swift expressions in the debugger may fail - [Debug Swift debugging with LLDB](https://developer.apple.com/videos/play/wwdc2022/110370/)

In modular projects with many test targets, the same static dependency may be linked into multiple final binaries. The result is duplicated machine code, larger CI/CD artifacts, and longer link times.

A dynamic library can avoid duplication when shared by multiple final binaries, while also providing a smoother debugging experience. However, a dynamic library is not always an option: a package may depend on a prebuilt static target, or a vendor may distribute a static framework without source code.

**DylibForge** addresses that case:

> **[GitHub - Loupehope/DylibForge: A macOS CLI tool for relinking static Apple ar...](https://github.com/Loupehope/DylibForge)**
>
> A macOS CLI tool for relinking static Apple ar archives and frameworks into dynamic Mach-O binaries.

It relinks a static archive as a dynamic library without requiring access to its source code. The tool extracts object files, preserves autolink directives, patches Objective-C symbol visibility, skips byte-identical objects, localizes selected duplicate native symbols, and invokes `clang -dynamiclib`.

For example:

```bash
dylib-forge ./AbstractMaps.framework/AbstractMaps
    --output ./AbstractMaps.framework/AbstractMaps
    --sdk iphoneos
    --install-name @rpath/AbstractMaps.framework/AbstractMaps
    --linker-arg "-Wl,-undefined,dynamic_lookup"

```

For more control:

```bash
dylib-forge ./AbstractMaps.framework/AbstractMaps
    --output ./AbstractMaps.framework/AbstractMaps
    --sdk iphoneos
    --install-name @rpath/AbstractMaps.framework/AbstractMaps
    --linker-arg -framework
    --linker-arg Foundation
    --linker-arg -lc++
    --linker-arg -F"Framework/Search/Path"
    --linker-arg -Wl,-U,_some_undefined_symbol
    --ignore-autolink PrivateVendorShim
    --exclude-object LegacySimulatorOnly

```

Any feedback, ideas, or suggestions are very welcome.

---

<div class="post-metadata">

**Author:** ![loupehope](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/loupehope/32/45914_2.png) [@loupehope](https://forums.swift.org/u/loupehope)\
**Post date:** [July 14, 2026, 7:44pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200/2 "2026-07-14T19:44:10Z")

</div>

Quick update on DylibForge - 1.1.0!

I have improved the autolinking and SDK handling paths. The tool now parses TAPI `.tbd` metadata structurally, respects `allowable-clients`, supports weak autolink libraries, and skips header-only SDK modules such as `CoreAudioTypes` that cannot be passed to the linker.

I also added a README tip for setting a minimum OS version through linker arguments.

Feedback and archives that expose edge cases are especially welcome :-)

---

<div class="post-metadata">

**Author:** ![loupehope](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/loupehope/32/45914_2.png) [@loupehope](https://forums.swift.org/u/loupehope)\
**Post date:** [July 17, 2026, 2:06pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200/3 "2026-07-17T14:06:53Z")

</div>

Quick update on DylibForge - 1.2.0!

I have improved Mach-O parsing, autolinking, and SDK handling for static archives and prebuilt frameworks. The tool now validates more binary metadata before using it, handles SDK TAPI metadata when filtering restricted frameworks, and prevents unfiltered autolink directives from reaching the linker.

This removes common warnings caused by internal SDK frameworks such as `UIUtilities` and redundant system-library linkage. I also made duplicate-symbol handling deterministic when archives are repacked or contain repeated native definitions.

Feedback and archives that expose edge cases are especially welcome :-)

---

<div class="post-metadata">

**Author:** ![loupehope](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/loupehope/32/45914_2.png) [@loupehope](https://forums.swift.org/u/loupehope)\
**Post date:** [July 26, 2026, 2:09pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200/4 "2026-07-26T14:09:28Z")

</div>

Quick update on DylibForge - 1.3.0!

I have added `dylib-forge-xc`, a new command for converting a complete XCFramework rather than relinking each static archive manually - [Release 1.3.0 💡 · Loupehope/DylibForge · GitHub](https://github.com/Loupehope/DylibForge/releases/latest)

The tool copies the XCFramework, relinks its supported static artifacts as dynamic libraries, and updates the root `Info.plist` to match the resulting paths and architectures. It derives the SDK and install name from the XCFramework metadata, so those no longer need to be supplied for every slice.

For example:

```swift
dylib-forge-xc ./VendorSDK.xcframework 
--output ./VendorSDK.xcframework

```

It preserves headers, modules, debug symbols, and existing dynamic artifacts. Unsupported architecture slices are skipped with a warning, and Mac Catalyst artifacts are omitted from the converted XCFramework for now.

Feedback and XCFrameworks that expose edge cases are especially welcome :-)

---

<div class="post-metadata">

**Author:** ![loupehope](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/loupehope/32/45914_2.png) [@loupehope](https://forums.swift.org/u/loupehope)\
**Post date:** [August 1, 2026, 2:50pm UTC](https://forums.swift.org/t/dylibforge-relinking-static-archives-into-dynamic-libraries-without-source-code/88200/5 "2026-08-01T14:50:13Z")

</div>

Quick update on DylibForge — 1.6.0! [Release 1.6.0 💻 · Loupehope/DylibForge · GitHub](https://github.com/Loupehope/DylibForge/releases/tag/1.6.0)

Since 1.3.0, DylibForge has gained improved support for modern SDKs and XCFrameworks. It now resolves Swift framework aliases correctly, handles multi-document TAPI v4 stubs, and can automatically link matching XCFramework dependency slices with options to control that behavior.

This release also adds `--xcode-path` to both `dylib-forge` and `dylib-forge-xc`, so you can choose the Xcode installation used for a single invocation. When the option is omitted, DylibForge continues to use the Xcode selected by `xcode-select`.