When configuring connection pools in Vapor – whether for Redis, PostgreSQL, or other databases – you encounter a parameter called maximumActiveConnections. The natural assumption is that this sets the total maximum connections for your application. It does not. It sets the maximum per NIO EventLoop.

This distinction matters enormously in production.

The Math That Surprised Me

On a typical server, Swift NIO creates one EventLoop per CPU core. So the actual maximum connection count is:

actual max = maximumActiveConnections * CPU cores * number of dynos/instances

I had configured maximumActiveConnections to 8, thinking I was capping my Redis connections at a reasonable 16 across two dynos. The real number:

8 (per event loop) * 8 (cores) * 2 (dynos) = 128 potential connections

That is an order of magnitude more than intended, and it was exceeding my Redis provider’s connection limit during traffic spikes.

The Symptoms

The failure mode is particularly insidious: intermittent 500 errors that only appear under load. During normal traffic, you never hit the real connection limit, so everything works fine. During spikes, connections pile up across all event loops simultaneously, exceeding the provider’s limit. The errors look random and are difficult to reproduce locally because development machines typically have fewer cores.

How to Calculate the Right Value

Divide your provider’s connection limit by the total number of event loops across all instances:

// Provider limit: 40 connections
// 2 dynos * 8 cores = 16 event loops total
// 40 / 16 = 2.5, round down to 2

app.redis.configuration = .init(
   pool: .init(maximumActiveConnections: 2)
)

This conservative setting finally fixed the longstanding rare 500 errors in TranslateKit that had been puzzling me for months. Always check your cloud provider’s connection limits and do the multiplication before deploying.

There is a common belief in the developer community that filing Feedback Assistant reports (the successor to Radar) is pointless – that reports disappear into a void and nothing ever happens. I had a feature request implemented in Xcode 26, which proves otherwise.

Seeing a feature you requested show up in a keynote or release notes is a satisfying validation. But more importantly, it demonstrates that Apple’s engineering teams do review and prioritize community feedback, even when they never respond to the report directly.

Tips for Writing Effective Feedback

Not all reports are created equal. Here is what I have found increases the chances of a report being actionable:

Be specific about the problem. “Xcode is slow” is not useful. “Xcode’s SwiftUI preview takes 12 seconds to refresh when the file contains more than 3 #Preview blocks” gives engineers something to investigate.

Include a sample project. A minimal reproduction project is the single most valuable thing you can attach. If an engineer can build and run your project to see the issue, you have removed the biggest barrier to them investigating it.

Describe the use case, not just the solution. Instead of “add a button that does X,” explain why you need it: “When working with large SPM graphs, I need to quickly identify which target a file belongs to because…” This gives the team context to design the right solution, which might be different from what you imagined.

File during beta season. The weeks after WWDC are when Apple’s teams are most actively collecting feedback on new features. Reports filed during this window get significantly more attention than those filed in the middle of a release cycle.

Make It a Habit

Every WWDC beta season, set aside time to test your apps against the new OS and Xcode betas. File reports for every issue and every missing feature. Most will not get a response, but some will quietly influence future releases.

A pattern I see constantly in SwiftUI code is manually creating icon-only buttons by putting an Image directly inside a Button‘s label closure. It works visually, but it throws away accessibility information and fights against SwiftUI’s design.

The Wrong Way

Button {
   toggleSidebar()
} label: {
   Image(systemName: "sidebar.left")
}

This renders a tappable icon, but VoiceOver has no meaningful label to announce. The user hears something like “button” or the raw SF Symbol name, which is not helpful.

The Right Way

Button("Toggle Sidebar", systemImage: "sidebar.left") {
   toggleSidebar()
}
.labelStyle(.iconOnly)

Or using Label explicitly:

Button(action: toggleSidebar) {
   Label("Toggle Sidebar", systemImage: "sidebar.left")
}
.labelStyle(.iconOnly)

Why This Matters

The Label view carries both a title and an icon. When you apply .labelStyle(.iconOnly), SwiftUI hides the title visually but preserves it in the accessibility tree. VoiceOver will announce “Toggle Sidebar, button” – exactly what the user needs to hear.

