iOS Resources
Hand-picked Articles and Videos

Following the release of iOS 26 I was left with one strong impression (leaving liquid glass aside): Apple Intelligence seems pretty powerful. I’d love to be able to feed it an image along with some context about the use of the image, and get Apple Intelligence to generate an appropriate description. As a developer, there are times when alt text is not available because the person who chose the image didn’t add it, and this leaves VoiceOver users missing a ton of content.

With the first Beta release of iOS 27 and Xcode 27, we can do just that.

The model can reach into your app. Mid-generation. It can call a function you wrote, get a result, and fold that result into its answer — all in a single respond call. That's the Tool protocol - on-device tool calling - and it's the difference between an AI feature that talks about your data and one that talks to it.

When you embed web content in a WKWebView, you often want it to stay on a set of trusted domains. A login flow that wanders off to an arbitrary site, or a help page that turns into an open browser, is both a security and a product problem. There are two ways to control this. One is declarative, handed to WebKit through your Info.plist. The other lives in your navigation code, where you decide each request yourself.

Xcode 27 beta is out, and it comes with a range of SwiftUI and Swift updates and improvements. The first thing that caught my eye is a change to @State. Up until now it was a property wrapper conforming to the DynamicProperty protocol, but in Xcode 27 it becomes a Swift macro. In this post we will look at what the change means for @Observable models stored in @State.

Property wrappers are a Swift feature that allows you to define reusable logic for getting and setting property values. They reduce boilerplate code and enable elegant solutions for common patterns like lazy initialization, validation, and persistence. This post is a deep dive suited for intermediate to advanced Swift developers who already have basic familiarity with property wrappers.

Platforms State of the Union has just been published, and we have a lot of new APIs to learn, explore, and use to build new features and apps. Let’s start with the most important framework for our apps. This week, we will look at what WWDC26 brings to the new iteration of SwiftUI.

When working with SwiftUI, we constantly compose views from other views.

A Text view can be placed inside a VStack, a VStack can be embedded in a NavigationStack, and an entire screen can become a child of another view. This ability to build complex user interfaces from smaller building blocks is one of the core ideas behind SwiftUI.

Enums are one of the most useful modeling tools in Swift. We use them for screen states, navigation routes, user actions, errors, commands, feature flags, and many other parts of iOS applications.

A lot of these models have something in common: they describe a closed set of possible values. A screen can be loading, loaded, or failed. A route can open a list, details, or settings. An action can represent view appearance, refresh, or item selection. These concepts map naturally to enums.

By default, SwiftUI's Text view renders formatted measurements as a uniform string and applies the same font and style to both the value and the unit. In some situations we might want to style the unit differently from the value to make it less dominant, for example. We can do this using the AttributedString API.

We can build a reusable Text initializer that targets only the unit component of a formatted measurement and applies a distinct font.