Xcode 12.1.1 (RC) Released

[sschneid]

The Xcode 12.1.1 (Release Candidate) image has just been released and can be selected as follows:

macos:
    xcode: 12.1.1

---

Image Info

Xcode 12.1.1 Build version 12A7605b is installed at /Applications/Xcode-12.1.1.Release.Candidate.app

The following runtimes are installed:

• iOS 13.7
• iOS 14.2
• tvOS 13.4
• tvOS 14.2
• watchOS 6.2
• watchOS 7.1

The full manifest of installed software can be found here.

---

edit: updated tag to 12.1.1.

[danl3v]

Thanks for this update. Is there a way we can choose to opt into these updates instead? Being forced to update breaks our pipeline as we lock in our version of xcode developers can use to make sure our pipeline is stable. Thanks!

[danl3v]

I also tried to select 12.1.1 in the circle config and got this error. Can you allow folks to select 12.1.1 in the circle config so that people it can be clear as to what our tooling is? This release from circle is a major change from the way circle has done updates in the past when there was a grace period to update to newer patch versions

Build-agent version 1.0.43515-46fef117 (2020-11-05T22:27:13+0000)
Preformatted text`Creating a dedicated VM with xcode:12.1.1 image
failed to create host: Image xcode:12.1.1 is not supported

failed to create host: Image xcode:12.1.1 is not supported

[sdaniel55]

What was the reason for updating 12.1.0 to 12.1.1, without updating the config file? Our project’s pipeline got blocked because of this change, since we explicitly check the Xcode version before running tests, and now it’s not matching.

[james-rantmedia]

This has broken our build without any warning. We specify 12.1.0 in our config and we were relying on the 14.1 simulator to be available for our tests. Now that sim is gone, replaced with 14.2. Why does the 12.1.1 get selected when specifying 12.1.0? Is there a way we can prevent this in the future?

[gemmakbarlow]

Confirming that this has also caused CI breakages for us overnight. I’m guessing the config issue is due to an error - please revert and have this be opt-in.

[backslash-f]

Yep, looks like an error to me. 12.1.0 should be != from 12.1.1 ¯_(ツ)_/¯
It’s also breaking some of our pipelines.
Please revert.

[sdaniel55]

Update: tried again after seeing the updated tag, the issue is still happening. Even though 12.1.0 is defined in our config, the jobs use 12.1.1 version of Xcode.

# .circleci/config.yml
macos:
      xcode: "12.1.0"

Creating a dedicated VM with xcode:12.1.0 image

[15:58:09]: $ xcversion selected
[15:58:11]: ▸ Xcode 12.1.1
[15:58:11]: ▸ Build version 12A7605b
[15:58:11]: Selected Xcode version is not correct: 12.1.1. You expected 12.1.0.

[thekatertot]

Thanks everyone for your patience! We’re working on this, and will update here as soon as we can.

[shawnce]

It may be helpful to install iOS 13.7 simulator support in the 12.1.0 image in addition to the the iOS 13.5 support that was added. This would make a little easier forward compatibility with XC 12.1.x and XC 12.2 which appear to now have iOS 13.7 available (it is now available for XC 12.1.0, wasn’t at first I believe).

[sschneid]

Hello, thanks for your patience on this issue. Per our published Xcode patch policy:

We retain the latest patch version of each Xcode major.minor version we support. Once a new patch version has been released, we will deprecate the previous patch version and redirect all requests to the new patch.

As patches are generally backwards compatible, redirects will be put in place within 24 hours of a new patch release. If any major issues are discovered, we will issue a rollback and make both versions temporarily available.

It looks like Apple has introduced a new iOS simulator version (iOS 14.1 has been replaced by 14.2 in this z-release), so we’ve temporarily re-enabled our Xcode 12.1.0 image under the 12.1.0 tag in order to help ease customer transition to Xcode 12.1.1.

To summarize, for the next week:

• 12.1.0 will point to the Xcode 12.1 GM seed image
• 12.1.1 will point to the Xcode 12.1.1 Release Candidate image

In addition, we’ve added a support article on resolving “Path /Applications/Xcode.app doesn’t exist” errors to our knowledge base to assist in avoiding pipeline errors across Xcode releases.

Please note that 12.1.0 will be deprecated and automatically redirected to 12.1.1 starting on November 13th, 2020.

Thank you again for your feedback and patience!

[danl3v]

Thanks for reverting the change. When was this patch policy introduced? I do not recall being alerted of this change. I think it is also safer to offer a grace period to allow for opt in upgrades - say 5 business days. After that, I think it would be fine to force redirect folks with an announcement.

You are a CI provider and your job is to enable people to have a stable pipeline, so force upgrading folks when patches are “generally backwards compatible” is honestly not good enough. This policy negatively impacts my team as builds can break any time due to Xcode changes without our control, and this revert has broken our pipeline again as now we have to update our circle config to point to 12.1.1

Please offer your customers stability by at least giving some grace period to upgrade as you have done in previous years

[bytesguy]

Thank you for your feedback everyone and apologies for the inconvenience caused in this instance.

To answer some of the queries:

The Xcode Image Policy was put in place at the beginning of October

New Xcode Image Policy Doc

Hello everyone! As I am sure many of our macOS executor users has seen, Apple has certainly been powering through Xcode releases and betas at a fast pace over the past year, and it appears to show no sign of slowing. To ensure we are able to continue supporting as many versions as possible, along with releasing new images quickly, we have decided to create and release our new Xcode Image Policy document which is now available for viewing: If you are a frequent user of the macOS execu…

Due to the recent rapid increase in Apple’s release schedule over the past year, we created the new public policy to ensure we can continue to support the latest and greatest Xcode releases quickly, whilst retaining as much backwards compatibility as possible. For an idea of scale, including betas and GMs, the Xcode 10 series (June 2018 → July 2019) had a total of 19 releases, while Xcode 11 (June 2019 → August 2020) had 30 releases and Xcode 12 (June 2020 → Present) has already reached 16 releases so far.

The vast majority of the policy ratifies the internal policies we have been following for some time, but puts into place clear guidance for customers including timelines to make sure we are all on the same page moving forward into the next year of releases from Apple.

In terms of history of dropping older patch versions, we have run through this a few times already without receiving any reports of issues both here on Discuss and via support tickets. Examples of these are when we dropped 11.3.0 and 11.4.0 in favour of 11.3.1 and 11.4.1 and dropped 12.0.0 in favour of 12.0.1. We will never automatically redirect a minor version of Xcode - this only applies to patch versions.

In this instance, it appears Apple has included changes that are more major than expected for a patch release, breaking the notion of semver. We will certainly be taking this feedback on board and introducing additional testing and checking to ensure changes to simulator support, for example, are minimal before automatically replacing a patch release and reviewing the deprecation timeline based on changes included. This should allow us to improve clarity around future Xcode patch releases.

Once again, thank you for sharing your views on this - we really do appreciate it!

[danl3v]

Thank you for the response and taking our feedback into account!