This pattern also makes your code more adaptable. If you later decide to show text alongside the icon (for example, in a toolbar on iPad), you just change the label style to .titleAndIcon. No restructuring needed.

Beyond Buttons

The same principle applies to any view that accepts a Label: NavigationLink, Toggle, Picker, menu items. Whenever you are tempted to use a bare Image, ask yourself whether a Label with a style modifier would be more appropriate. In almost every case, it is.

When multiple people contribute to a Swift package, indentation inconsistencies creep in. One contributor uses 4 spaces, another uses tabs, a third uses 2 spaces. Pull requests become noisy with whitespace-only changes, and the codebase drifts toward an inconsistent mess. The fix is a single file that takes 30 seconds to add.

The .editorconfig Standard

EditorConfig is a widely supported standard for defining coding style settings per project. Xcode respects .editorconfig files, so contributors automatically get the correct indentation settings when they open the project – no manual configuration, no documentation to read.

Here is the .editorconfig I recommend for every SwiftPM package:

root = true

[*.swift]
indent_style = space
indent_size = 3

[*.{yml,yaml,json}]
indent_style = space
indent_size = 2

The 3-space indent for Swift is an intentional choice. It is less common than 2 or 4 spaces, but it hits a sweet spot: more readable than 2 spaces for nested closures, less wasteful of horizontal space than 4 spaces. Once you try it, the standard choices start to feel either too cramped or too spread out.

Why This Beats Global Settings

Every developer has their own Xcode indentation preferences configured globally. Without .editorconfig, those global settings apply to every project they open. This means a contributor with 4-space tabs will silently reformat code when they edit a file, even if the project convention is different.

With .editorconfig in the repository root, Xcode overrides global settings with the project-specific ones. Contributors do not need to change anything – it just works.

Adoption

Drop this file in your package root and commit it. That is all. There is no build step, no dependency, no configuration beyond the file itself. Most modern editors (VS Code, Vim, Sublime Text) also support EditorConfig, so non-Xcode contributors benefit too.

The App Store Connect iOS app has a feature that most developers never discover: push notifications for new user reviews. It is turned off by default, and you have to enable it separately for each app, which is probably why so few people know about it.

How to Enable It

Open the App Store Connect app on your iPhone, then navigate to:

1. Tap your profile icon or go to Settings

2. Select Notifications

3. You will see a list of all your apps

4. For each app, toggle on Customer Reviews

That is it. From now on, you will get a push notification whenever someone leaves a new review for that app.

Why This Matters for Indie Developers

Responding to App Store reviews quickly has a tangible impact. When a user leaves a negative review about a bug, a fast reply acknowledging the issue (or pointing them to a fix) can lead them to update their rating. Positive reviews also deserve acknowledgment – it encourages users to keep providing feedback.

Without notifications, most developers only check reviews when they remember to, which might be days or weeks later. By then, the user has moved on, and your response feels like an afterthought.

A Word of Caution

If you have multiple apps with high review volume, enabling this for all of them could become noisy. Start with your most important apps and adjust based on how many notifications you actually receive. For most indie developers with a handful of apps, the volume is perfectly manageable and the benefits are immediate.

Most developers know DocC supports standard markdown, but there are two powerful directives that are surprisingly underused: video embedding and tabbed content. Both work in Xcode’s documentation viewer and on hosted DocC websites.

Embedding Videos

Adding a video to your documentation is a single directive:

@Video(source: "setup-walkthrough.mp4")

Place the video file in your documentation catalog’s Resources folder. This renders an inline video player directly in the documentation, which is far more effective than linking to an external URL or describing a visual process in text. It works well for setup guides, UI walkthroughs, or demonstrating animations.

Tabbed Content with TabNavigator

When you need to show alternative approaches or platform-specific instructions, tabs keep things organized without overwhelming the reader:

@TabNavigator {
   @Tab("SwiftUI") {
      Use the `.environment` modifier to inject dependencies.
   }
   @Tab("UIKit") {
      Override `viewDidLoad` and configure your dependencies there.
   }
}

