swift-sharing can't be used as dynamic library on at least iOS 16

[KaiOelfke]

Description

When using swift-sharing as dynamic library on iOS 16 simulators it crashes on launch:

dyld[19285]: Symbol not found: _SFAirDropDeviceNameIsSuspicious
  Referenced from: <DC8E84EB-1E2C-3415-AF31-E86B29FA6B2D> /Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ShareSheet.framework/ShareSheet
  Expected in:     <E4A3C0A4-327D-30A2-BF09-A89F626638FC> /Users/kaioelfke/Library/Developer/Xcode/DerivedData/ShareIt-cynzwlohngbvacaujbvtfvtrmjhb/Build/Products/Debug-iphonesimulator/Sharing.framework/Sharing

There's a name conflict with a private Apple framework also called Sharing.framework.

While I discovered this issue initially within a project using Tuist it can also be reproduced without using Tuist. In order to reproduce it a single change has to be done in the swift-sharing package manifest. This forces Xcode / SPM to integrate Sharing as dynamic library.

.library(
      name: "Sharing",
      targets: ["Sharing"]
      type: .dynamic,
      targets: ["Sharing"],
    )

main...KaiOelfke:swift-sharing:main

On the main branch of swift-sharing nothing is specified for type, which doesn't mean it'll be always a static framework.

The optional type of the library that’s used to determine how to link to the library. Leave this parameter so Swift Package Manager can choose between static or dynamic linking (recommended). If you don’t support both linkage types, use Product.Library.LibraryType.static or Product.Library.LibraryType.dynamic for this parameter.

Then you only need some simple sample project using swift-sharing and run on an iOS 16 simulator. I can't test iOS 16 devices as I don't have one. iOS 17 / 18 seem to be not affected. My guess would be that the framework doesn't exist anymore or newer versions of dyld handle this name collision somehow. But I don't really know.

I've solved this with the steps described in https://community.tuist.dev/t/sharing-framework-symbol-not-found/279/9. For vanilla SPM or Xcode projects this can probably also be fixed by using moduleAlias in SPM or alternatively in other swift flags -module-alias Sharing=PFSharing. The PRODUCT_NAME build setting maybe also has to be changed.

I'm filing this issue to document it and I don't need another solution. I guess renaming the framework is not easy as I remember the issues with XCTestDynamicOverlay and probably also not worth it for only iOS 16.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The app should launch and run.

Actual behavior

The app crashes on launch.

dyld[29776]: Symbol not found: _SFAirDropDeviceNameIsSuspicious
  Referenced from: <DC8E84EB-1E2C-3415-AF31-E86B29FA6B2D> /Library/Developer/CoreSimulator/Volumes/iOS_20E247/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 16.4.simruntime/Contents/Resources/RuntimeRoot/System/Library/PrivateFrameworks/ShareSheet.framework/ShareSheet
  Expected in:     <D7567E8B-1387-3552-BB0E-8395F2307263> /Users/kaioelfke/Library/Developer/Xcode/DerivedData/ShareSample-erxibdtbbozksudaetmefassoyus/Build/Products/Debug-iphonesimulator/PackageFrameworks/Sharing.framework/Sharing

Reproducing project

ShareSample.zip

Sharing version information

KaiOelfke@0251bfe

Destination operating system

iOS 16

Xcode version information

Version 16.1 (16B40)

Swift Compiler version information

swift-driver version: 1.115 Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)
Target: arm64-apple-macosx15.0

[stephencelis]

@KaiOelfke I'm going to convert this to a discussion till it can be reproduced without changing the library's package file. Currently it sounds like this has more to do with Tuist projects that use Sharing as a dynamic library. Perhaps the Tuist community has a solution?

If you are able to reproduce this in a vanilla SPM project, please share it with us and we can determined if it's an actual bug with the library.

It's possible module aliases could also work around the issue. Let us know if you explore that and have any luck!

[KaiOelfke]

Perhaps the Tuist community has a solution?

It's already solved. The link in my original comment has a workaround using moduleAlias.

I'm going to convert this to a discussion till it can be reproduced without changing the library's package file. Currently it sounds like this has more to do with Tuist projects that use Sharing as a dynamic library. If you are able to reproduce this in a vanilla SPM project, please share it with us and we can determined if it's an actual bug with the library.

I disagree here. The reproduction changed one line, but it doesn't involve Tuist. It's just a combination of iOS 16 and dynamic linking.

E.g. if you look up the official documentation here.

/// - Parameters:
///     - name: The name of the library product.
///     - type: The optional type of the library that is used to determine how to link to the library.
///         Leave this parameter unspecified to let to let the Swift Package Manager choose between static or dynamic linking (recommended).
///         If you do not support both linkage types, use `.static` or `.dynamic` for this parameter. 
///     - targets: The targets that are bundled into a library product.
static func library(name: String, type: Product.Library.LibraryType? = nil, targets: [String]) -> Product

From my perspective, my fork shows that swift-sharing currently does not support dynamic linking on iOS 16. The documentation says "If you do not support both linkage types, use .staticor.dynamic for this parameter."

According to the documentation swift-sharing should then use .static, not support iOS 16, or find another solution.

Currently the type is unspecified so according to the documentation you let the Swift Package Manager choose between static or dynamic linking. I don't know the internal rules that determine for what kind of build and dependency graphs SPM chooses dynamic instead of static, but whenever it's chosen for some project that runs iOS 16 there's this crash.

[mbrandonw]

From my perspective, my fork shows that swift-sharing currently does not support dynamic linking on iOS 16.

But can you reproduce the problem without a fork of our project and only using what is on main? If not, I don't see how this is a problem that we should be solving in the library.

As the documentation shows, there is a blurry line between dynamic and static linking when it comes to Xcode/SPM. We are specifically not specifying the library type to allow Xcode/SPM do whatever it needs to do, and as far as I can tell that always works when just using vanilla Xcode/SPM.