Description
template/Gemfile still pins gem 'xcodeproj', '< 1.26.0'. For any app whose .xcodeproj contains a PBXFileSystemSynchronizedRootGroup, which Xcode creates by default since Xcode 16, bundle exec pod install fails outright:
RuntimeError - `PBXGroup` attempted to initialize an object with unknown ISA
`PBXFileSystemSynchronizedRootGroup` from attributes:
`{"isa" => "PBXFileSystemSynchronizedRootGroup", "exceptions" => [...], "path" => "ShareQR", "sourceTree" => "<group>"}`
Xcodeproj added support for that ISA in 1.26.0 (CocoaPods/Xcodeproj#985), which is exactly the version the pin excludes. Because the pin lives in the Gemfile, deleting a stale Gemfile.lock does not help: Bundler re-resolves to 1.25.1 and fails identically. The pin also silently drags CocoaPods itself backwards, since CocoaPods 1.17.0 requires xcodeproj >= 1.28.0; on my machine bundle install with this Gemfile resolved CocoaPods 1.15.2, while the system pod is 1.17.0 and works fine.
History: the pin was added in #71 on 2024-10-28 because Xcodeproj 1.26.0, released the day before, broke React Native's CI. That regression was the default build settings change in CocoaPods/Xcodeproj#987, and upstream reverted it in 1.27.0 on 2024-10-31 (CocoaPods/Xcodeproj#992). The pin has therefore been unnecessary for its original purpose for close to two years, while it has become actively harmful for any app that adds a native target in a modern Xcode.
The template's own CI cannot catch this: template/ios/HelloWorld.xcodeproj/project.pbxproj is still objectVersion = 54 with zero synchronized groups. The same pin is present in facebook/react-native's root Gemfile and in packages/rn-tester/Gemfile.
Suggested fix: drop the pin, or replace it with a floor such as gem 'xcodeproj', '>= 1.28.1', which also brings the Xcode 26 objectVersion (CocoaPods/Xcodeproj#1041) and the Ruby 3.4 kconv/base64 crash fixes (CocoaPods/Xcodeproj#1046).
Steps to reproduce
- Create an app from the template.
- In Xcode 16 or newer, add any second target, for example a Share Extension, so the project gains a
PBXFileSystemSynchronizedRootGroup. (Equivalently: use any existing app whose project already has one.)
bundle installcd ios && bundle exec pod install- The install aborts with the unknown-ISA error above.
pod install using a system CocoaPods, which resolves Xcodeproj 1.28.1, succeeds on the same tree.
Removing the xcodeproj pin from the Gemfile and re-running bundle install && bundle exec pod install makes it succeed.
React Native Community Template Version
0.87.2 (also present on main and on 0.88.0-rc.1)
Affected Platforms
Build - MacOS
Output of npx @react-native-community/cli@latest info
System:
OS: macOS 27.0
CPU: (10) arm64 Apple M1 Max
Memory: 20.86 GB / 64.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node:
version: 24.18.0
Yarn:
version: 1.22.22
npm:
version: 11.16.0
Watchman:
version: 2026.07.27.00
Managers:
CocoaPods:
version: 1.17.0
path: /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms:
- DriverKit 27.0
- iOS 27.0
- macOS 27.0
- tvOS 27.0
- visionOS 27.0
- watchOS 27.0
IDEs:
Xcode:
version: 27.0/27A266a
Languages:
Ruby:
version: 4.0.6
path: /opt/homebrew/bin/ruby
Stacktrace or Logs
[!] Oh no, an error occurred.
RuntimeError - `PBXGroup` attempted to initialize an object with unknown ISA
`PBXFileSystemSynchronizedRootGroup` from attributes:
`{"isa" => "PBXFileSystemSynchronizedRootGroup", "exceptions" => ["5134B5522EB7C1B000A6AD03"], "path" => "ShareQR", "sourceTree" => "<group>"}`
If this ISA was generated by Xcode please file an issue: https://github.com/CocoaPods/Xcodeproj/issues/new
Gems resolved by Bundler with the current Gemfile:
cocoapods (1.15.2)
xcodeproj (1.25.1)
activesupport (7.2.3.1)
concurrent-ruby (1.3.7)
Same tree, system CocoaPods 1.17.0 with xcodeproj 1.28.1:
Pod installation complete! There are 119 dependencies from the Podfile and 120 total pods installed.
Reproducer
https://github.com/ZeusLN/zeus is a public app that reproduces it today: clone it, yarn install, then bundle install && cd ios && bundle exec pod install fails with the error above, while pod install with a current system CocoaPods succeeds. Its Gemfile is the template's, and its project has synchronized groups from two app extension targets.
I have not published a separate minimal reproducer repo, since the trigger is one line in the template Gemfile plus any project containing a synchronized group, and step 2 above produces it from a fresh template app in a minute. Happy to publish one from the reproducer template if that is required for triage.
Disclosure: this report was investigated and drafted with AI assistance (Claude Code). Every command, version check and log excerpt above was executed and verified on the environment described.
Description
template/Gemfilestill pinsgem 'xcodeproj', '< 1.26.0'. For any app whose.xcodeprojcontains aPBXFileSystemSynchronizedRootGroup, which Xcode creates by default since Xcode 16,bundle exec pod installfails outright:Xcodeproj added support for that ISA in 1.26.0 (CocoaPods/Xcodeproj#985), which is exactly the version the pin excludes. Because the pin lives in the
Gemfile, deleting a staleGemfile.lockdoes not help: Bundler re-resolves to 1.25.1 and fails identically. The pin also silently drags CocoaPods itself backwards, since CocoaPods 1.17.0 requiresxcodeproj >= 1.28.0; on my machinebundle installwith this Gemfile resolved CocoaPods 1.15.2, while the systempodis 1.17.0 and works fine.History: the pin was added in #71 on 2024-10-28 because Xcodeproj 1.26.0, released the day before, broke React Native's CI. That regression was the default build settings change in CocoaPods/Xcodeproj#987, and upstream reverted it in 1.27.0 on 2024-10-31 (CocoaPods/Xcodeproj#992). The pin has therefore been unnecessary for its original purpose for close to two years, while it has become actively harmful for any app that adds a native target in a modern Xcode.
The template's own CI cannot catch this:
template/ios/HelloWorld.xcodeproj/project.pbxprojis stillobjectVersion = 54with zero synchronized groups. The same pin is present infacebook/react-native's rootGemfileand inpackages/rn-tester/Gemfile.Suggested fix: drop the pin, or replace it with a floor such as
gem 'xcodeproj', '>= 1.28.1', which also brings the Xcode 26 objectVersion (CocoaPods/Xcodeproj#1041) and the Ruby 3.4kconv/base64crash fixes (CocoaPods/Xcodeproj#1046).Steps to reproduce
PBXFileSystemSynchronizedRootGroup. (Equivalently: use any existing app whose project already has one.)bundle installcd ios && bundle exec pod installpod installusing a system CocoaPods, which resolves Xcodeproj 1.28.1, succeeds on the same tree.Removing the
xcodeprojpin from theGemfileand re-runningbundle install && bundle exec pod installmakes it succeed.React Native Community Template Version
0.87.2 (also present on
mainand on 0.88.0-rc.1)Affected Platforms
Build - MacOS
Output of
npx @react-native-community/cli@latest infoStacktrace or Logs
Reproducer
https://github.com/ZeusLN/zeus is a public app that reproduces it today: clone it,
yarn install, thenbundle install && cd ios && bundle exec pod installfails with the error above, whilepod installwith a current system CocoaPods succeeds. ItsGemfileis the template's, and its project has synchronized groups from two app extension targets.I have not published a separate minimal reproducer repo, since the trigger is one line in the template
Gemfileplus any project containing a synchronized group, and step 2 above produces it from a fresh template app in a minute. Happy to publish one from the reproducer template if that is required for triage.Disclosure: this report was investigated and drafted with AI assistance (Claude Code). Every command, version check and log excerpt above was executed and verified on the environment described.