This renders as a proper tabbed interface where readers can switch between sections. It is especially useful for documentation that covers multiple platforms, API versions, or configuration approaches.

Practical Advice

I updated my Contributing guide to use both of these features, and the result is noticeably more approachable than a wall of text. The video shows the setup process that would take paragraphs to describe, and the tabs separate platform-specific steps cleanly.

These directives are documented in Apple’s DocC documentation but rarely mentioned in tutorials. If you maintain an open-source Swift package, consider adding them to your documentation catalog – they make a real difference in how people experience your docs.

Switching a paid app to freemium is a common business decision, but it comes with a fairness challenge: users who already paid for the app should not suddenly lose features or be asked to pay again. StoreKit’s AppTransaction API solves this cleanly.

Using AppTransaction to Check Purchase History

The key is AppTransaction.shared, which provides information about the original transaction for your app. Specifically, originalAppVersion tells you which version of the app the user originally downloaded. If that version was a paid version, you know the user already paid.

import StoreKit

func shouldGrantFullAccess() async -> Bool {
   do {
      let result = try await AppTransaction.shared
      if case .verified(let transaction) = result {
         let originalVersion = transaction.originalAppVersion
         // Version "2.0" was when the app went freemium
         if originalVersion.compare("2.0", options: .numeric) == .orderedAscending {
            return true // User purchased before freemium transition
         }
      }
   } catch {
      // Handle verification failure
   }
   return false
}

The logic is straightforward: compare the user’s originalAppVersion against the version where you made the freemium switch. If their original version predates the change, grant them full access automatically.

Important Details

The originalAppVersion corresponds to the CFBundleShortVersionString value at the time of the original purchase (or download for free apps). Make sure you know exactly which version number marks your transition point.

This approach requires no server infrastructure and no migration code. StoreKit handles verification through the App Store receipt chain, so the check is tamper-resistant. Apple documents this pattern in their original API for business model migration.

For TestFlight and simulator testing, originalAppVersion returns the CFBundleVersion (build number) instead, so plan your test cases accordingly.

For years, my workflow for checking documentation in Xcode was the same: Cmd-click a symbol, select “Show Quick Help” from the context menu, read the popup, then dismiss it and continue coding. It works, but it is interruptive – each lookup requires three actions and breaks your editing flow.

Then I accidentally discovered the Quick Help inspector panel in the right sidebar.

How It Works

Open the Quick Help inspector with Option+Cmd+3, or go to View > Inspectors > Quick Help. This opens a panel in the right sidebar that displays documentation for whatever symbol your cursor is currently on. As you move your cursor through your code – clicking on a method, arrowing through parameters, selecting a type – the sidebar updates automatically.

There is no clicking, no popup to dismiss, no interruption. You just keep coding and the relevant documentation follows along.

Why It Beats Cmd-Click

The Cmd-click approach has a specific cost: it requires you to decide “I need docs for this” before you look. The sidebar inverts that. Because it is always visible, you absorb documentation passively. You notice parameter descriptions, return types, deprecation warnings, and availability annotations without making a conscious effort to look them up.

This is particularly valuable when working with unfamiliar APIs. Instead of Cmd-clicking every other symbol, you simply move your cursor through the code and read the sidebar as you go. It turns documentation lookup from a discrete action into a continuous stream.

The panel shows the same content as the Quick Help popup: declaration, description, parameters, return value, availability, and related symbols. The only difference is that it persists and updates in place rather than appearing and disappearing.

If you have the screen space for the right sidebar, keeping Quick Help open while coding is one of those small workflow changes that compounds over time.

Standard SwiftUI Button actions are synchronous. When you need to perform an async operation – a network request, a database write, a StoreKit purchase – you end up manually managing a Task, tracking loading state, disabling the button, and handling errors. This boilerplate repeats across every async button in your app.

I built an AsyncButton component that wraps all of this into a single reusable view.

A Simplified Implementation

Here is the core idea:

struct AsyncButton<Label: View>: View {
   let action: () async throws -> Void
   let label: () -> Label

   @State private var isRunning = false
   @State private var result: Result<Void, Error>?

   var body: some View {
      Button {
         isRunning = true
         Task {
            do {
               try await action()
               result = .success(())
            } catch {
               result = .failure(error)
            }
            isRunning = false
         }
      } label: {
         HStack(spacing: 8) {
            label()
            if isRunning {
               ProgressView()
            }
         }
      }
      .disabled(isRunning)
   }
}

The button creates a Task internally, so callers can use await directly in the action closure. While the task runs, a ProgressView appears next to the label and the button is disabled to prevent duplicate submissions. The result state can drive success or failure indicators – a checkmark, a color flash, or a shake animation.

Usage

Using it feels natural:

AsyncButton {
   try await viewModel.submitOrder()
} label: {
   Text("Place Order")
}

No manual state management, no Task creation at the call site. The full implementation in HandySwiftUI adds configurable success/failure animations, customizable progress indicators, and support for button styles. But the core pattern above covers the most common case and is straightforward to adapt to your own projects.

SwiftUI’s ImageRenderer lets you render any SwiftUI view into a UIImage or CGImage. It works well for pure SwiftUI views, but silently fails – producing a blank or incomplete image – when the view tree contains components backed by UIKit or AppKit. This includes several commonly used views:

• List (wraps UITableView / NSTableView)

• ScrollView (wraps UIScrollView / NSScrollView)

• TextEditor (wraps UITextView / NSTextView)

• Map (wraps MKMapView)

There is no compiler warning or runtime error. The renderer simply does not capture those portions of the view hierarchy.

The Workaround

When I needed to export a list-like layout as an image, the solution was to replace List with a pure SwiftUI equivalent built from VStack and manual styling:

let exportView = VStack(spacing: 0) {
   ForEach(items) { item in
      HStack {
         Text(item.name)
         Spacer()
         Text(item.value)
            .foregroundStyle(.secondary)
      }
      .padding(.horizontal, 16)
      .padding(.vertical, 12)

      if item.id != items.last?.id {
         Divider()
      }
   }
}
.background(.white)
.frame(width: 390)

let renderer = ImageRenderer(content: exportView)
renderer.scale = UIScreen.main.scale

if let image = renderer.uiImage {
   // Use the rendered image
}

The VStack with ForEach replicates the visual structure of a List without relying on any UIKit-backed views. Adding dividers, padding, and a background produces a result that looks close enough to a standard list for export purposes.

Practical Advice

If you plan to use ImageRenderer in your app, design your exportable views with this constraint in mind from the start. Build them from basic SwiftUI primitives: stacks, text, shapes, and images. Avoid any view that you know wraps a platform-specific control. Testing the render output early saves the frustration of discovering blank regions later.

In any Swift project of moderate size, you end up with the same set of imports at the top of nearly every file. Foundation, SwiftUI, OSLog, maybe Observation – the list grows as you adopt new frameworks. With the move to structured logging via OSLog, I found myself adding import OSLog to almost every file alongside the usual suspects.

The solution is a wrapper module that re-exports everything you commonly need through a single import.

Setting Up the Wrapper Module

Create a new target in your Swift package or Xcode project. In my case, I called it AppFoundation. The entire module consists of a single file:

// Sources/AppFoundation/Exports.swift
@_exported import Foundation
@_exported import SwiftUI
@_exported import OSLog
@_exported import Observation

The @_exported attribute makes all public symbols from each framework available to any file that imports AppFoundation. Now, every file in your app just needs:

import AppFoundation

In your Package.swift, the target has no source code of its own beyond the exports file. Your app target declares a dependency on AppFoundation, and all the re-exported frameworks become available everywhere.

Trade-Offs to Consider

This approach has clear benefits: less boilerplate, fewer merge conflicts in import sections, and a single place to add new framework imports. But there are trade-offs.

First, @_exported is an underscored attribute, meaning it is not officially part of the stable Swift API. In practice, it has been stable for years and is used widely in the ecosystem, but it carries no formal guarantee.

Second, implicit dependencies can make it harder to understand what a file actually uses. When every file has access to everything, you lose the documentation value of explicit imports. If you later extract a module into a standalone package, you will need to add the explicit imports back.

For app targets where convenience matters more than strict modularity, the wrapper module pattern saves real time. For reusable libraries, explicit imports remain the better choice.

In UIKit, navigation is imperative. You tell the system exactly what to do:

let detailVC = DetailViewController()
detailVC.item = selectedItem
navigationController?.pushViewController(detailVC, animated: true)

You create a view controller, configure it, and push it onto the stack. You are in control of the action.

SwiftUI works differently. You do not navigate – you present data in new views. Everything is data-driven. You do not control views. You control data.

Data-Driven Navigation in Practice

With NavigationStack, navigation is driven by state. You declare what data maps to what view, and SwiftUI handles the transitions:

struct ContentView: View {
   @State private var path: [Item] = []

   var body: some View {
      NavigationStack(path: $path) {
         List(items) { item in
            Button(item.name) {
               path.append(item)  // Modify data, not views
            }
         }
         .navigationDestination(for: Item.self) { item in
            DetailView(item: item)
         }
      }
   }
}

The key line is path.append(item). You are not pushing a view. You are adding data to an array. SwiftUI observes the change and presents the corresponding view automatically.

Why This Matters

This distinction is not just philosophical – it has practical consequences. Because navigation is state, you get deep linking for free by constructing the right path array. You can persist and restore navigation state by saving the path. You can programmatically navigate to any depth by appending multiple items at once.

It also means dismissal is just data removal. Calling path.removeLast() pops the top view. Clearing the array returns to root. No need to track view controller references or walk the navigation hierarchy.

The shift takes time to internalize, especially if you have years of UIKit experience. But once it clicks, SwiftUI navigation becomes far more predictable. Your views become pure functions of your data, and navigation is just another piece of that data.

SwiftUI’s AsyncImage is convenient for loading remote images, but it has a surprising limitation: you cannot apply the .resizable() modifier to it. This code compiles but does not behave as expected:

// This does NOT work as intended
AsyncImage(url: imageURL)
   .resizable()  // Has no effect -- AsyncImage is not an Image
   .aspectRatio(contentMode: .fill)
   .frame(width: 200, height: 200)

The reason is that AsyncImage is not an Image – it is a container view that manages loading state. The .resizable() modifier is defined only on Image, so applying it to AsyncImage just calls the generic View version, which does nothing useful.

The Solution

The fix is to use the phase-based initializer, which gives you direct access to the underlying Image value once loading completes:

AsyncImage(url: imageURL) { phase in
   switch phase {
   case .success(let image):
      image
         .resizable()
         .aspectRatio(contentMode: .fill)
   case .failure:
      Image(systemName: "photo")
         .foregroundStyle(.secondary)
   case .empty:
      ProgressView()
   @unknown default:
      EmptyView()
   }
}
.frame(width: 200, height: 200)
.clipped()

Inside the .success case, image is a real Image value, so .resizable() works correctly. This also gives you control over the loading and error states, which is better practice anyway.

When to Load Manually

If you need the raw image data – for example, to cache it, inspect its size, or create a UIImage – you may want to skip AsyncImage entirely and load with URLSession. But for most display-only cases, the phase-based initializer covers the need without extra complexity.

This is one of those SwiftUI APIs where the simple initializer looks appealing but falls short in practice. Default to the phase-based version whenever you need any image-specific modifiers.

Xcode 15 introduced a small but impactful editing shortcut: Ctrl+M. Place your cursor on a function call, initializer, or any comma-separated parameter list, press Ctrl+M, and Xcode automatically expands it across multiple lines – one parameter per line, properly indented.

Before this shortcut, reformatting a long function call meant manually adding line breaks and fixing indentation. Consider a call like this:

let label = UILabel(frame: .zero, font: .systemFont(ofSize: 14), textColor: .label, numberOfLines: 0)

After pressing Ctrl+M with the cursor on that line, Xcode reformats it to:

let label = UILabel(
   frame: .zero,
   font: .systemFont(ofSize: 14),
   textColor: .label,
   numberOfLines: 0
)

When to Use It

This shortcut is most valuable when you are writing SwiftUI view modifiers or initializers that accumulate parameters over time. A view that starts with two parameters often grows to five or six as you add configuration. Rather than reformatting manually each time, Ctrl+M handles it in one keystroke.

