flutter_tools: Copy vendored frameworks from plugin podspecs in ios/macos-framework builds #180135

MohammedTarigg · 2025-12-19T18:44:31Z

When running flutter build ios-framework or flutter build macos-framework, vendored frameworks declared in plugin podspecs (via s.vendored_frameworks) were not being copied to the output directory.

This PR adds support for parsing plugin podspecs to find vendored_frameworks entries and copying them to the output directory. Single .framework files are wrapped into xcframeworks to match the output format.

Changes:

Added copyVendoredFrameworks method to BuildFrameworkCommand base class
Added parseVendoredFrameworks function to parse podspec Ruby files
Called from both iOS and macOS framework build commands
Added unit tests for the podspec parser

I'm happy to adjust the approach if there's a better way to handle this - particularly around the regex-based podspec parsing. Let me know if this looks reasonable or if you'd prefer a different strategy.

gemini-code-assist

Code Review

This pull request adds support for copying vendored frameworks from plugin podspecs during iOS and macOS framework builds. The implementation introduces a new copyVendoredFrameworks method and a regex-based parser for podspecs. My review focuses on improving the robustness and correctness of the parsing logic, aligning with async best practices, and enhancing test clarity. Overall, this is a valuable addition that addresses a gap in the build process.

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

packages/flutter_tools/test/commands.shard/hermetic/build_darwin_framework_test.dart

gemini-code-assist

Code Review

This pull request adds functionality to copy vendored frameworks from plugin podspecs during iOS and macOS framework builds. The implementation introduces a new method copyVendoredFrameworks and a regex-based parser parseVendoredFrameworks.

My review focuses on improving the robustness of the podspec parsing and correcting a path resolution issue.

The parseVendoredFrameworks function has a potential bug where it could incorrectly handle multiple vendored_frameworks assignments. I've suggested a refactoring to process only the last assignment, which aligns with Ruby's behavior.
There's a path resolution bug in copyVendoredFrameworks that could fail for plugins with shared darwin sources. I've provided a fix to use the podspec's parent directory as the base for resolving framework paths.
I've also recommended adding tests for the new copyVendoredFrameworks logic to ensure its correctness and prevent future regressions.

Overall, the changes are a valuable addition, and with these fixes, the implementation will be more robust.

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

packages/flutter_tools/test/commands.shard/hermetic/build_darwin_framework_test.dart

jmagman · 2026-01-02T22:30:43Z

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

+          final Directory destination = modeDirectory.childDirectory(frameworkName);
+          if (!destination.existsSync()) {
+            globals.logger.printTrace('Copying vendored xcframework: $frameworkName');
+            copyDirectory(source, destination);


@vashworth do you have concerns this will cause unintended consequences when a plugin supports both CoocaPods and Swift Package Manager?

I'm planning on introducing a new command when we do add SwiftPM support for add to app. So this will need to be adjusted (to limit it to CocoaPods-only plugins) and added to the new command, but I don't see any major conflicts

vashworth · 2026-01-06T18:15:02Z

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

+  // It captures either a single quoted string or an array literal.
+  // Group 1: single string content, Group 2: array content
+  final pattern = RegExp(
+    r'''^\s*[a-zA-Z_]+\.vendored_frameworks\s*=\s*(?:["']([^"']+)["']|\[([^\]]*)\])''',


This does not take into account when a vendored_framework is per platform, such as

spec.ios.vendored_frameworks = 'Frameworks/MyFramework.framework'

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

vashworth · 2026-01-06T18:39:23Z

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

+          final Directory destination = modeDirectory.childDirectory(frameworkName);
+          if (!destination.existsSync()) {
+            globals.logger.printTrace('Copying vendored xcframework: $frameworkName');
+            copyDirectory(source, destination);


I'm planning on introducing a new command when we do add SwiftPM support for add to app. So this will need to be adjusted (to limit it to CocoaPods-only plugins) and added to the new command, but I don't see any major conflicts

vashworth · 2026-01-06T19:07:33Z

packages/flutter_tools/lib/src/commands/build_ios_framework.dart

+    }
+  } else if (arrayContent != null) {
+    // Extract individual paths from the array content.
+    final pathPattern = RegExp(r'''["']([^"']+)["']''');


Podspec syntax allows wildcard patterns such as:

s.vendored_frameworks = '**/*.xcframework'

https://guides.cocoapods.org/syntax/podspec.html#group_file_patterns

Trying to match all the patterns seems overcomplicated. We could just try to match the most basic and accept it as a limitation for now since this would still be an improvement to what is.

I wonder if perhaps instead of parsing the podspec, the ios/Pods/Pods.xcodeproj/project.pbxproj could be parsed (using PlistParser) to find any children found in PBXGroups called "Frameworks".

vashworth · 2026-01-06T19:30:45Z

packages/flutter_tools/test/commands.shard/hermetic/build_darwin_framework_test.dart

There should be unit tests for copyVendoredFrameworks too

MohammedTarigg · 2026-01-14T02:48:43Z

Hey, sorry for keeping you waiting on this, I switched to parsing the project.pbxproj file instead of the podspec like you suggested. This way CocoaPods handles all the wildcard and platform-specific stuff for us.
Added tests for it too. Let me know if you need any changes.

… Darwin framework builds.

Co-authored-by: Victoria Ashworth <15619084+vashworth@users.noreply.github.com>

@vashworth

This change addresses reviewer feedback by: - Replacing podspec regex parsing with project.pbxproj parsing using PlistParser - This approach is more reliable because CocoaPods has already resolved all paths, wildcards, and platform-specific entries - Handles edge cases like spec.ios.vendored_frameworks and wildcard patterns automatically - Added comprehensive unit tests for parseVendoredFrameworksFromPbxproj Note: This only copies frameworks from CocoaPods-based plugins. Swift Package Manager support will be added in a separate command as mentioned by @vashworth.

MohammedTarigg requested a review from a team as a code owner December 19, 2025 18:44

github-actions bot added tool Affects the "flutter" command-line tool. See also t: labels. team-ios Owned by iOS platform team labels Dec 19, 2025

gemini-code-assist bot reviewed Dec 19, 2025

View reviewed changes

MohammedTarigg force-pushed the fix-ios-framework-vendored-frameworks branch from afeee34 to 70486c6 Compare December 19, 2025 18:54

okorohelijah requested review from okorohelijah and vashworth January 2, 2026 22:27

jmagman reviewed Jan 2, 2026

View reviewed changes

vashworth reviewed Jan 6, 2026

View reviewed changes

MohammedTarigg and others added 3 commits January 14, 2026 05:48

feat: Implement copying vendored frameworks from plugin podspecs into…

561c256

… Darwin framework builds.

Update packages/flutter_tools/lib/src/commands/build_ios_framework.dart

448dd53

Co-authored-by: Victoria Ashworth <15619084+vashworth@users.noreply.github.com>

MohammedTarigg force-pushed the fix-ios-framework-vendored-frameworks branch from 50a61cc to 038add9 Compare January 14, 2026 02:48

hellohuanlin requested a review from vashworth January 15, 2026 22:30

flutter_tools: Copy vendored frameworks from plugin podspecs in ios/macos-framework builds #180135

Are you sure you want to change the base?

flutter_tools: Copy vendored frameworks from plugin podspecs in ios/macos-framework builds #180135

Conversation

MohammedTarigg commented Dec 19, 2025

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jmagman Jan 2, 2026

Choose a reason for hiding this comment

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

vashworth Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

MohammedTarigg commented Jan 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants