#30223·fastlane

get_version_number fails on array-valued shellScript in newer project formats - Xcode 27, Xcode 26, Xcode 16.3

Author: KaspikCreated Sep 14, 2026Updated Sep 14, 2026

Bug description

Please prioritize support for array-valued shellScript fields in newer Xcode project formats. The xcodeproj parser rejects this representation, affecting Fastlane actions such as get_version_number that load a project through it.

The error still reproduces with Fastlane 2.239.0 and xcodeproj 1.28.1, after updating both dependencies with Bundler.

Urgency and existing reports

Apple released Xcode 27 RC and opened submissions for the new OS releases on September 9, 2026. Compatibility gaps in project-parsing actions are particularly disruptive during release preparation and toolchain adoption.

This is longstanding: CocoaPods/Xcodeproj#1017 reported this exact serialization failure on May 19, 2025, nearly 16 months ago. CocoaPods/CocoaPods#12794 reports the same error.

The affected representation is present in the Xcode 26.3 project format. Xcode 27's release adds urgency to fixing this existing problem; this report does not claim that all Xcode 27 projects or all Fastlane actions fail.

Minimal reproduction

A Run Script phase represented as a string:

shellScript = "echo hello\n";

is represented in newer project serialization as an array:

shellScript = (
    "echo hello",
    "",
);

Load a project containing the latter with:

bash
bundle exec ruby -e 'require "xcodeproj"; Xcodeproj::Project.open("Example.xcodeproj")'

The parser raises:

[Xcodeproj] Type checking error: got `Array` for attribute: Attribute `shellScript` (type: `simple`, classes: `[String]`, owner class: `PBXShellScriptBuildPhase`)

Fastlane's get_version_number uses this project parser, so the same incompatibility prevents it from reading a version:

ruby
get_version_number(xcodeproj: "Example.xcodeproj", target: "Example")

Expected behavior

Fastlane should be able to read projects using the newer serialization without requiring a project-format downgrade. A supported parser fix would unblock affected version-reading and other project-parsing operations.

Maintenance / ownership

Please also see Fastlane taking over the xcodeproj dependency? #29926. Orta proposed transferring maintenance, and a subsequent Fastlane response outlined maintaining compatibility with Xcode changes and publishing a patch.

Could this bug be treated as a high-priority compatibility fix in that effort? Guidance on where to contribute a fix during the ownership transition would also help. The immediate request is a supported fix; a broader dependency migration can remain in the existing discussion.

Dependency versions

  • Fastlane: 2.239.0
  • xcodeproj: 1.28.1

The minimal parser reproduction requires no Apple account or network access.