Install statically via SPM

[igorvoytovich]

Problem

Hi,

Since Privacy Manifest validator has been fixed on Apple side, I guess it makes sense to revert back this change: https://github.com/realm/realm-swift/pull/8561 to be able to install Realm statically via SPM.

Solution

Remove type: .dynamic from Package.swift for both Realm and RealmSwift.

Alternatives

-

How important is this improvement for you?

Dealbreaker

Feature would mainly be used with

Local Database only

[sync-by-unito[bot]]

➤ PM Bot commented:

Jira ticket: RCOCOA-2360

[tgoyne]

Do you have any further information about what changes Apple has made to privacy manifest validation? I have not heard anything.

[igorvoytovich]

@tgoyne

you can find the discussion here: https://github.com/firebase/firebase-ios-sdk/issues/12557#issuecomment-2091166297

There was a problem with privacy manifest in static libraries for some time, but seems like everything is working normally now.

Hope this change can be made, so we can continue using the SDK the same way we’ve used for years.

[tgoyne]

Validation for static libraries works, but the problem is that Xcode doesn't actually build static libraries; it builds object libraries which are a different thing that did not work when I last retested it after the May 1 deadline.

[igorvoytovich]

Ah, I get it now.

So, there is no way of installing SDK statically via SPM as it was before this change? The only option is to use RealmSwift with Embed & Sing, which would be dynamic installation, right?

We doubt how we should deal with this right now. Perhaps we should avoid using SPM specifically for Realm and consider other installation ways? Because we have many different dependencies, and for everyone else nothing seems to have changed after introduction of Privacy Manifests. (Firebase SDKs for example)

[shvetsjr]

Every dependency we used fixed their privacy manifests without making their library dynamic and only Realm did it. This caused us a lot of issue and at some point we even wanted to switch to SwiftData. Really hope we will be able to install Realm statically in the future.

[igorvoytovich]

Every dependency we used fixed their privacy manifests without making their library dynamic and only Realm did it. This caused us a lot of issue and at some point we even wanted to switch to SwiftData. Really hope we will be able to install Realm statically in the future.

Same here.

At the moment we just don't know what to do next. I hope this will be changed in the next release so that the SDK can be updated and used normally.

[nirinchev]

We're going to investigate this and see if we can provide a better developer experience here. As a temporary workaround, you can either downgrade to 10.49.2 and copy the entries from the Realm privacy manifest to your app's privacy manifest or consume Realm through non-SPM package manager.

[shvetsjr]

Hey, @nirinchev any update on this? Can't we simply remove type: .dynamic from the package like other do?

[johnfrancmartin]

Also stuck on this, @nirinchev any updates?

[igorvoytovich]

Same for us. Really looking forward to a solution.

[nirinchev]

There are workarounds proposed already, so we don't consider this issue to be a blocker. We're looking into options here, but at the same time, our top priorities are around issues that don't have workarounds, such as Xcode 16 support and a few other high impact tickets.

[Jeanno]

It's really bad when a "patch" update breaks dependants.

Generally speaking, the change to .dynamic should at least bump the minor version. That way you give yourself leeway when there is a critical security patch in the future.

Also when an xcode project has more than one build target, having them link to the same dynamic library is problematic. You can only have one "Embed and sign" and have the other one "Do not embed", which contributes to some other crashes in edge cases as well from what I observed.

[igorvoytovich]

It's really bad when a "patch" update breaks a dependant.

Generally speaking, the change to .dynamic should at least bump the minor version. That way you give yourself leeway when there is a critical security patch in the future.

Also when an xcode project has more than one build target, having them link to the same dynamic library is problematic. You can only have one "Embed and sign" and have the other one "Do not embed", which contributes to some other crashes in edge cases as well from what I observed.

+1

IMO the best option would be to leave it as it was (without .dynamic) and to mention in docs that “due to some current Xcode bugs you’ll need to manually include some information in Privacy manifest when installing statically via SPM”.

[nirinchev]

We're not generally backporting fixes to old releases, so this being a minor or a patch release would have had no meaningful impact beyond automatically upgrading for people who configured their version range to be up to next minor.

That being said, I understand your frustration and it's undeniably annoying when what would seem like a trivial version bump results in more work and looking for workarounds. At the time we made the call, this felt like the lesser of two evils and we're still planning to try and mitigate it further. In the meantime my suggestion would be to switch to consuming the static xcframework directly or downgrade your dependency to a pre-.dynamic version.

[shvetsjr]

Thanks for the replies @nirinchev, don't mean to annoy or add take much of your time, just curious, what are the complications, risks or issues with simple removing type: .dynamic from the package and slightly update docs? Pure interest question :)

[nirinchev]

The problem is that Xcode doesn't merge the privacy manifest for static targets, which then means that users will need to manually add the privacy entries from https://github.com/realm/realm-swift/blob/master/RealmSwift/PrivacyInfo.xcprivacy to your app's privacy manifest.