It also works in reverse – if your parameters are already on separate lines, pressing Ctrl+M collapses them back into a single line. This toggle behavior makes it easy to switch between compact and expanded formats depending on readability needs.

One thing to note: the shortcut operates on the innermost parameter list at the cursor position. If you have nested function calls, position your cursor carefully to expand the right one.

Most Xcode users are familiar with Shift+Cmd+O – the “Open Quickly” shortcut that lets you jump to any file, symbol, or type in your project. It is one of those shortcuts that becomes second nature within days of using Xcode. What I did not realize until recently is that the same shortcut now works on the Apple Developer documentation website, powered by DocC.

When browsing developer.apple.com/documentation, pressing Shift+Cmd+O opens a search overlay that behaves just like Xcode’s Open Quickly dialog. You can type a framework name, a class, a method, or even a partial match, and results appear instantly. Selecting a result navigates directly to that documentation page.

Why This Matters

Before this feature, searching Apple’s documentation meant scrolling through the sidebar hierarchy or using the general search bar, which often returned a mix of articles, tutorials, and API references. The Open Quickly overlay filters results to API symbols and pages, making it far more precise.

This is especially useful when you are in a browser reading a WWDC article or forum thread and need to quickly check the signature of a related API. Instead of switching back to Xcode, you stay in context and look it up directly.

The feature is part of Apple’s broader investment in DocC as a documentation platform. Since DocC powers both Xcode’s documentation viewer and the web-based documentation, it makes sense that the same interaction patterns carry over. If you spend time reading Apple docs in the browser, building this shortcut into your muscle memory is worth the effort.

One of the quieter but impactful changes in Xcode 15 is built-in type-safe access to asset catalogs. Previously, referencing an image or color from your asset catalog required a string literal:

// Before Xcode 15
Image("custom-header-icon")
Color("primaryBrand")

This was fragile. Rename an asset and your code compiles fine but crashes or shows nothing at runtime. Tools like SwiftGen existed specifically to solve this by generating type-safe constants from your asset catalogs.

What Changed

Xcode 15 now generates Swift accessors for every image and color in your asset catalog automatically. You access them through the resource initializers:

// Xcode 15+
Image(.customHeaderIcon)
Color(.primaryBrand)

The compiler knows about your assets. You get full autocomplete, and if you delete or rename an asset, you get a compile-time error instead of a silent runtime failure.

Apple Sherlocked SwiftGen

This is effectively Apple integrating what SwiftGen has provided for years. For teams already using SwiftGen, this is a good time to evaluate whether you still need it. The built-in solution covers the two most common use cases – images and colors – without any build phase scripts or code generation steps.

There are still reasons to keep SwiftGen if you use it for fonts, localized strings, or other resource types. But for asset catalogs specifically, the native solution is now good enough for most projects, and it works out of the box with zero configuration.

Working with .strings and .stringsdict files has always been one of the rougher edges of Apple development. Plain text key-value files are easy to get wrong – missing semicolons, mismatched keys across languages, no way to see translation progress at a glance. And .stringsdict files, used for pluralization rules, are XML-based plist files that are notoriously difficult to author by hand.

What String Catalogs Bring

Xcode 15 introduces a new .xcstrings file format called String Catalogs. It replaces both .strings and .stringsdict with a single file that comes with a dedicated visual editor.

The key improvements are substantial:

Visual editor – All localizable strings are displayed in a table with columns for each language. You can see and edit translations inline without switching between files or using external tools.

Translation progress tracking – Each language shows a completion percentage. At a glance, you can tell which languages need attention and which strings are still untranslated.

Automatic string extraction – Xcode scans your Swift code and automatically discovers strings that need localization. New strings appear in the catalog without any manual registration step.

Built-in migration – There is a migration path from existing .strings and .stringsdict files. Right-click your existing localization files and Xcode offers to convert them to the new format.

Practical Impact

For projects with even a handful of supported languages, this is a significant quality-of-life improvement. The visual editor alone eliminates an entire class of formatting errors. Combined with automatic extraction, it means fewer forgotten strings and a clearer picture of your localization status across the entire project.

