Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Investigate why app & system extension shared dependencies fail to embed #149

Open
@ethanndickson

Description

@ethanndickson

In both#145 and#98, I've encountered an issue with release builds of the app. These issues arose when a dependency was required by both the App target (or any of it's dependencies), and the system extension target (and any of it's dependencies).

In#98, the issue occurred when protobuf definitions were added directly to the app target, or a new framework target that would be depended on by the app target. They were previously working fine being depended on by justVPNLib (which the system extension depends on).
In the first case, the network extension would crash. In the second case, the app would crash.
The crash reason was:

Library not loaded: @rpath/SwiftProtobuf.framework/Versions/A/SwiftProtobuf

Other users have reported this issueapple/swift-protobuf#1506 (comment)

In#143, the issue occured whenInternalCollectionsUtilities was depended on by both the App target, and the VPN target (via another framework, VPNLib). When a library that depended onswift-collections was added to the app target, the network extension would crash on startup with the error:

Library not loaded: @rpath/InternalCollectionsUtilities.framework/Versions/A/InternalCollectionsUtilities

FWICT, xcode is making some form of optimisation where it constructs a framework for code shared between two different targets. This poses an issue with a system extension, which is copied and executed outside of the app bundle. A copy of the system extension always lives in the app bundle, so it's trivial for the app to depend on a framework present within the system extension bundle (we already do this), but not the other way around. If there was some way to tell xcode to embed this new framework within the system extension bundle, we wouldn't have this issue.

Instead, the workaround we've gone with is to simply put everything that would cause this issue inVPNLib, as to minimise the number of times we depend on any one package.

This issue doesn't require immediate action, and is more so for book-keeping. It would be good to post this alongside an MRE on the Apple developer forums and in Apple feedback assistant.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp