iOS Resources
Hand-picked Articles

Swipe actions were a primary reason for using List in SwiftUI. As you may recall, I’ve mentioned several times that a scroll view paired with lazy stacks is the preferred approach in most scenarios, except when swipe actions are required.

SwiftUI tabs used to be simple on iPhone and more awkward on iPad. On iPhone, TabView naturally mapped to a bottom tab bar. On iPad, many apps needed something closer to a sidebar: more space, grouped destinations, and a layout that feels better on a large display.

The usual answer was to build a custom sidebar, split the app into separate navigation structures, or use conditional code for iPhone and iPad. That worked, but it also meant you were responsible for keeping selection, layout, and platform behavior in sync.

Xcode 27 launched during WWDC 2026 and includes Apple’s SwiftUI Agent Skill for the first time. These skills work great for agentic development in Xcode, or when Using Xcode 27’s Agent Skills in Claude, Codex, and Cursor, any AI IDE.

While we can use these skills and not look back, it’s far more interesting to dive a little deeper and analyze what Apple believes is important enough to include in an Agent Skill. Skills need to be compact and optimized for token usage, so only essential parts will be included. In this article, we’ll dive deeper into the SwiftUI best practices by looking at the SwiftUI Specialist Agent Skill bundled in Xcode 27.

How a pile of repeated corrections became the rulebook I load into every coding agent, and what writing it down taught me about my own code

Testing on-device Foundation Models features with Swift Testing when the output is non-deterministic by design.

‍Stop trying to assert equality on AI output

Here’s the reframe that unlocks all of this: a language model is not a function in the mathematical sense. The same input does not map to the same output. The moment you accept that, you stop asking “what string will it return” and start asking “what must be true about whatever it returns.”

Swift's defer statement is useful for cleanup logic. It guarantees that a block of code runs when the current scope exits, regardless of whether execution completes normally, throws an error, or returns early.

Before Swift 6.4, we couldn't perform asynchronous operations directly inside a defer block. Starting with Swift 6.4, it is possible.

At WWDC 2026, Apple introduced a new tab role for SwiftUI: .prominent.

The API is straightforward.

The design implications are not.

Ever since the announcement, I've notice developers will immediately treat .prominent as a replacement for floating action buttons, toolbar actions, and the classic "+" button.

I think that's the biggest mistake developers will make with this new API.

The prominent tab is not Apple's version of a Floating Action Button.

It is not a replacement for a navigation bar button.

It is not a shortcut for presenting a sheet.

A prominent tab is still a tab.

Understanding that distinction is the key to using this feature correctly.

Most validation code is one giant function that walks a tree and appends to an error array through a forest of if statements. OpenAPIKit showed me a better way, a validation is a small composable value, the description states the correct state, and every error already knows where it lives

At WWDC26, Apple extended the Foundation Models framework with support for server-side language models. The idea is simple: the same LanguageModelSession API that drives the on-device model can now drive any remote model that conforms to the LanguageModel protocol. Anthropic was quick to adopt it and released ClaudeForFoundationModels — a Swift package that makes Claude a drop-in model for your sessions. Streaming, guided generation with @Generable, and tool calling work the same way.

In this post, we'll build GiftGenie — a small app that generates gift ideas — and let the user switch between the on-device model and Claude with their own API key.

Before iOS 27, swipeActions(edge:allowsFullSwipe:content:) only worked on rows inside a List. Applying it to views in a LazyVStack, a LazyVGrid, or a custom layout had no effect. iOS 27 removes that restriction with a new modifier, swipeActionsContainer(), that activates swipe action support for any container inside a scroll view.

We have to apply the new swipeActionsContainer() modifier directly to the ScrollView and then add swipeActions(edge:allowsFullSwipe:content:) to each row inside it.