Xcode 14
Xcode 14 includes Swift 5.7 and SDKs for iOS 16, iPadOS 16, tvOS 16, watchOS 9, and macOS Monterey 12.3. The Xcode 14 release supports on-device debugging in iOS 11 and later, tvOS 11 and later, and watchOS 4 and later. Xcode 14 requires a Mac running macOS Monterey 12.5 or later.
As with last year, the release version of Xcode removes the beta SDK for this fall’s macOS update.
Xcode 14 is identical to the release candidate last week.
Previously:
- Swift 5.7
- Xcode Cloud Subscriptions Now Available
- Xcode 14: Swift Package Plug-ins
- Xcode 14: High Sierra and Later
- Xcode 14 Announced
- Xcode 13 RC
Update (2022-10-10): Jesse Grosjean:
Love the idea of showing code structure while scrolling, but I’m having a hard time getting used to the reality of all the flickering. Anyone else have that problem? Did you get used to it?
One nice touch with the Xcode sticky headers is that it also rolls up multi-line function declarations into the header 👏🏻
In Xcode 14, if you select a block of text and type
{, it embeds the block in a closure and puts the cursor in the beginning of the closure so you can define it. Works great for SwiftUI!
In Xcode 14 optional parameters don’t get autocompleted by default. And I only realized after watching the overview by @seanallen_dev that we can still get all the parameters by holding the option key or get only some by starting to type their names.
Leo:
Is it just me - or Xcode 14 is simply unusable at this point? Because new
IBOutletproperties are not recognized in Interface Builder.(Outlets created in pre-14 Xcode versions do appear in Xcode 14 but with a warning sign with a tooltip claiming that outlet doesn’t exist).
It’s been many years since I don’t understand what any of the options meant and the only appropriate action is “Force Quit”
The option you want is always “use version on Disk”, except that option doesn’t actually work so you need to close and reopen the project anyway
The following code works on iOS, but crashes on macOS. I believe this is because of SE-0338 combined with the lack of
@_unsafeInheritExecutorin the macOS stdlib included with Xcode 14. In my view, Xcode 14 is unsafe to use for macOS until this is fixed (presumably when Xcode 14.1 includes the macOS 13 SDK with the 5.7 stdlib)
If you don’t mind my asking, was this bug known inside Apple before the final release of Xcode 14.0? Or were Apple folks surprised because nobody thought through the implications of matching the Swift 5.7 compiler with the Swift 5.6’s standard library module interface? Or was it known but not considered as a serious issue?
[…]
I’m asking because the compiler generating code that breaks concurrency invariants is a serious problem, and I’m surprised by the lack of communication from Apple about it[…] In my opinion, something like this warrants a big red warning at the top of the release notes: “Don’t use Xcode 14.0 to build macOS targets that use concurrency!”
Update (2022-10-13): Ole Begemann (tweet):
Mac apps built with Xcode 14.0 and 14.0.1 may contain concurrency bugs because the Swift 5.7 compiler can generate invalid code when targeting the macOS 12.3 SDK. If you distribute Mac apps, you should build them with Xcode 13.4.1 until Xcode 14.1 is released.
[…]
Third-party developers had little chance of discovering the bug during the Xcode 14.0 beta phase because the betas ship with the new beta macOS SDK.
2 Comments RSS · Twitter
Strangely enough I can still without warnings compile with "macOS 10.12" as a deployment target and successfully run the result on OS X 10.12. It didn't work in the Xcode 14 betas but it does with Xcode 14 final although the release notes still state that "Building for deployment to OS releases older than macOS 10.13, iOS 11, tvOS 11, and watchOS 4 is no longer supported. (92834476)"
