Feature: Xcode 16.0 support

[Brett-Best]

Initial support for Xcode 16 which changed object versions and introduced a new attribute.

[Brett-Best]

Some of the other variable such as LAST_KNOWN_SWIFT_VERSION could do with updating as well

[marcpalmer]

FYI fastlane's dependency on xcodeproj means that you can't build Xcode 16 projects that have the new PBXFileSystemSynchronizedRootGroup node type added e.g. if you add a widgets extension in Xcode 16 beta, it uses this node type and then you can no longer build with fastlane.

The workaround in this case is to remove that node from your project in Xcode 16, removing the references only, then open the project in Xcode 15, add the container node again/add the files back again, which creates the node as a PBXGroup, and then you can open the project in both 15 and 16 fine and xcodeproj can parse it fine and fastlane will build even with the Xcode 16 buildchain.

[drewolbrich]

FYI fastlane's dependency on xcodeproj means that you can't build Xcode 16 projects that have the new PBXFileSystemSynchronizedRootGroup node type added e.g. if you add a widgets extension in Xcode 16 beta, it uses this node type and then you can no longer build with fastlane.

I believe that more broadly, without similar workarounds, fastlane can't be used with any new project created with Xcode 16.

If you create a new iOS project with Xcode 16, its xcodeproj/project.pbxproj file will contain the string PBXFileSystemSynchronizedRootGroup.

[Brett-Best]

I wonder if it would be possible to have Fastlane use https://github.com/tuist/XcodeProj 🤔

[pepicrft]

I wonder if it would be possible to have Fastlane use https://github.com/tuist/XcodeProj 🤔

That'll be tricky. Through the Ruby version of XcodeProj, tools like Fastlane can manipulate the object directly in memory through the various getters and setters available in Ruby objects defined by this library. If we adopt something like Tuist's XcodeProj, we'd have to use something like Ruby FFI, so the interaction between Fastlane (Ruby) and XcodeProj (Swift) would have to be through a set of functions that capture the various operations that the Ruby side of things has interest in doing.

[Westacular]

FYI fastlane's dependency on xcodeproj means that you can't build Xcode 16 projects that have the new PBXFileSystemSynchronizedRootGroup node type added e.g. if you add a widgets extension in Xcode 16 beta, it uses this node type and then you can no longer build with fastlane.

The workaround in this case is to remove that node from your project in Xcode 16, removing the references only, then open the project in Xcode 15, add the container node again/add the files back again, which creates the node as a PBXGroup, and then you can open the project in both 15 and 16 fine and xcodeproj can parse it fine and fastlane will build even with the Xcode 16 buildchain.

I haven't tested this, but I think there's a more simple fix: in Xcode 16, select the folder in the Project navigator, and go to Edit > Convert > To Group.

That should convert the PBXFileSystemSynchronizedRootGroup to a PBXGroup that Xcodeproj and Fastlane can handle.

[Levy4u]

FYI fastlane's dependency on xcodeproj means that you can't build Xcode 16 projects that have the new PBXFileSystemSynchronizedRootGroup node type added e.g. if you add a widgets extension in Xcode 16 beta, it uses this node type and then you can no longer build with fastlane. The workaround in this case is to remove that node from your project in Xcode 16, removing the references only, then open the project in Xcode 15, add the container node again/add the files back again, which creates the node as a PBXGroup, and then you can open the project in both 15 and 16 fine and xcodeproj can parse it fine and fastlane will build even with the Xcode 16 buildchain.

I haven't tested this, but I think there's a more simple fix: in Xcode 16, select the folder in the Project navigator, and go to Edit > Convert > To Group.

That should convert the PBXFileSystemSynchronizedRootGroup to a PBXGroup that Xcodeproj and Fastlane can handle.

"To Group" worked for me but I lost my app scheme. So I had to go to Product > Schemes > Autocreate Schemes Now, and it came back.

[mlight3]

Any update or progress?

[Brett-Best]

@mlight3 I haven't made any further improvements as this currently is sufficient for my needs.

[patrickhartling]

What is the likelihood of this PR being approved? I work on a large team with a large code base, and being able to use folders instead of groups could save us a lot of hassle. For example, our project file size could be reduced by more than 26,000 lines through the use of folders. However, we cannot make that move because Fastlane cannot build our code without this gem supporting folders.

[Brett-Best]

@patrickhartling you can point to this using your Gemfile and it'll work in the meantime. My feeling is a low chance of approval on this tbh, especially since it's not complete support.

[orta]

Anyone in the community can take over this PR if you want it merged, start a fork from the head commit on this branch and go through the feedback in the chat and then send a separate PR - Brett got a lot of the way there, and that's a good job but it doesn't have to be on them to wrap it up

[igor-makarov]

I agree - @Brett-Best did a great job putting together this PR and there's not much left!

There are just a few more attributes to add, I think all of those are simple value types:

• Copy attributes from PBXGroup to PBXFileSystemSynchronizedRootGroup: name, uses_tabs, indent_width, tab_width, wraps_lines
• Add new attributes to PBXFileSystemSynchronizedRootGroup:
  • explicit_file_types (type Hash)
  • explicit_folders (type Array)
• Add new attributes to PBXFileSystemSynchronizedBuildFileExceptionSet:
  • public_headers (type Array)
  • private_headers (type Array)
  • additional_compiler_flags_by_relative_path (type Hash)
  • attributes_by_relative_path (type Hash)

[Brett-Best]

Replied to thread above, but one of the things that also needs done, which seems much more complicated is https://github.com/tuist/XcodeProj/issues/852.

I also checked the box to allow: users with write access to CocoaPods/Xcodeproj can add new commits to your feature/Xcode-16.0-Support branch.

[Harry-KNIGHT]

Hi, any news on this PR ?

[gui17aume]

I made a new PR based on this one to add some missing attributes: https://github.com/CocoaPods/Xcodeproj/pull/985

Hoping it will help!