TL;DR
- Xcode 16 is coming in September 2024.
- Bitrise will make it available as a new stack on day one
- On this new stack, there will be some breaking changes compared to the Xcode 15 stacks
- We take this time as an opportunity to set modern tooling defaults and make often-requested changes that are breaking changes for some workflows
- Existing stable stacks (Xcode 14.x and 15.x) won’t receive these breaking changes
- Test & adapt with the already available Xcode 16.0 edge stack.
- Based on timelines in previous years, Apple will only accept apps built with Xcode 16 in the App Store starting from April 2025.
- Preparation is key to avoid failing builds on your workflows.
Timeline
- June 10, 2024: First Xcode 16.0 Beta release
- June 10, 2024: Xcode 16.0 Beta on Bitrise
- September 2024: Final Xcode 16.0 release
- September 2024: Xcode 16.0 on Bitrise as a new Stable stack
- April 2025 (estimate): App Store no longer accepts apps built with Xcode 15 or earlier
Why does this matter?
Our commitment has always been to ensure that our developers enjoy a seamless experience on Bitrise. However, with every major tool or version update, there is always a potential for disruptions, especially for workflows that have grown reliant on the specifics of an older stack.
Tooling is also constantly evolving, and we want to provide stacks that follow the latest best practices and set meaningful defaults. Additionally, certain tool versions are only supported for a given period, after which security fixes are no longer backported.
Throughout the year, we ship these possibly breaking changes to our edge stacks for early testers, and the stable stacks receive the breaking changes once a year when a new Xcode major version is released (as explained in our Stack Update Policy). Unanticipated or inconsistent stack updates can lead to broken builds that take time away from what you love to do the most - code and ship features.
Unlike in previous years, existing Stable stacks (Xcode 14.x and 15.x) won’t receive those breaking changes in September, only the new Stable stack based on Xcode 16.
Transitioning from Edge to Stable Stacks
The imminent release of the final Xcode 16 means we'll be transitioning from our current Edge stack to a Stable stack. This could present breaking changes for some workflows.
What exactly is the Edge stack?
Our stacks progress through a lifecycle consisting of four stages: Edge, Stable, Frozen, and Removed. An Edge stack, the first stage, gives users a glimpse of upcoming tool versions and features, serving as a testing ground for your workflows before they reach the Stable state.
Testing on Edge stacks empowers you to foresee potential breakages and strategize preventive measures. Regularly updated, Edge stacks incorporate the latest stable and beta Xcode releases, the most recent stable versions of pre-installed tools. Currently, our Edge stack is based on macOS Sonoma and the latest Xcode 16 Beta, as well as the various preinstalled tools and default versions we’ll elaborate on below.
Summary of changes and migration guide
General changes
macOS upgrade
This stack is based on the latest version of macOS Sonoma (macOS 14). If migrating from the Xcode 15.2 stack or earlier, this means a major OS version upgrade for you (the Xcode 15.3 and 15.4 stacks are already based on Sonoma).
Tuist
Tuist is now installed via its asdf-tuist version manager plugin. This means you can install additional versions with asdf install tuist 4.1.0 and set set as the active version with a .tool-versions file or with asdf global tuist 4.1.0.
Homebrew NO_DEPENDENTS_CHECK
Similar to the brew-install step’s new default behavior, the env var HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK=1 is also defined on stacks. This tweak helps the speed and reproducibility of brew install calls in scripts. See the step release notes for more details.
Default Ruby version: 3.3
The default Ruby version is now 3.3 (an alias to the latest 3.3.x version). The previous default, 3.2 remains preinstalled.
Ruby 3.0 removed
Ruby 3.0 has been removed as it’s no longer officially supported. You can manually reinstall it by running asdf install ruby 3.0.7.
Other tool upgrades
- Homebrew package upgrades: on Stable stacks, Homebrew packages are not upgraded after the initial release of a stack. When switching from a previous stable stack, you’ll see newer package versions. Our Edge stacks are updated weekly with the latest package versions, so you can check the Xcode 16.0 Edge stack report any time to get a snapshot.
- Ionic CLI 6.x → 7.x
- Cordova CLI 11.x → 12.x
- Appcenter CLI 2.x → 3.x
- OpenUPM CLI 1.x → 3.x
- The default Go version is
1.22. The previous default,1.21remains preinstalled. - Go 1.23 is now preinstalled
- Go 1.20 is no longer installed
Python 2
Python 2 is no longer installed. pyenv, a Python version manager is still installed, so you can reinstall Python 2 at your own risk.
Related: pipx, a tool to install Python executables is now installed and configured on stacks.
Android
JDK 17 is the new default version
To better align with modern Android Gradle Plugin versions, JDK 17 is now the default Java version on stacks.
JDK 11 remains preinstalled and you can use the Set Java version step to switch.
JDK 8 is no longer preinstalled.
Android command-line tools
The Android SDK’s cmdline-tools package has been upgraded to the latest stable version.
cmdline-tools was previously installed (incorrectly) to $ANDROID_HOME/cmdline-tools/cmdline-tools, this is now fixed (the tools are at $ANDROID_HOME/cmdline-tools/latest/bin).
Android NDK
The previously installed NDK version, 24.0.8215888 has been replaced with the current LTS version, 26.3.11579264.
You can use the install-missing-android-tools step to install another NDK version.
Previously, the NDK package was incorrectly installed to the $ANDROID_HOME/ndk-bundle directory, this is no longer the case.
The env vars ANDROID_NDK_HOME and ANDROID_NDK_VERSION are no longer defined as modern Android Gradle Plugin versions don’t rely on them.
System-wide Gradle and Maven
Gradle and Maven are no longer installed system-wide as most projects use the Gradle Wrapper and Maven Wrapper to execute a pinned version of the build tools.
React Native
Node.js 20 is the new default version
Node 20 (LTS) replaces Node 18 (previous LTS) as the default version. Node 18 is no longer preinstalled, but you can manually install it by running asdf install node 18.20.3.
Node 22 (the upcoming LTS release) is also preinstalled.
Corepack
Corepack is now enabled for all installed Node.js versions. This means that you no longer need to install Yarn or pnpm manually if your project uses these dependency managers. As long as the package.json contains a packageManager field with a package constraint like [email protected], any script step invoking yarn (or pnpm) will trigger Corepack that automatically downloads and caches the required version manager.
Flutter
Default Flutter version
The preinstalled Flutter version has been upgraded from 3.7.12 to 3.22.0.
The Flutter Install step can be used to prepare the exact version that your project depends on.
Preparation is key: Test with the Edge stack
We cannot emphasize enough the importance of proactive testing using our Edge stacks. The Xcode 16.0 with edge updates stack is already available on Bitrise.
Testing on these Edge stacks will provide insights into how your workflows might be affected once the Stable version with Xcode 16 rolls out. This proactive approach will not only allow you to identify and resolve issues beforehand but will also give you peace of mind and more time to adapt to the forthcoming changes.
For more information, please check out our Stack Update and Stack Deprecation policies.
Helping your transition: Dedicated support
Changes, especially major ones, can be daunting. But remember, our primary goal is to offer you an enhanced experience, and sometimes that means evolving alongside industry updates. If you find yourself facing any issues or uncertainties, our dedicated Customer Support team is always there to help you!
