Xcode 14.3
Clang and the build system support a new mode for building module dependencies called explicit modules which improves build performance, reliability, and correctness. The new mode is opt-in, and can be enabled by setting
_EXPERIMENTAL_CLANG_EXPLICIT_MODULESas a user-defined build setting in C and Objective-C projects which build with modules enabled.[…]
Xcode now prompts a user prior to performing a clean action. This prompt can be bypassed by holding the option key while performing a clean, or by permanently hiding the prompt by enabling the “Don’t Ask Me” setting within the prompt.
[…]
Run scripts in a scheme’s pre-actions and post-actions for the Build section now cause the build to fail if any run script exits with a non-zero exit code, instead of reporting a false-positive successful build.
[…]
When a pre-build scheme action (such as compiling a package plugin) encounters an error, the status message at the top of Xcode’s workspace window sometimes doesn’t update. This leaves the previous status showing, possibly causing confusion if the previous status was “Build Succeeded.”
[…]
Xcode automatic signing now creates managed provisioning profiles for Developer ID. This resolves an issue that caused Xcode to throw an error when cloud signing with a Developer ID certificate during the app distribution workflow.
[…]
The
timeoutargument ofXCTestCase.wait(for:timeout:enforceOrder:)and related methods is now optional—if you don’t specify it, the function waits indefinitely (until the overall test times out.) To ensure reasonable execution time, set an appropriate value for theexecutionTimeAllowanceproperty of the runningXCTestCaseinstance (self).
The extra pieces can be downloaded here, though the Additional Tools are still only at RC status.
The two main changes I noticed are that there’s now an annoying animation when I use Open Quickly… and that tests now need a deployment target of macOS 12. This created a bunch of work silencing deprecation warnings, which is kind of silly because the code being tested runs on macOS 10.13 and so can’t depend on the newer APIs, anyway.
I had to turn off the new module verifier because it warned about double-quoted includes even though I had turned off that warning. (I use such includes to be able to use the same file both in a framework and when I want to include a few individual files in a standalone binary.)
TIL Xcode 14.3 Beta isn’t supported under Rosetta. This means that if your iOS project uses x86 libraries, you won’t be able to run the project on an x86 iOS Simulator on an arm64 mac anymore.
You’ll either have to go back to an x86 mac to run your project or you’ll have to add arm64 slices to your libraries.
New in Xcode 14.3: if you’re using
XCTestExpectationorXCTWaiterfrom an async Swift function, you’ll get warnings when usingwait(for:timeout:)because that synchronous function may deadlock. Switch to fulfillment(of:) instead for maximum Swiftiness!
If Xcode 15 released and the only feature was it was cured of hallucinating ghost errors I would stand up out of my chair and clap.
With the last several releases of Xcode, I’ve seen a lot of fake errors, as well as problems with builds not working properly unless I manually clean the folder first. The Swift compiler still crashes every day.
PSA: If you’re an Apple dev who hasn’t updated to Ventura for whatever reason, the usual trick of editing the Minimum system version in the Xcode 14.3 Info.plist seems to get it running just fine on Monterey.
Previously:
Update (2023-04-07): My experience so far is that Xcode 14.3 massively increases the number of fake compiler errors, and I’m also getting all sorts of weird crashes when running tests that go away if I clean the build folder. My guess is that there’s something wrong with the dependency tracking so that some files are not being recompiled, and the mismatch between old and new code interacting is causing crashes as well as unexpected test failures.
Kurt:
I have to build multiple times to see failures in Xcode 14.3. First build: failed, but no errors are shown. Second build: failed, errors are show for a few seconds then go away. Rinse and repeat until you can find the errors.
Update (2023-04-21): Christian Beer:
Xcode, I love you too…
I can’t upload NetNewsWire to Apple’s notarization service using Xcode 14.3 — Xcode complains about the profile not complaining a Game Center entitlement.
Sure. For obvious reasons.
But! I had kept a copy of Xcode 14.2, as you do, and it worked perfectly.
Sooo… I just discovered the latest version of Xcode may have fixed a compiler issue that was kneecapping my M1 Ultra.
There was an issue where on certain projects my Mac Studio would be as fast as my Intel iMac and SLOWER than an M1 MBP. The reason? Too many cores. If I limited to 4 cores it was faster than 20 (as in 90s vs 150-200s).
Just did a clean build today and… 20-30s. My Studio FINALLY feels as fast as it should! 😭
A change in compilers (whatever clang was in Xcode 14.0 vs. 14.3) + a more aggressive ARC memory release surfaced a stupid little bug in Acorn that nobody would have seen but me. It was caught in regression tests, and I was super confused for a long time, but … yay compilers getting smarter / faster / whatever?
Anyone else have Xcode 14.3 beach balling constantly?
Seems to be hanging on some XPC thing to do with text input?
This has happened to me several times. I’m also seeing hangs when I’m away from the office and it tries to check the source control status of a file but can’t reach the server on my LAN.
Previously:
Update (2023-05-01): Paul Haddad:
Anyone run into problems with Xcode 14.3 not auto-creating a proper CFBundleIcons~ipad entry? 14.2 doesn’t create it for simulator builds, but does create it for Archive. 13.4.1 creates it all the time.
Driving me nuts.
Xcode 14.3 has many problems. Also doesn’t work correctly in any CI/CD environment. Throwing random errors which are not related to the actual error. Need to downgrade to Xcode 13.x everything to get the real error. Driving me nuts.
I’ve been much happier since downgrading to 14.2, though it still shows lots of spurious errors.
9 Comments RSS · Twitter · Mastodon
@Ivan It’s off by default unless you opt in when it prompts you the first time you open the project after updating Xcode. I did that and found it caused problems so changed the setting to ENABLE_MODULE_VERIFIER = NO.
It seems that `-ffp-contract=on` is now the default in Xcode 14.3. This causes some tiny differences in floating point values that made several of my own unit tests fail.
On the subject of warnings that can't be silenced; I use clang mainly for compiling C programs on the command line. With the new clang version 14.0.3 and the command line option -Weverything, it always throws a -Wdeclaration-after-statement (when that is in the code) despite it being allowed since language standard C99. This happens regardless of the -std=... option which by default should be gnu17 (=C17 + GNU extensions). Work-around solution is to explicitly add the option -Wno-declaration-after-statement, or to use 'cc' or 'gcc' with options -Wall -pedantic to call the compiler (both are hardlinks in /usr/bin to Xcode clang). Disadvantage of using cc/gcc is that some other warnings, like alignment, are left out too.
My submission to Feedback: https://ee1.nl/code/clang-1403-warning-statement-declaration.png
On interesting regression(?) in Xcode 14.3 I found is that the SymLink command as part of the target dependencies build phase now uses relative paths instead of full paths to make symlinks.
This seemingly innocent change wound up breaking my python-based release build script. My script starts out by putting a lot of things in a temporary directory so I can ensure fully clean builds each time the script is called, and then zip everything up for archival purposes. The python tempfile.mkdtemp() stores items in /var/folders, which is really /private/var/folders/. As such the Xcode 14.3 SymLink command's relative path turns out to be incorrect (it is missing a ../), and when using a SYMROOT to the xcodebuild command, library dependencies do not resolve correctly and my builds fail!
I can workaround this either with Xcode 14.2 or by having my SYMROOT be in a resolvable path. Using temporary directories was nice though since my script didn't have to worry about cleaning up or managing conflicting names when invoked.
This was a fun change in a seemingly minor release I spent a ton of time investigating (and by that I mean not fun).
I think something else changed, too, because I’m now getting lots of failures running unit tests (FB12147053):
Assertions: System: Failed to create a bundle instance representing '[path].xctest'. Check that the bundle exists on disk.
The bundle actually is there. Sometimes cleaning the build folder or restarting Xcode helps, but sometimes it doesn’t.
I also had to downgrade to Xcode 14.2 because I could not reliably run unit tests in 14.3 more than once without Xcode crashing. First unit test run after launch would always work; every subsequent run had about a 50% of triggering some Xcode assertion failure.
How do you manage to develop and release applications with Xcode ?
My day job is with server side Python and Go but in 2016 I had an idea for an app, worked with Swift for several months and did a full prototype for my iPad, and I remember reading online lengthly discussions about a bunch of issues with Xcode and having several crashes during my "exploration".
Today I decided to explore another idea with my 2019 Intel MacBook Pro (16GB) and started with the official SwiftUI Apple tutorial, super basic but just to get the feeling of the current state of the platform...Xcode was slow (only two Safari tabs opened). I did half the tutorial went to get some water and when I returned the fans were at full speed and completely "frozen", I had to use the power button :-( . It really killed my excitement.
I am starting to wonder if the Kotlin tools for Android are much better than Apple's Xcode, any insights or experience about the quality of the tools at the other side?
I think Xcode has gotten better, but I also feel it has a long way to go in some areas. As an example, Swift's refactoring tools feel very limited compared to C#'s. (And while Swift's more powerful type inference — I'll call it "bidirectional" for lack of a better term — more elegant to read, it can be much more frustrating to write, as Swift's compiler gets very confused about what the error actually is. Swift feels "aspirational" in certain ways: with a much better IDE/compiler/static analysis, it would quite a good language, but for now, they hold it back a fair bit.)
For "this isn't a great release in terms of quality" cases, I use Xcodes; I can easily downgrade to a different release (assuming it's still supported).
In terms of performance, an ARM-based MBP will be about twice as fast (https://github.com/devMEremenko/XcodeBenchmark#xcode-130-or-above) as your model. But even then, I've found the SwiftUI Previewer to be annoyingly slow. Hopefully, that'll improve over time.
