coder / coder/coder-desktop-macos

Investigate why app & system extension shared dependencies fail to embed

オープン
#149 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Swift
スター
29
フォーク
8
平均マージ
18時間 14分
マージ済み PR(30日)
4

説明

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 just `VPNLib` (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 issue https://github.com/apple/swift-protobuf/issues/1506#issuecomment-2435125065

In #143, the issue occured when `InternalCollectionsUtilities` was depended on by both the App target, and the VPN target (via another framework, VPNLib). When a library that depended on `swift-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 in `VPNLib`, 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.

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

まず、issues #145、#98、#143 に記載されているリリースビルドの失敗を再現し、App および VPN のシステム拡張ターゲットで共有されている依存関係に焦点を当てます。不足している埋め込みフレームワークを示す最小限の再現可能な例を用意し、その結果を issue に記載されているとおり Apple Developer Forums と Feedback Assistant 向けに文書化します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
swift
領域
build-system, desktop
issue の種類
バグ
難易度
4/5
見積もり時間
3〜5日
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
30/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。