Add SFSymbol framework support#32
Add SFSymbol framework support#32LiYanan2004 wants to merge 4 commits intoOpenSwiftUIProject:mainfrom
Conversation
There was a problem hiding this comment.
Pull request overview
Adds SFSymbols private framework support to the repo and tooling so it can be updated, packaged, and installed into an internal SDK.
Changes:
- Adds an SFSymbols xcframework (with tbds/swiftinterfaces) plus reset/update scripts.
- Wires SFSymbols into update/install scripts, the SwiftPM package, and the UpdateXCFrameworks plugin.
- Adds a small SwiftUI example app demonstrating basic SFSymbols API usage.
Reviewed changes
Copilot reviewed 32 out of 33 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| Scripts/update_frameworks.sh | Adds SFSymbols to the selectable/all framework update list. |
| Scripts/SDK/install_sfsymbols.sh | New installer script to copy SFSymbols artifacts into an Internal SDK. |
| Scripts/SDK/install_internal_sdk.sh | Runs the new SFSymbols installer during SDK installation. |
| SFSymbols/update.sh | Generates the SFSymbols xcframework structure and swiftinterfaces from Sources/tbds. |
| SFSymbols/reset.sh | Removes generated SFSymbols xcframework output for a given release. |
| SFSymbols/latest | Declares the “latest” SFSymbols version directory pointer. |
| SFSymbols/README.md | Documents where tbds come from and what platforms are supported. |
| SFSymbols/2025/tbds/macos-arm64e-arm64-x86_64/SFSymbols.tbd | Adds macOS/maccatalyst tbd exports for SFSymbols. |
| SFSymbols/2025/tbds/ios-arm64-x86_64-simulator/SFSymbols.tbd | Adds iOS Simulator tbd exports for SFSymbols. |
| SFSymbols/2025/tbds/ios-arm64-x86_64-simulator/Info.plist | Adds iOS Simulator framework Info.plist metadata. |
| SFSymbols/2025/tbds/ios-arm64-arm64e/SFSymbols.tbd | Adds iOS device tbd exports for SFSymbols. |
| SFSymbols/2025/Sources/Modules/SFSymbols.swiftmodule/template.swiftinterface | Adds a template swiftinterface content used when generating module interfaces. |
| SFSymbols/2025/Sources/Info.plist | Adds a baseline framework Info.plist used when generating slices. |
| SFSymbols/2025/SFSymbols.xcframework/macos-arm64e-arm64-x86_64/SFSymbols.framework/SFSymbols.tbd | Adds the packaged macOS slice tbd inside the xcframework. |
| SFSymbols/2025/SFSymbols.xcframework/macos-arm64e-arm64-x86_64/SFSymbols.framework/Modules/SFSymbols.swiftmodule/x86_64-apple-macos.swiftinterface | Adds packaged macOS x86_64 swiftinterface. |
| SFSymbols/2025/SFSymbols.xcframework/macos-arm64e-arm64-x86_64/SFSymbols.framework/Modules/SFSymbols.swiftmodule/arm64e-apple-macos.swiftinterface | Adds packaged macOS arm64e swiftinterface. |
| SFSymbols/2025/SFSymbols.xcframework/macos-arm64e-arm64-x86_64/SFSymbols.framework/Modules/SFSymbols.swiftmodule/arm64-apple-macos.swiftinterface | Adds packaged macOS arm64 swiftinterface. |
| SFSymbols/2025/SFSymbols.xcframework/macos-arm64e-arm64-x86_64/SFSymbols.framework/Info.plist | Adds packaged macOS slice Info.plist. |
| SFSymbols/2025/SFSymbols.xcframework/ios-arm64-x86_64-simulator/SFSymbols.framework/SFSymbols.tbd | Adds the packaged iOS Simulator slice tbd inside the xcframework. |
| SFSymbols/2025/SFSymbols.xcframework/ios-arm64-x86_64-simulator/SFSymbols.framework/Modules/SFSymbols.swiftmodule/x86_64-apple-ios-simulator.swiftinterface | Adds packaged iOS Simulator x86_64 swiftinterface. |
| SFSymbols/2025/SFSymbols.xcframework/ios-arm64-x86_64-simulator/SFSymbols.framework/Modules/SFSymbols.swiftmodule/arm64-apple-ios-simulator.swiftinterface | Adds packaged iOS Simulator arm64 swiftinterface. |
| SFSymbols/2025/SFSymbols.xcframework/ios-arm64-x86_64-simulator/SFSymbols.framework/Info.plist | Adds packaged iOS Simulator slice Info.plist. |
| SFSymbols/2025/SFSymbols.xcframework/Info.plist | Declares xcframework available libraries/slices and supported architectures. |
| SFSymbols/2025/Info.plist | Duplicates xcframework metadata at the version root (appears used for generation). |
| README.md | Mentions BacklightServices and SFSymbols in the repository overview and installer note. |
| Plugins/UpdateXCFrameworks/UpdateXCFrameworksCommand.swift | Adds reset/update steps for SFSymbols in the plugin command. |
| Package.swift | Exposes SFSymbols as a binary target + library product via SwiftPM. |
| Example/SFSymbolsExample_2025/ExampleApp.swift | Adds SwiftUI example app entrypoint for SFSymbols. |
| Example/SFSymbolsExample_2025/ContentView.swift | Example view that prints basic SFSymbols dataset counts. |
| Example/SFSymbolsExample_2025/Assets.xcassets/Contents.json | Adds example app asset catalog metadata. |
| Example/SFSymbolsExample_2025/Assets.xcassets/AppIcon.appiconset/Contents.json | Adds example app icon set manifest. |
| Example/SFSymbolsExample_2025/Assets.xcassets/AccentColor.colorset/Contents.json | Adds example accent color asset manifest. |
Comments suppressed due to low confidence (5)
Scripts/SDK/install_sfsymbols.sh:1
- The installer hard-codes the SFSymbols version directory to
2024, but this PR adds/uses SFSymbols2025elsewhere (Package.swift and the UpdateXCFrameworks plugin). This will cause installs to fail or to pick up the wrong framework version. Consider deriving the version fromDARWINPRIVATEFRAMEWORKS_TARGET_RELEASE(like other tooling) or fromSFSymbols/latest, and ensure it matches the xcframework actually shipped in the repo.
Scripts/SDK/install_sfsymbols.sh:1 - The installer hard-codes the SFSymbols version directory to
2024, but this PR adds/uses SFSymbols2025elsewhere (Package.swift and the UpdateXCFrameworks plugin). This will cause installs to fail or to pick up the wrong framework version. Consider deriving the version fromDARWINPRIVATEFRAMEWORKS_TARGET_RELEASE(like other tooling) or fromSFSymbols/latest, and ensure it matches the xcframework actually shipped in the repo.
Scripts/SDK/install_sfsymbols.sh:1 - The installer hard-codes the SFSymbols version directory to
2024, but this PR adds/uses SFSymbols2025elsewhere (Package.swift and the UpdateXCFrameworks plugin). This will cause installs to fail or to pick up the wrong framework version. Consider deriving the version fromDARWINPRIVATEFRAMEWORKS_TARGET_RELEASE(like other tooling) or fromSFSymbols/latest, and ensure it matches the xcframework actually shipped in the repo.
Scripts/SDK/install_sfsymbols.sh:1 - The iPhoneSimulator slice path uses
ios-arm64-simulator, but the xcframework slice directory added in this PR isios-arm64-x86_64-simulator(and includes x86_64 swiftinterfaces). This mismatch will make the copy steps fail (directory not found) once the installer points at the new version. Align the installer slice path with the actual xcframework directory name (or rename/regenerate the xcframework slices to match the intended identifier).
SFSymbols/latest:1 - The
latestpointer is set to./2024, but the PR primarily introduces SFSymbols content under2025and runs update/reset for release2025in the plugin. This version skew makes automation ambiguous (and likely breaks scripts that readlatest). Either updateSFSymbols/latestto./2025, or add/ship a realSFSymbols/2024directory and consistently use that version across install/update/SwiftPM.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| <dict> | ||
| <key>LibraryIdentifier</key> | ||
| <string>ios-arm64-simulator</string> | ||
| <key>LibraryPath</key> | ||
| <string>SFSymbols.framework</string> | ||
| <key>SupportedArchitectures</key> | ||
| <array> | ||
| <string>arm64</string> | ||
| </array> | ||
| <key>SupportedPlatform</key> | ||
| <string>ios</string> | ||
| <key>SupportedPlatformVariant</key> | ||
| <string>simulator</string> | ||
| </dict> |
There was a problem hiding this comment.
The xcframework metadata declares the simulator slice as LibraryIdentifier = ios-arm64-simulator with only arm64, but the actual slice directory included in this PR is ios-arm64-x86_64-simulator and contains both arm64 and x86_64 swiftinterfaces. XCFramework consumers rely on LibraryIdentifier matching the on-disk slice folder name and on SupportedArchitectures reflecting included architectures; this mismatch can break resolution. Update the Info.plist to match the slice folder name and include x86_64 if it’s intended to be supported, or remove the x86_64 artifacts and rename the folder to match ios-arm64-simulator.
| @@ -0,0 +1,83 @@ | |||
| #!/bin/bash | |||
|
|
|||
| ## xcframework does not support soft link header file, so we use this script to simpfy the process. | |||
There was a problem hiding this comment.
Correct the typo in the comment: simpfy → simplify.
| ## xcframework does not support soft link header file, so we use this script to simpfy the process. | |
| ## xcframework does not support soft link header file, so we use this script to simplify the process. |
| generate_swiftinterface_header() { | ||
| local target="$1" | ||
| local result="" | ||
| result+="// swift-interface-format-version: 1.0\n" | ||
| result+="// swift-compiler-version: Apple Swift version 6.1 effective-5.10 (swiftlang-6.1.0.110.21 clang-1700.0.13.3)\n" | ||
| result+="// swift-module-flags: -target $target -enable-objc-interop -enable-library-evolution -swift-version 5 -Osize -enable-upcoming-feature InternalImportsByDefault -enable-experimental-feature Extern -module-name SFSymbols -package-name OpenSFSymbols\n" | ||
| result+="// swift-module-flags-ignorable: -interface-compiler-version 6.1" | ||
|
|
||
| echo -e $result | ||
| } |
There was a problem hiding this comment.
The function uses echo -e $result without quoting, which will perform word-splitting and glob expansion and can corrupt the intended output formatting. Use a quoting-safe approach (e.g., printf or echo -e \"$result\") and consistently quote variable expansions when passing parameters (e.g., generate_swiftinterface_header \"$target\").
| # Version mapping logic | ||
| if [ "$VERSION" = "2025" ]; then | ||
| IOS_VERSION="18.0" | ||
| MACOS_VERSION="15.0" | ||
| XROS_VERSION="2.0" | ||
| else | ||
| IOS_VERSION="18.0" | ||
| MACOS_VERSION="15.0" | ||
| XROS_VERSION="2.0" | ||
| fi |
There was a problem hiding this comment.
The version-mapping if/else currently assigns identical values in both branches, and XROS_VERSION is never used in the remainder of this script (as shown). This makes the intent unclear and adds maintenance overhead. Either remove the conditional entirely (and drop unused variables), or implement actual per-release mappings (and use/remove XROS_VERSION accordingly).
| # Version mapping logic | |
| if [ "$VERSION" = "2025" ]; then | |
| IOS_VERSION="18.0" | |
| MACOS_VERSION="15.0" | |
| XROS_VERSION="2.0" | |
| else | |
| IOS_VERSION="18.0" | |
| MACOS_VERSION="15.0" | |
| XROS_VERSION="2.0" | |
| fi | |
| # Version mapping logic (single mapping currently; extend if per-release values are needed) | |
| IOS_VERSION="18.0" | |
| MACOS_VERSION="15.0" |
| // SFSymbols | ||
| try run(context: context, command: "SFSymbols/reset.sh", environment: ["DARWINPRIVATEFRAMEWORKS_TARGET_RELEASE": "2025"]) | ||
| try run(context: context, command: "SFSymbols/update.sh", environment: ["DARWINPRIVATEFRAMEWORKS_TARGET_RELEASE": "2025"]) |
There was a problem hiding this comment.
This pins SFSymbols generation to release 2025, while other parts of the PR (notably the new SFSymbols/latest file and the SFSymbols installer script) refer to 2024. Centralizing the chosen SFSymbols release (e.g., via SFSymbols/latest or a shared constant) would prevent the tooling from drifting and inadvertently generating/installing different versions.
fa48f78 to
c57aba5
Compare
|
@Kyle-Ye Changes applied |
No description provided.