{"id":47269,"date":"2025-04-01T16:22:54","date_gmt":"2025-04-01T20:22:54","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=47269"},"modified":"2025-07-14T13:47:06","modified_gmt":"2025-07-14T17:47:06","slug":"xcode-16-3","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2025\/04\/01\/xcode-16-3\/","title":{"rendered":"Xcode 16.3"},"content":{"rendered":"

Apple<\/a> (security<\/a>, downloads<\/a>):<\/p>\n

Clang now defines TARGET_OS_*<\/code> conditionals as built-in macros based on the provided target triple.<\/p>

[…]<\/p>

Searching in the documentation viewer may start an indexing process which makes no progress. This may result in missing search results and increased CPU usage.<\/p>

[…]<\/p>

Fixed: Foundation encoders\/decoders user info dictionaries now require Sendable<\/code> values. This may cause build errors even in the Swift 5 language mode in small edge cases where the userInfo property is set to a value like init(myCustomInitializer:)<\/code> where the initializer is defined in an extension on Dictionary<\/code> with a Value == Any<\/code> constraint.<\/p>

[…]<\/p>

Instruments 16.3 includes a new Processor Trace Instrument which uses hardware-supported, low-overhead CPU execution tracing to accurately reconstruct execution of the program.<\/p>

[…]<\/p>

In Xcode when you are in a test context you are now able to query for your test plan name and scheme name in the environment with the keys XCODE_TEST_PLAN_NAME<\/code> and XCODE_SCHEME_NAME<\/code>.<\/p>

[…]<\/p>

xcodebuild<\/code> supports constraining the tests run through tests actions by tags. Use -only-testing-tags<\/code> to include tests identified by a tags and -skip-testing-tags<\/code> to omit tests identified by tags.<\/p><\/blockquote>\n\n

There are also lots of C++ and Swift\/C++ improvements. It does not look like the issues with linking to certain frameworks on older versions of macOS (FB14667312<\/a>) or calling async functions bridged from Objective-C (134442168<\/a>) have been fixed yet.<\/p>\n\n

Xcode Releases<\/a>:<\/p>\n

\n

It is identical to RC2 that came out a couple of days ago.<\/p>\n<\/blockquote>\n\n

Matt Massicotte<\/a> (via Christian Tietze<\/a>):<\/p>\n

\n

No, dynamic isolation is not bad<\/strong>.<\/p>\n\n

But, I think we can also agree that static isolation is preferable<\/em>. If you find yourself using dynamic isolation solely because it is a familiar pattern, that’s something to think about more deeply. Static isolation is a safer, clearer way to express what you need. That doesn’t mean you can always or even should start with it. Adopting concurrency will be a long process. Dynamic isolation is a very handy tool for getting there, I just don’t think it should typically be an end-state.<\/p>\n<\/blockquote>\n\n

Rob Napier<\/a>:<\/p>\n

I’m wondering if there are changes to how DynamicActorIsolation works in Xcode 16.3. I’m seeing crashes due to running on a background thread that I don’t have with 16.2. The closure in question isn’t intended to be MainActor even though it’s defined in a View. With DynamicActorIsolation turned on, it seems to be getting MainActor assertions added, even if I mark it Sendable.<\/p><\/blockquote>\n\n

Paul Hudson<\/a>:<\/p>\n

If you upgraded to Xcode 16.3, be warned: there appears to be a simulator bug that causes network access to fail regularly. It doesn’t affect devices, just the simulator. You can work around it by using URLSession(configuration: .ephemeral)<\/code> rather than URLSession.shared<\/code>.<\/p><\/blockquote>\n\n

Previously:<\/p>\n