Skip to content

Add Swift Package Manager support - #188

Open
harumidiv wants to merge 1 commit into
button:masterfrom
harumidiv:feature/swiftpm-support
Open

Add Swift Package Manager support#188
harumidiv wants to merge 1 commit into
button:masterfrom
harumidiv:feature/swiftpm-support

Conversation

@harumidiv

Copy link
Copy Markdown

Summary

Adds a Package.swift so DeepLinkKit can be consumed with Swift Package Manager,
alongside the existing CocoaPods and Carthage support.

SwiftPM requires all public headers of a C-family target to live under a single
include directory, and DeepLinkKit's sources import headers by file name only
(#import "DPLDeepLink.h"). To satisfy that, the ten public headers move to
DeepLinkKit/include/DeepLinkKit/. Private headers stay next to their
implementation files.

Nothing changes for existing users: #import <DeepLinkKit/DeepLinkKit.h> and
#import <DeepLinkKit/AppLinks.h> keep working, and no header contents were edited.

Changes

  • Package.swift — a single Objective-C target, iOS 12 / tvOS 12
  • Public headers moved to DeepLinkKit/include/DeepLinkKit/ (moves only, no content
    changes). The Errors directory is removed since DPLErrors.h was its only file.
  • DeepLinkKit/include/module.modulemap — see below
  • DeepLinkKit.xcodeproj — file references updated to the new header locations
  • README.md — Swift Package Manager installation instructions
  • .gitignore.build/ and .swiftpm/

Why the explicit module map

SwiftPM generates an umbrella-header module map when include/<Module>/<Module>.h
exists. AppLinks.h, DPLDeepLink+AppLinks.h and DPLMutableDeepLink+AppLinks.h
are intentionally not imported by DeepLinkKit.h, so clang emits
umbrella header for module 'DeepLinkKit' does not include header ... warnings in
every consumer build, and the AppLinks category is unreachable from Swift.
Listing those three headers explicitly resolves both, without changing what
DeepLinkKit.h itself pulls in.

Compatibility

  • CocoaPodsDeepLinkKit.podspec is unchanged. Its source_files and
    private_header_files patterns resolve to exactly the same files as before
    (10 public headers, 11 private headers, 14 implementation files).
  • Carthage / Xcode project — both framework targets still build, and the
    Headers build phase entries keep their public visibility.

Verification

  • xcodebuild -scheme DeepLinkKit -destination 'generic/platform=iOS' — succeeds
  • DeepLinkKit-tvOS target built with -sdk appletvos — succeeds
  • A SwiftPM consumer package resolving this branch from git builds for iOS with zero
    warnings, from both Swift (import DeepLinkKit) and Objective-C
    (#import <DeepLinkKit/DeepLinkKit.h>, #import <DeepLinkKit/AppLinks.h>),
    including the AppLinks category
  • Verified the podspec file patterns resolve to the same file set as before

Not verified locally: tvOS through SwiftPM (tvOS platform support is not installed on
my machine), and the CocoaPods-based test target (its dependencies could not be
installed in my environment). This is a packaging change with no source behaviour
changes, so no tests are added — happy to add whatever you'd like to see.

Note

Consumers can point at a branch or revision today, but a tagged release will be
needed for version-based dependencies, since the existing 1.5.1 tag predates
Package.swift.

@harumidiv
harumidiv requested a review from wessmith as a code owner August 26, 2026 23:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant