Xcode 8 Tips and Issues

Sash Zats:

Amazing tip from Xcode labs: add a EXCLUDED_SOURCE_FILE_NAMES build setting to conditionally exclude sources for different configuration.

Dave DeLong:

There’s also an INCLUDED_SOURCE_FILE_NAMES, and they can be used together (exclude that, but include this).

Daniel Jalkut:

A major change from Xcode 7 is that Xcode now requires that every target in your project specify a development team, even when the manual code signing option is selected.

[…]

The new PROVISIONING_PROFILE_SPECIFIER build setting will impart the desired team information to Xcode, even if provisioning profiles are not used.

[…]

This doesn’t exactly solve the challenge for open source projects, because organizations using an open source project will still have to override the configuration file or build settings for the projects they check out.

Daniel Jalkut:

So, the fix in Xcode 8, with the 10.12 SDK, is to delete those parentheses so Swift appreciates that it’s accessing a property. But doing so will break the build back on the 10.11 SDK. What’s a forward-looking, backward-looking developer to do?

[…]

Unfortunately, I think the only way to convince Swift to absolutely ignore the problematic line is to use a Swift compiler check, instead. Note that this is a bad solution because we are fundamentally not concerned about the version of Swift being used.

[…]

In my opinion, we need a compile time, conditional code exclusion that operates on the SDK, similarly to #available. Something like “#if sdk(OSX 10.12)”. As far as I know, nothing like this exists.

Russ Bishop:

Source Extensions have several capabilities and are organized around commands. Each extension can provide a list of commands in its plist file or via an override of XCSourceEditorExtension. Each command specifies what XCSourceEditorCommand subclass implements the command, the name on the menu, and a unique identifier. The same class can implement several commands by switching on the identifier.

[…]

The first parameter is an XCSourceEditorCommandInvocation. That invocation has the contents of the editor’s text buffer (either as a single string or as an array of lines). It also has the selections, and each selection has a start and end that tell you the line and column (which can be used to index into the text buffer’s lines array). If nothing is selected, the single XCSourceTextRange in the array will have the same start and end point representing the insertion point.

See also: WWDC Session 414: Using and Extending the Xcode Source Editor.

Update (2016-06-23): Jay Graves:

Xcode 8 brings the dark art of customized code signing and provisioning profiles into the light for all to see. Instead of being buried in the Build Settings, Code Signing is now displayed front and center in the General tab. When “Automatically manage signing” is unchecked we can specifically select the provisioning profile we wish to use for each Configuration. Now this in itself is nothing new, we have always been able to do this in the Build Settings tab. The awesome sauce comes in with the smarts that Xcode 8 displays here. The drop down list of profiles now groups the Eligible profiles above the Ineligible profiles. Meaning that profiles that match the bundle identifier absolutely or with a wild card will be displayed above any profiles that don’t match at all.

[…]

The Xcode team has included a new report in the Report Navigator that outlines everything Xcode does on your behalf related to code signing.

Update (2016-06-29): James Thomson:

Xcode 8 no longer supports iOS 7 as a deployment target, so if you add support for iOS 10, you’ll lose iOS 7 support.

Matt Gallagher:

I took a break from converting projects to Swift 3 this weekend and instead played around with writing a new “Source Editor Command” extension for Xcode 8. The result is an extension that detects and corrects whitespace issues. It’s a topic I’ve touched on before because I’m frustrated by the continuous burden of correcting whitespace in my projects. I wanted to see if an Xcode source extension could reduce my annoyance with this issue.

The fun part of this exercise for me was writing a pushdown automaton parser where all of the parser logic was expressed through the case patterns of a single Swift switch statement. Accordingly, most of this article is not really about Xcode Source Editor Command extensions or whitespace issues but is actually about design choices related to large, complex switch statements in Swift: choosing data types to switch upon, designing case patterns to handle a deep decision tree in a single switch statement, when to use custom pattern matching and when to use where clauses.

Update (2016-10-14): Russell Ivanovic:

To stop the Xcode 8 iOS Simulator from logging like crazy, set OS_ACTIVITY_MODE = disable in your debug scheme.

Code Signing Extensions iOS iOS 10 Mac macOS 10.12 Sierra Parser Programming Swift Programming Language Xcode

2 Comments RSS · Twitter

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