Xcode 26 RC

Build Environment Mobile
1

Hello,

Xcode 26 RC is available.

When would it be available in CircleCI?

Thanks.

9 Likes
2

No answer from anybody at CircleCI? iOS 26 released today, we still don’t have access to a RC to produce our App Store builds. Not even a suggestion of when they will make it available.

3 Likes
3

Every fucking time.

9t4sxm
9t4sxm500Ă—676 126 KB

3 Likes
4

+1. Could we please get an update of some sort of timeline when CircleCI will support Xcode 26?

1 Like
5

Working on it right now. Target is EOW. Apologies for the delay.

4 Likes
6

Given that MacOS complications were the source of the delay last time CircleCI was unable to produce an updated Xcode image - does the jump from MacOS 15.5 to 15.6 have something to do with the delay here?

Would CircleCI be willing to consider pursuing MacOS updates separately from Xcode, with an eye towards being as up-to-date as possible? This would allow MacOS related complications to be identified as soon as possible, rather than having them impact CircleCI users who have a reasonable expectation of being able to use recent Xcode releases in CI builds.

7

Looks like the 26 final release image just got deployed (right in the middle of one of my workflow runs). Ruby version has again been bumped (now 3.4.6). Confirmed via SSH:

VM-923cfc5335:~ distiller$ xcodebuild -version
Xcode 26.0
Build version 17A324

8

I’m finding jobs are either queuing for a long time or spending many minutes on the “Preparing environment” step - is this just a consequence of the new images rolling out?

9

looking into preparing environment thing, will get back to you soon

1 Like
10

@lukeredpath it’s a function of this being a new image. the underlying infra that scales out machines takes a little bit of time to “learn” the new “SKU” (image + execution env combo)

it should get better over time especially as more users start leveraging the new image. message here if it still persists for a long time.

2 Likes
11

Hello.
Xcode 26 GA has been released. The job queue times have also returned back to normal following a new image release as Sebastian has described.

4 Likes
12

I’m still seeing long environment preparation times here.

13

@lukeredpath looking into prep times.

Unrelated to the environment preparation times mentioned above, we’ve also seen reports from our users hitting an OS issue (outlined here) with XCode 26 where the device id is changing across VMs. We’ve opened a support ticket with Apple and encourage you to do so as well if you are hitting it.

14

Hello
The distribution of the image has been completed. We are observing preparation times that match our intended times.
Please check again when you get the chance.

1 Like
15

I’m also still seeing quite long environment preparation times

16

Seems better this morning though. Fingers crossed :crossed_fingers:

17

@neilsardesai yes the issue that was causing slower start-up times was fixed last night, so it should work as expected now. Let us know if you notice more issues.

2 Likes
18

FYI that we’ve seen the iOS 26 simulator device hang indefinitely on startup roughly ~10% of the time. We have filed a support ticket with Apple. In the meantime, here is a workaround:

  1. The boot-simulator command takes in three parameters:

    1. device (“iPhone 17 Pro”)
    2. platform (“iOS”)
    3. version (“26.0”) NOTE: this must be quoted to coerce it to a string data type in yaml

  2. Using homebrew, add the coreutils package. This installs the timeout command.

  3. Using the parameters, a device UDID is determined. if one can’t be found, the step fails

  4. The simulator is booted. If it hasn’t succeeded (the boot command returns without exit) in 60 seconds, then the simulator is force shutdown. After a brief timeout it will retry.

For this to work, any tools or frameworks that connect to simulators will need to ensure they are set up to boot the same device that this workaround starts up.

Here’s the command that can be added to a CircleCI YML config and further customized:

commands:
  boot-simulator:
    parameters:
      # i.e. "iPhone 17 Pro"
      device:
        type: string
      # i.e. "iOS"
      platform:
        type: string
      # i.e. "26.0" (ensure quoted to coerce value to string)
      version:
        type: string
    steps:
      - run:
          name: install coreutils (provides timeout utility)
          command: brew install coreutils
      - run:
          environment:
            SIM_VERSION: <<parameters.version>>
            SIM_DEVICE: <<parameters.device>>
            SIM_PLATFORM: <<parameters.platform>>
          name: Get Simulator Device UUID - <<parameters.platform>>-<<parameters.device>>
          command: |
            ESCAPED_VER=$(echo "$SIM_VERSION" | tr '.' '-')
            SIMREQ="${SIM_PLATFORM}-${ESCAPED_VER}"
            SIMLIST=$(xcrun simctl list -j)

            UDID_not_found() {
              # arguments: requested simulator, device
              SIMS=$(xcrun simctl list devices | tail -n +2)
              echo "ERROR!: UDID not found, check Platform, Version and Device"
              echo "Requested: Simulator: ${1}, Device: ${2}"
              echo "Available:"
              echo "${SIMS}"
              exit 1 
            }

            SIMREQ_not_found() {
              # arguments: requested simulator runtime
              echo "ERROR!: Simulator runtime not found"
              echo "Requested: Simulator Runtime: ${1}"
              echo "Available Runtimes:"
              echo "${SIMLIST}" | jq -r '.devices | keys[] | select(startswith("com.apple.CoreSimulator.SimRuntime."))'
              exit 1
            }

            if ! echo "${SIMLIST}" | jq -e ".devices | has(\"com.apple.CoreSimulator.SimRuntime.${SIMREQ}\")" > /dev/null; then
              SIMREQ_not_found "${SIMREQ}"
            fi

            UDID=$(echo "${SIMLIST}" | jq -r ".devices.\"com.apple.CoreSimulator.SimRuntime.${SIMREQ}\"[] | select(.name==\"${SIM_DEVICE}\").udid")

            if [[ -z "${UDID}" ]]; then
              UDID_not_found "${SIMREQ}" "${SIM_DEVICE}"
            fi

            echo "export UDID=${UDID}" >> "${BASH_ENV}"
      - run:
          name: Launch Simulator
          background: true
          command: |
            max_attempts=10
            attempt=1

            while [ $attempt -le $max_attempts ]; do
                echo "Launching Simulator (Attempt $attempt/$max_attempts)"
                
                if timeout -s SIGKILL 60s xcrun simctl bootstatus "${UDID}" -b; then
                    echo "Simulator Booted Successfully"
                    exit 0
                else
                    echo "Sim boot stalled. Powering down..."
                    xcrun simctl shutdown "${UDID}"

                    echo "Retrying in 5s..."
                    attempt=$((attempt + 1))
                    sleep 5
                fi
            done

            echo "Simulator Boot failed after $attempt attempts"
            exit 1
1 Like
19

@sebastian-lerner Any updates for a proper fix?

I tried using your workaround, but I could not figure out how to provide fastlane / xcodebuild with a list of UDIDs so that it will run tests in parallel. Calling xcodebuild with multiple -destination parameters runs all the tests on every destination, instead of spreading the tests across the multiple destinations. Can you think of a way I could make it work?

20

@xzoky Apple replied back to our bug report earlier this week requesting failure dumps for the VM and Simulator environments after hitting the bug. We passed those along and are waiting on a response. So we’re cautiously optimistic that they’re taking the bug report seriously and will have a fix out at some point.

For the test spreading out, i don’t have a good solution off the top of my head unfortunately. support.circleci.com may have an idea if you want to submit a ticket there. (Note the response time SLAs for support.circleci.com in case this is urgent)

1 Like