Xcode Tips and Tricks Group Lab

Transcript

Engineers from the Xcode team introduce themselves — noting Xcode is built with Xcode — and set up a session on lesser-known tips, project structure and merge conflicts, running multiple Xcode versions, build performance, previews, debugging with LLDB, source control, and code signing.

A round of lesser-known favorites. The #Playground macro (added last year) lets you drop a runnable snippet into any Swift file — import Playgrounds, write code, and see expression results inline, including previewing UI or trying Foundation Models; File > New > Playground scaffolds one. New this year, per-workspace themes let you color-code different projects so they're easy to tell apart. A hidden file-management trick: cut the code you want to move, focus the file navigator, and paste — Xcode creates a new file and names it from the content (paste struct Person and get Person.swift). Find Call Hierarchy quickly shows where a function is called from, several levels deep — handy when refactoring Objective-C to Swift. And Command-Shift-J reveals the current file in the navigator; combined with Open Quickly on a symbol, it jumps you right to where that symbol lives.

Synchronized folder references ("blue folders") — they largely eliminate the project-file merge conflicts that plague large teams, since files added or removed on disk no longer require hand-edited .xcodeproj changes. Many projects haven't adopted them yet, and doing so meaningfully cuts conflicts.

The team welcomed the appreciation for the new Delete Derived Data menu item, which replaces years of manually deleting folders, running Terminal commands, or maintaining custom scripts — a small quality-of-life win in everyday workflows.

Yes, you can run both. The main caution is to stick to features from the already-shipped public SDK for apps you submit, so your production app keeps building and remains App Store-eligible while you experiment with the beta.

A grab-bag of underused capabilities. Beyond converting groups to blue folders (to cut project conflicts), you can pin individual canvas tabs — new this year — so a SwiftUI preview stays live while you navigate other files. Breakpoints can play a sound instead of pausing. Xcode Cloud is easy to miss and easier than ever to set up directly in Xcode this year, with improved onboarding and built-in webhook configuration. Xcode's search navigator is more powerful than most realize: regular-expression and proximity search, combining the search field with the bottom filter for Boolean-style queries, pressing Delete to remove results from the set, Command-clicking a disclosure triangle to collapse siblings and see all file names, and type-hierarchy queries up to the root or down to subtypes. And the profiling tools — Instruments' flame graph paired with top functions, plus dedicated SwiftUI, concurrency, and Foundation Models templates — reward a look.

Generally you're fine — the team routinely runs many Xcode versions across many macOS versions. Keep the versions in separate app bundles, be mindful that command-line tools selection (xcode-select) points at one version at a time, and build production apps against the shipping SDK.

Use synchronized folder references so adding or removing files no longer edits the project file, which is the primary source of these conflicts. That built-in mechanism addresses most of what teams reach for Tuist or XcodeGen to solve, without adding a project-generation tool to your pipeline.

Xcode 27's Markdown support is genuinely useful for in-project docs and notes. On source control, the panel acknowledged the multi-select-on-stashes request as reasonable and encouraged filing Feedback, since specific workflow gaps like that are exactly what they prioritize from developer reports.

The re-approval on macro changes is a deliberate security prompt, but the team recognized the CI friction of re-approving on every update. They treated pinning trust to a package identity as a valuable enhancement request and encouraged filing Feedback, since macro trust is security-sensitive and evolving.

Not directly today. A workaround is to open Terminal and drag a file reference from the navigator into it to change to that directory. The panel liked the idea and suggested filing it as a Feedback request for a built-in "open Terminal here" action.

Favorites included Shift-Command-J to reveal the current file in the project navigator, Command-Shift-O for Open Quickly to jump to any symbol or file, Command-Control-arrow for navigating back/forward, and the Command-click menu on symbols for jump-to-definition and refactoring — small shortcuts that compound into much faster navigation.

The most common is trying to learn every feature at once — Xcode is a large, capable workhorse. Focus on the core edit-build-run-debug loop first and add features (Instruments, source control, previews) as you need them, rather than being overwhelmed by everything the app offers up front.

The panel was candid that documentation discipline is hard to keep up. The practical path is to write DocC comments as you build (documentation lives next to the code), build the DocC archive periodically to catch gaps, and treat docs as part of the change rather than a separate later pass so they don't drift from the implementation.

Understand what's actually slow first — use the build timeline to find bottlenecks. Common wins: keep modules well-factored, watch for expensive type inference in Swift (add explicit types to slow-to-check expressions), minimize unnecessary work in build phases, and avoid gratuitous clean builds. Measure before changing settings so you target the real cost.

Preview speed tracks overall build performance, so the same build-time improvements apply. Beyond that, keep preview targets small and dependencies lean so the preview build is fast, and structure previews to render focused subviews rather than the whole app, reducing what has to compile and launch for each preview.

Running a formatter in a build phase that rewrites files Xcode has open causes those "contents changed on disk" alerts. Prefer formatting outside the live-edit loop — for example on commit via a git hook, or as a separate command rather than an every-build phase — so the formatter isn't rewriting files while you're actively editing them.

Use breakpoint actions that don't halt: attach a log or debugger-command action and enable "automatically continue after evaluating," so you observe state as it changes without pausing. The Sound action gives an audible cue when a breakpoint hits, and Watchpoints let you break specifically when a variable's value changes — powerful for tracking down unexpected mutations.

It depends on what the compiler can prove via static analysis. Unused local variables produce warnings because the compiler can reliably determine they're unused. Unused properties or functions are much harder — they could be referenced dynamically, via Objective-C, or from other modules — so Xcode can't reliably flag them without risking false positives.

Deleting DerivedData isn't a superstition — it clears stale build products and indexes that can cause genuinely confusing failures, and Xcode 27's menu item makes it convenient. But reach for it after cheaper steps: check the actual error, try a clean build folder, and verify your settings first, rather than nuking DerivedData reflexively as step one.

The team welcomed this as concrete feedback. Writing an AGENTS/CLAUDE.md to re-ground the agent is a reasonable workaround today, and they took the requests — a visible context-compression indicator and a pause-before-editing safeguard — as valuable enhancement ideas worth filing so agent sessions are more transparent and safe.

Lean on automatically managed signing where possible so Xcode handles profiles for you, and use shared build configurations and xcconfig files so signing settings are defined once rather than per target. For repeated Instruments/testing flows, configure the scheme and configurations so you aren't hand-switching profiles each time. File Feedback for the specific multi-target pain points.

Xcode offers code folding (Editor menu and the folding ribbon) and the minimap/structure for navigation, but fine-grained control to hide categories of "noise" is limited. The panel saw this as a strong enhancement request and encouraged filing Feedback describing the desired focus-oriented folding behavior.