Xcode 16 known issues

With the release of a new Xcode version 16, developers often encounter a range of bugs and unexpected issues that can disrupt their workflows. At Bitrise, we understand the critical importance of maintaining seamless development processes; that’s why we are committed to supporting the developer community by sharing known issues and viable workarounds. Leveraging our extensive experience working with thousands of companies, we have the unique advantage of quickly identifying common problems and effective solutions. By disseminating this valuable information, we aim to help you as developers navigate the intricacies of new Xcode updates more smoothly. This is a living document of known issues when building with Xcode 16, if you have something to share just add it to the list. the more the merrier.

Last updated based on Xcode 16.0 RC1 (16A242)

Issue with Bitcode on TestFlight builds

Uploading to Apple TestFlight fails validation with an error saying that frameworks are compiled with bitcode, which isn’t allowed. The issue only happens on Xcode 16 RC when bitcode is implicitly set, builds on Xcode 15 should work without problem. Diving in a bit deeper we see some interesting behaviour: for reported frameworks, the generated IPA symbols contains no LLVM symbols where they should exist. This can be tricky because some out of date libraries or dependencies still have bitcode and can’t be updated quickly. It looks like Xcode 16 RC has stricter bitcode validation compared to Xcode 15. The workaround is to strip bitcode of framework before building.

xcrun bitcode_strip -r YourFramework.framework/YourFramework -o YourFramework.framework/YourFramework

If you use Cocoapod you can utilise the following workaround.

post_install do |installer|  

  bitcode_strip_path = `xcrun --find bitcode_strip`.chop!
  def strip_bitcode_from_framework(bitcode_strip_path, framework_relative_path)
    framework_path = File.join(Dir.pwd, framework_relative_path)
    command = "#{bitcode_strip_path} #{framework_path} -r -o #{framework_path}"
    puts "Stripping bitcode: #{command}"
    system(command)
  end
  
  framework_paths = [
    "Pods/LibraryA/LibraryA/dynamic/LibraryA.xcframework/ios-arm64_armv7/LibraryA.framework/LibraryA",
    "Pods/LibraryB/LibraryB.xcframework/ios-arm64_armv7/LibraryB.framework/LibraryB"
  ]

  framework_paths.each do |framework_relative_path|
    strip_bitcode_from_framework(bitcode_strip_path, framework_relative_path)
  end
end

Unable to run Danger on XCode 16 RC

Running Danger on Xcode 16 RC simply fails with Dangerfile eval failed at Dangerfile.swift error . There is no workaround at the moment we suggest you to follow the issue conversation at Dangerfile cannot be compiled when using Xcode 16 · Issue #615 · danger/swift · GitHub

Improve build time by disabling module verification

This isn’t a regression but an optimization technique. If your project is stable you can disable module verification to speed up compilation time. Andrade explains that module verification, a process intended to ensure the integrity of compiled modules, can significantly increase build times, particularly in large projects. Swift Build Times and Module Verification…

Runtime crashes on Swift 6

Your apps may experience runtime crashes Swift concurrency and @MainActor . Specifically it is a problem where the attribute fails to properly enforce main-thread execution, leading to potential concurrency issues. There is no fix at the moment we suggest you to follow the issue conversation at Incorrect actor isolation assumption across Swift 5/6 module boundary leads to `dispatch_assert_queue` crashes · Issue #75453 · swiftlang/swift · GitHub

Potential memory issue with iOS simulator on Xcode 16 RC

One of our customers reported that iOS simulator on Xcode 16 RC consumes all machine memory thus throws errors on test runners. Memory usage simply spikes for no reason. We are actively investigating this, so far we suspect it’s related to incorrect permission on /tmp folder and memory swapping.

2 Likes