If you are starting a new project on Xcode 15, String Catalogs are the default. For existing projects, the migration is straightforward and well worth doing.

Long function calls and declarations with many parameters are one of the most common readability issues in Swift code. You end up with lines that stretch well past any reasonable column limit:

func configureView(title: String, subtitle: String, icon: Image, backgroundColor: Color, isEnabled: Bool, action: @escaping () -> Void) {

Manually breaking this into multiple lines is tedious. You have to position the cursor, add line breaks, indent each parameter, and make sure the trailing parenthesis lines up correctly.

The New Action in Xcode 15

Xcode 15 introduces a “Format to Multiple Lines” action that does this automatically. Place your cursor on a function call or declaration with multiple parameters, and Xcode offers to reformat it:

The result is cleanly formatted with one parameter per line:

func configureView(
   title: String,
   subtitle: String,
   icon: Image,
   backgroundColor: Color,
   isEnabled: Bool,
   action: @escaping () -> Void
) {

You can find this action by right-clicking on the function signature and looking under Refactor, or by using the Editor menu. It works on both function declarations and call sites.

When to Use It

This is most useful right after writing a new function or adding parameters to an existing one. Instead of manually formatting as you go, you can write everything on one line and then apply the formatter in a single action. It also helps when reviewing code where someone else left long single-line signatures – select and reformat without manual editing.

The reverse operation (collapsing multiple lines back to one) is not currently available, but that direction is less commonly needed.

When building views that depend on asynchronous data, you typically have a loading state that shows a spinner or placeholder. In production, this state appears briefly while data loads from the network or database. But in SwiftUI previews, your mock data is available instantly, so the loading state flashes by too fast to inspect – or never appears at all.

A Preview-Only Delay Helper

The solution is a small helper that introduces an artificial delay, but only in preview or debug contexts. Here is the pattern:

struct DelayedStatePreview<Content: View>: View {
   @State private var isLoaded = false
   let delay: Duration
   let content: (Bool) -> Content

   init(
      delay: Duration = .seconds(2),
      @ViewBuilder content: @escaping (Bool) -> Content
   ) {
      self.delay = delay
      self.content = content
   }

   var body: some View {
      content(isLoaded)
         .task {
            try? await Task.sleep(for: delay)
            isLoaded = true
         }
   }
}

You use it in a preview like this:

#Preview {
   DelayedStatePreview { isLoaded in
      if isLoaded {
         ArticleListView(articles: mockArticles)
      } else {
         LoadingView()
      }
   }
}

Why This Matters

The key benefit is that your production code stays clean. You are not adding artificial delays or debug flags to your actual views. The helper exists purely at the preview layer, giving you a way to visually verify that your loading states look correct, that transitions animate smoothly, and that layout does not jump when data arrives.

This is especially useful for views with skeleton loaders or shimmer effects where the visual quality of the loading state is part of the user experience.

If you have ever noticed a delay – sometimes several seconds – between pressing Run in Xcode and your app actually appearing, the culprit is often the LLDB debugger attaching to your process. During this time, the Simulator shows a blank screen while the debugger initializes.

Where to Find the Setting

The setting lives in your scheme configuration:

1. Go to Product > Scheme > Edit Scheme (or press Cmd+Shift+<)

2. Select the Run action on the left

3. Switch to the Info tab

4. Uncheck Debug executable

What This Does

When “Debug executable” is enabled (the default), Xcode attaches the LLDB debugger to your app process at launch. This is what enables breakpoints, the debug memory graph, view hierarchy debugger, and po commands in the console.

Disabling it skips the debugger attachment entirely. Your app launches noticeably faster – in my experience, the difference can be 2 to 5 seconds on larger projects. Console output via print() and os_log still works normally, so you can still use logging for debugging.

The Trade-Off

Without the debugger attached, you lose:

• Breakpoints (they will not trigger)

• po and expression commands in the console

• Memory graph and view hierarchy debugging tools

This makes the setting ideal for UI iteration work, where you are making visual tweaks and re-running frequently. When you need to investigate a specific bug with breakpoints, just re-enable the checkbox temporarily. I keep it off most of the time and only toggle it on when I need to step through code.

Swift’s #warning directive generates a compiler warning with a custom message. Unlike comments, these show up in the Issue Navigator and in the build output, making them impossible to miss. I use them as hard reminders for things that must be addressed before shipping.

Two Snippets I Use Daily

I have two Xcode code snippets configured for this purpose.

“nyi” – Not Yet Implemented:

#warning("Not yet implemented!")

I type nyi and hit Enter whenever I stub out a function or skip a code path during prototyping. It compiles fine but the warning ensures I come back to finish the work.

“dw” – Developer Warning:

#warning("<#message#>")

This one uses a placeholder token so that after typing dw and pressing Enter, the cursor lands inside the message and I can type a custom note. I use this for things like #warning("Handle error case for offline mode") or #warning("Remove before release").

How to Create Xcode Snippets

Setting these up takes about 30 seconds each:

1. Type the code you want as a snippet in any Swift file

2. Select the code

3. Right-click and choose Create Code Snippet

4. Give it a title (e.g., “Developer Warning”)

5. Set the Completion shortcut (e.g., dw)

6. Set Availability to “All” or “Swift” scopes

7. Click Done

From that point on, typing the shortcut in any Swift file offers the snippet via autocomplete.

The key advantage over plain comments is visibility. A // TODO: comment is easy to ignore and hard to search for consistently. A #warning forces the compiler to surface it every single build, keeping your unfinished work front and center until you resolve it.

Swift Evolution proposals are thorough by design. They cover motivation, detailed design, alternatives considered, ABI implications, and more. That thoroughness is essential for the review process, but when you just want to understand what a proposal does and why, reading through thousands of words can be a lot.

The URL Trick

There is a simple way to get a summarized version of any Swift Evolution proposal on GitHub. When you are viewing a proposal at a URL like:

https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

Replace apple with FlineDev:

https://github.com/FlineDev/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md

That takes you to a fork of the swift-evolution repository where proposals have been augmented with AI-generated summaries at the top. Each summary distills the key points – what the proposal introduces, why it matters, and the basic syntax – into a few paragraphs.

When This Helps

This is particularly useful when you see a proposal mentioned in release notes or on social media and want to quickly understand the gist. Instead of spending 15 minutes reading the full proposal, you get the essential information in a couple of minutes.

The summaries cover most recently accepted proposals. For older proposals that predate the fork, you will still see the original text. But for anything from the last few years of Swift Evolution, the summarized version is a real time-saver.

I built this fork because I found myself repeatedly skimming proposals for just the core idea, and figured other developers might benefit from the same shortcut.

When building an onboarding flow, one challenge is directing the user’s attention to the next action they should take. A subtle pulsating animation on buttons draws the eye without being intrusive. I implemented this in SwiftUI using a combination of scaleEffect and opacity modifiers tied to a repeating animation.

Here is the core approach:

struct PulsatingButtonStyle: ButtonStyle {
   @State private var isPulsating = false

   func makeBody(configuration: Configuration) -> some View {
      configuration.label
         .scaleEffect(isPulsating ? 1.06 : 1.0)
         .opacity(isPulsating ? 0.8 : 1.0)
         .animation(
            .easeInOut(duration: 0.8)
               .repeatForever(autoreverses: true),
            value: isPulsating
         )
         .onAppear {
            isPulsating = true
         }
   }
}

The trick is combining two animations – scale and opacity – that run in sync. The repeatForever(autoreverses: true) modifier makes the animation bounce back and forth continuously. By toggling isPulsating on appear, the animation starts immediately when the view is displayed.

The scale factor of 1.06 is intentionally subtle. Going much higher (like 1.2) makes the animation feel aggressive and distracting. The slight opacity shift adds depth to the pulse without making the button hard to read.

This pattern works well for onboarding screens where you want to highlight a “Continue” or “Get Started” button. Once the user has moved past onboarding, the animation is no longer shown, so it does not become annoying over time.

You can apply it to any button with .buttonStyle(PulsatingButtonStyle()), keeping the animation logic cleanly separated from your button content.