{"id":31516,"date":"2021-02-02T16:54:30","date_gmt":"2021-02-02T21:54:30","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=31516"},"modified":"2021-02-02T16:54:30","modified_gmt":"2021-02-02T21:54:30","slug":"xcode-12-5-beta","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/02\/02\/xcode-12-5-beta\/","title":{"rendered":"Xcode 12.5 Beta"},"content":{"rendered":"

Apple<\/a>:<\/p>\n

\n

Xcode 12.5 Beta requires a Mac running macOS Big Sur 11 or later.<\/p>\n

[…]<\/p>\n

The Reveal Build Products Folder item in the Product menu reveals the build products directory in Finder.<\/p>\n

[…]<\/p>\n

Code completion is more reliable in expressions that contain errors, and in expressions that are ambiguous without additional context.<\/p>\n

[…]<\/p>\n

Profiling XCTest with Instruments now automatically starts the recording, without a click on the record button.<\/p>\n<\/blockquote>\n\n

This would be great if it works, but profiling Mac unit tests<\/a> has been broken for me for years.<\/p>\n\n

\n

Incremental compilation is faster in many cases. When you change code within the body of a struct, class, enum, prototype, or extension, Swift now recompiles far fewer files in that module than before.<\/p>\n

Implicit member expressions now support chains of member accesses.<\/p>\n

Swift includes more checks when bridging data from Objective-C. In particular, the runtime library aborts your program with a suitable error message if it detects a non-nullable pointer that contains a null value.<\/p>\n

Property wrappers are now supported on local variables.<\/p>\n

Functions, subscripts, and initializers may now have more than one variadic parameter, as long as all parameters that follow variadic parameters are labeled.<\/p>\n<\/blockquote>\n

These are from Swift 5.4<\/a>.<\/p>\n\n

Antoine van der Lee<\/a>:<\/p>\n

While developing apps or framework it’s common to refactor a piece of code. Although often temporary, it’s common to run into failing tests while the code is still being refactored. Up until we could use XCTExpectFailure<\/code> I would disable those tests and only run them once I expected them to succeed.<\/em><\/p>

In other words, there are scenarios in which you realise a failure is expected. Without letting Xcode know this is true, your tests would report a failure and your CI would no longer report green.<\/p>

Another benefit is that Xcode will report a test as failed once an expected failure does not occur. You can see Xcode as a guard to make sure your tests match upon current expectations.<\/p><\/blockquote>\n\n

Previously:<\/p>\n