Conversation
dosubot
bot
added
size:L
🛠️ Tuist Run Report 🛠️Tests 🧪
Builds 🔨
|
pepicrft
force-pushed
the
fix/external-static-framework-bundle-accessor
branch
from
858ffee to
254c196
Compare
pepicrft
commented
Jan 22, 2026
| if target.product.isDynamic { return true } | ||
| if target.product == .staticFramework, target.containsResources || target.containsMetalFiles { | ||
| return graphTarget.project.type == .local | ||
| return true |
Contributor
Author
There was a problem hiding this comment.
As mentioned in the description, I wrongly assumed that the issue that we had with external packages was not a bug but some assumptions in third-party packages regarding how bundles are accessed, but it turned out that wasn't the case, and it was just how we generated the Info.plist, so I'm reverting it.
…th resources The Obj-C bundle accessor was failing to find resource bundles at runtime for external packages configured as static frameworks. This happened because the accessor was only searching for standalone .bundle files, not for bundles embedded inside the framework directory. When an external Obj-C package (like SVProgressHUD) is configured as a staticFramework, its resources are placed inside the framework at <Framework.framework>/<Target.bundle>. The accessor now searches this path first before falling back to standalone bundle locations. Closes #9156
pepicrft
force-pushed
the
fix/external-static-framework-bundle-accessor
branch
from
254c196 to
2906a73
Compare
…static frameworks - Align ObjC bundle accessor with SwiftPM's approach while supporting Tuist's embedded framework resources - Update unit test to expect external static frameworks with resources to be embeddable - Fix linting issues
pepicrft
commented
Jan 22, 2026
| try await setUpFixture("generated_app_with_objc_static_framework_with_resources") | ||
| try await run(InstallCommand.self) | ||
| try await run(GenerateCommand.self) | ||
| try await run(BuildCommand.self, "App") |
Contributor
Author
There was a problem hiding this comment.
Need to find a way to run the app and check that it doesn't blow up.
fortmarek
approved these changes
Jan 22, 2026
- Add back the #import "TuistBundle+<target>.h" header that was accidentally removed - Update ViewController to load SVProgressHUD resources on launch - Update acceptance test to run the app on simulator and verify it doesn't crash
pepicrft
added a commit
that referenced
this pull request
Feb 13, 2026
This reverts the static framework resource embedding feature that was introduced across multiple PRs (#9081, #9141, #9210, #9240, #9317, #9382, #9419 and related fixes). Resources for static frameworks go back to being placed in separate .bundle targets instead of being embedded inside the framework itself. The cache version is bumped to invalidate artifacts built with the old embedding approach.
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes the
BundleNotFoundexception for external packages configured as static frameworks with resources (like SVProgressHUD or CLImageEditor).What changed
Aligned local and external static framework embedding: External static frameworks with resources are now embedded, just like local ones. Previously, I had reverted embedding for external dependencies thinking it was causing issues, but the actual problem was that the Info.plist generated for those frameworks had an incorrect bundle identifier.
Simplified bundle generation logic: Static frameworks (both local and external) no longer generate separate resource bundles. Resources stay inside the framework, which gets embedded.
Updated the Obj-C bundle accessor: The accessor now mirrors SwiftPM's approach while adding Tuist-specific framework locations. It first checks for embedded
.frameworkbundles (where Tuist places resources for static frameworks), then falls back to looking for.bundlefiles (SwiftPM's standard approach). This maintains backward compatibility while supporting Tuist's static framework resource embedding.Assumptions
This assumes that external dependencies are using the generated bundle accessor to find their resources, which is a safe assumption since that's how SwiftPM packages access their resources.
Test plan
Closes #9156