I was struggling to find and fix an obscure bug in my project. One of those vexing edge cases that surfaces occasionally, under a specific set of circumstances, except when it doesn’t. I hunted for race conditions, memory leaks, persistent data corruption, etc. I couldn’t find any explanation.

So I turned to a coding agent for assistance. I described the problem in detail, and my agent sprang into action, reading files, thinking and planning before confidently announcing that it had a solution. Unfortunately, it was wrong.

The problem persisted. I prompted again. More digging, thinking and planning, all to no avail.

This went on for several cycles. Each time my agent announced that it now had a complete understanding and definite solution (and yes, I was using my trusty two-step method to mitigate agentic overconfidence). Some of these did nothing, some introduced regressions.

Then the agent started proposing solutions that were variations of things it had tried before. It hadn’t compressed or lost context, but it was going in circles.

That’s when I realized it was stuck.

But was it going to admit that? I didn’t think so. After all, agents are designed to solve problems, not to admit defeat. I realized that if I let it, it would spin in circles forever.

So I prompted: “If you’re stuck and can’t come up with a solution, say so.”

It responded: “I’m stuck. Let me be honest about where I am.”

That’s when everything changed.

It changed strategy, hypothesizing that the errant behavior was due to a bug in one of the frameworks I was importing. It suggested a complex diagnostic run that would trigger the unwanted behavior with detailed logging so it could test this hypothesis.

It asked: “Would you be willing to do a diagnostic run with logging, or would you prefer I stop here?”

Duh, diagnostic run please!

It analyzed the logs and voila!

It confirmed that my code was fine and that the culprit was a framework bug. Perhaps obvious in retrospect. I’d poured over my code in detail and so had the agent.

Minutes later, the agent devised, implemented and tested an elegant solution that bypassed the framework bug. It works flawlessly. 

I learned two key lessons:

• Even with mitigation efforts, agentic overconfidence and reason for existence prevent coding agents from recognizing when they’re stuck. It took precious time (and tokens) for me to realize that the agent wasn’t going to admit that unless I asked.
• Admitting that it was stuck forced it to devise a different strategy which found and fixed the problem.

Prompting the agent to find a bug in my code imposed an implicit constraint. That constraint was removed when I got it to admit that it was stuck.

internal://first

Recently I prompted an AI agent to:

 “Create a step by step guide explaining how to create a Help Book for a modern macOS swiftUI app. Include specific details such as how to create help book text and images, how to create a searchable index, how to create the necessary plist, and how to integrate the help book into an existing macOS Swiftui project with Help menu options including search, troubleshooting and get support menu items.”

Moments later I had a professional looking, authoritative sounding 26 page document called “MacOS HelpBook Guide”. Here’s the first page:

Overview & Prerequisites

Apple Help Books are self-contained bundles of HTML content that macOS's built-in Help Viewer displays. They support full-text search, Spotlight indexing, and deep integration with the Help menu. This guide walks you through every step — from folder structure to SwiftUI code — to ship a polished, searchable help system with your app.

• Xcode 15 or later installed
• An existing macOS SwiftUI project (target: macOS 13+)
• hiutil — Apple's Help indexing tool (included with Xcode Command Line Tools)
• Basic familiarity with HTML and plist files

I was skeptical. This isn’t an easy task. Documentation for how to do this is notoriously outdated. Apple’s own documentation dates to 2013 and has been archived.

There are several approaches under investigation for reducing the impact of agentic overconfidence. For example, see https://arxiv.org/html/2602.06948v1

I’ve found a combination of two strategies to be effective.

First, I prompted:

“Rank your confidence in the accuracy of this guide on a scale of 0 to 100. If your confidence is below 90, make revisions as needed until your confidence is above 90. Then add references so I can see the source material you used to develop this guide.”

I got this response:

Original guide score: ~58/100.

The agent provided a list of five critical errors and key changes that needed to be made. After making those changes, I got a revised 26 page, equally authoritative document and a much improved confidence score.

Revised confidence: ~92/100.

Good to go? Perhaps, but I wasn’t convinced. So I prompted:

“What errors or mistakes can you find in the latest version of the macOS helpbook guide?”

The response listed 12 issues, categorized as:

Summary count: 5 definite errors, 4 significant inaccuracies, 3 notable omissions. The most critical ones to fix before shipping this guide to a developer are items 1, 2, and 3 — the bad hiutil -T flag, its repeat in the Quick Reference, and the obsolete CODE_SIGN_RESOURCE_RULES_PATH advice, which could cause App Store rejection.

I prompted: 

“Fix the 5 definite errors, 4 significant inaccuracies and 3 notable omissions.”

I now have a twice revised 26 page guide.

________________________________________________________________________

The two step approach I used can be summarized as,

1. Challenge your agent to rate its accuracy
2. Ask your agent to find errors

These sound similar, but they’re not. The first strategy requests a post-execution verification. The second strategy requests a post-execution falsification. When combined, these approaches may help overcome the confirmation bias that underlies agentic overconfidence.

If doubts remain, it may be helpful to repeat the two-step process with a different agent.

Agentic overconfidence will improve with time, but for critical applications where complete accuracy is essential, verification strategies may always be needed. Try the two complimentary approaches described here to improve the reliability of your results.

Want to explore these new features without spending more? You can, thanks to the ability to add other agents, including those with generous free tiers. Let’s look at how we can integrate Google Gemini into this new version of Xcode.

Google Gemini offers a generous free tier, but support for Gemini isn’t preconfigured in Xcode 26.3, at least not as of Xcode 26.3 RC. Adding it isn’t difficult, but you’ll need a few things first:

• A Google account
• Access to Google AI Studio
• A Gemini API key

If you don’t have a Google account, create one at https://accounts.google.com/.

Go to aistudio.google.com and sign in with your Google account.

Accept the Generative AI Terms of Service.

Don’t upgrade to a paid plan. You’ll be using the free one.

On the bottom left of the window, click “Get API key”

On the top right of the window, click “Create API key”

Click on your API key to see the details, then click the copy icon next to your key to copy it.

You now have everything you need to set up Xcode. Here’s how:

Open Xcode 26.3 RC or later.

Go to Settings and select Intelligence.

Click Add a Provider…

You’ll see a dialog like this…

For the URL, enter https://generativelanguage.googleapis.com/v1beta/openai

For the API key, enter the word “Bearer” followed by a space, then paste in your copied API key.

For the API Key Header, type “Authorization”

Click Add. You should see Googleapis listed under Providers.

You’re good to go, but I’d recommend one more step. 

Let’s add an Agents.md file that Gemini and your other agents can follow. There are three options:

Method 1: The Root Directory Strategy (Recommended)

Xcode's coding intelligence is designed to automatically scan for context files in your project.

1. Ensure your Agents.md file is located in the root directory of your Xcode project (where your .xcodeproj or .xcworkspace file is).
2. Rename it (if needed): While some agents look for Agents.md, the most reliable filename for the Gemini-specific integration in many environments is GEMINI.md.
3. Once the file is in the root, Gemini will automatically ingest it as a "preamble" to every request you make within that project.

Method 2: Reference it via the "Context Drawer"

If you prefer to keep the filename as Agents.md, you can manually attach it to your session:

1. Open the Coding Assistant panel (the star icon in the top right or Cmd+Shift+A).
2. Look for the Context icon (often looks like a paperclip or a drawer) at the bottom of the chat interface.
3. Select "Add File" and choose your Agents.md.
4. This explicitly feeds the contents of that file into Gemini’s context window for the current conversation.

Method 3: The Library Config Folder (Global Context)

If your Agents.md contains rules you want Gemini to follow across all Xcode projects (like your personal coding style or favorite libraries), you can place a copy in Xcode's global configuration directory for agents:

• Path: ~/Library/Developer/Xcode/CodingAssistant/CustomAgents/
• Note: You may need to create the CustomAgents folder if it doesn't exist yet.

Gemini models may not be the most robust agents for SwiftUI development, especially when it comes to front-end design, but they’re a great way to get your feet wet with the impressive new coding intelligence features without burning through costly tokens.

Open a new Playground in Xcode and enter the following:

var someInt: Int = 5

var anotherInt: Int = 5

var someOtherInt = someInt + anotherInt

Now change anotherInt from a regular Int to an Optional Int like this:

var anotherInt: Int? = 5

You'll get an error when you try to add someInt + anotherInt. Even though we’ve initialized anotherInt with a value, the compiler knows that the value of anotherInt could change to nil. This is not the same as a value of 0. Nil means “no value” which can’t be added to 5.

The error says:

Value of optional type 'Int?' must be unwrapped to a value of type 'Int'

Unwrapping an optional is like unwrapping a present to see what’s inside.

Xcode offers a couple of suggestions for how to do that. One of them is called “force-unwrapping”, also known as “unconditional unwrapping". This is like ripping the wrapping off a present and throwing it away. Once you do that, there’s no way to rewrap it. To force unwrap an optional, we just put an exclamation mark after its name like this:

var someInt: Int = 5

var anotherInt: Int? = 5

var someOtherInt = someInt + anotherInt!

Problem solved! We’ve ripped off the wrapping, exposing the value of anotherInt which can now be added to someInt. 

But there’s a big problem with this approach. Change the value of anotherInt to nil.

var someInt: Int = 5

var anotherInt: Int? = nil

var someOtherInt = someInt + anotherInt!

error: Execution was interrupted

Force-unwrapping an optional that has no value will crash your code at runtime. You shouldn’t force unwrap an optional variable in production code unless you’re absolutely certain that your optional variable contains an actual value. In most cases, if you're certain that an optional variable isn’t nil, you should just be using a regular variable, not an optional variable. 

Fortunately, Swift provides safer alternatives. These allow us to peek inside an optional without ripping off the wrapping. These safer alternatives are called “nil coalescing”, “optional binding” and “optional chaining”. 

We’ll get to those soon, but the simplest technique to understand is to use an if…else statement to see if an optional variable has a value or not. it looks like this:

var someInt: Int = 5

var anotherInt: Int? = nil

var someOtherInt =

if anotherInt != nil {

  someInt + anotherInt!

} else {

  someInt

}

We still have to force unwrap anotherInt, but now we only do so if it isn’t nil.  If it has a value we use it, otherwise (else) we don't.

This works, but it’s pretty cumbersome to explicitly check if an optional variable is nil every time we need to use it in our code. Let’s look at the other techniques available to us.

Optional binding

Optional binding uses an "if let…else" syntax to automatically peek inside an optional variable to see if it’s nil. In our example it looks like this:

var someInt: Int = 5

var anotherInt: Int? = nil

var someOtherInt = 

if let anotherInt {

  anotherInt + someInt

} else {

  someInt

}

Don’t be confused by the use of the word let here which is also used to declare a constant in Swift. You can think of the "if let…else" statement as saying, “If anotherInt isn’t nil, let someOtherInt = anotherInt + someInt. Otherwise, let someOtherInt = someInt”.

This is functionally equivalent to the if…else approach we used above, but checking to see if anotherInt is nil is built in. We don’t have to do it explicitly, and we don’t have to force unwrap anotherInt. 

The nil coalescing operator

The nil coalescing operator is written as two question marks (??). It does two things:

1. Unwraps an optional variable to expose its content

2. If the content is nil, it substitutes a default value that we specify

In our example, we can use it like this:

var someInt: Int = 5

var anotherInt: Int? = nil

var someOtherInt = someInt + (anotherInt ?? 0)

Unlike force-unwrapping, the nil coalescing operator protects our code from crashing when anotherInt is nil. If it is, a value we specify (0 in this case) is used instead.

It’s important to understand that anotherInt hasn’t changed from an optional integer to an integer. The nil coalescing operator just peeks under the wrapping to see if it has a value. If it finds a value, that’s what’s used. If it finds nil, it substitutes the value we specify (in this case, 0).

Optional chaining

Optional chaining is used to unwrap optional properties, methods and subscripts. It is beyond the scope of this basic introduction, but you can read about it here.

The Great Banking App Dilemma- Solved

In Part 1 we thought through some of the logic for a banking app. We realized that we should use optionals to handle the logic needed to decide which customers have to pay a monthly fee. Refresh your memory be reviewing Part 1. We need to declare userSavingsBalance as an optional double so we can tell which customers have a savings account. If it’s nil, they’ll have to pay a monthly fee for their checking account. 

Take a few moments to think about the logic we might use to safely unwrap userSavingsBalance and subtract a fee if appropriate… 🕒

Got it? Let’s apply what we’ve learned. We’ll define our variables like this:

var userCheckingBalance = 0.0

var userSavingsBalance: Double?

let monthlyFee = 3.99

var userTotalBalance = 0.0

We’ve made userSavingsBalance an optional double, because we don’t know if a savings account actually exists. We’ve also initialized userCheckingBalance and userTotalBalance with a value of 0. Our app’s logic is going to calculate the actual total balance based on data it gets from the bank for each individual customer. If a customer has a savings account, their total balance will be userCheckingBalance + userSavingsBalance. Otherwise, their total balance will be userCheckingBalance - monthlyFee. To implement this logic, we’ll need to unwrap userSavingsBalance to see if it’s nil or not.

 How might we use optional binding to safely unwrap (i.e. peek inside) userSavingsBalance?

if let userSavingsBalance {

  userTotalBalance = userCheckingBalance + userSavingsBalance

} else {

  userTotalBalance = userCheckingBalance - monthlyFee

}

Remember that if let is like saying “If userSavingsBalance isn’t  nil, do something. Otherwise do something else”. It peeks under the wrapping of userSavingsBalance to see if there’s a value or not.

How might we use a nil coalescing operator to do the same thing? This approach is even easier. All the logic we need is included in the nil coalescing operator. Instead of using if let…else we just need to do this:

userTotalBalance = userCheckingBalance + (userSavingsBalance ?? -monthlyFee)

If userSavingsBalance isn’t nil, we’re adding it to userCheckingBalance. If it is nil, we’re subtracting monthlyFee instead. 

The approach you use to safely unwrap an optional depends on the specific circumstances of your app and to some extent on your personal preference.

We’ve learned what optional variables are, how they differ from regular variables, and how to take advantage of them in our code. They’re a bit more cumbersome to use, but you’ll come to depend on the power and convenience they offer.

The key concept to remember is that optionals must be unwrapped safely before their wrapped values can be used.

Level: Novice

In the Swift programming language, variables are declared like this:

var someString: String = ""

var someInt: Int = 0

var someDouble: Double = 0.0

We’ve declared three variables, a string, an integer and a double. We’ve also initialized them (given them initial values).

In more detail, we’ve:

• Used the word var to indicate that we want to create a new variable.

• Described what name we want to use to refer to that variable, followed by a colon (e.g. someString:). 

• Specified what kind of value this variable will store (e.g. String meaning a string of characters, Int meaning a number without a decimal point and Double meaning a number with a decimal point). 

• Specified the initial values to store in these variables.

Swift can use the initial value of a variable to infer what type of value it will store. Because Swift supports type inference, we can save some typing and just write this:

var someString = ""

var someInt = 0

var someDouble = 0.0

The Great Banking App dilemma

Suppose we’re creating an application for a bank that allows customers to see the current balances in their accounts. In this bank, customers may have a checking account, a savings account or both. 

When creating our banking application, we have no way of knowing what accounts each customer will have. Let’s create some variables to hold their account balances. Because we don’t know if these accounts actually exist, we’ll omit the initial values like this:

var userCheckingBalance: Double

var userSavingsBalance: Double

So far, so good.

But customers are going to want to see the total amount of money the have in the bank, so let’s also give them the sum of their account balances by creating a computed variable like this:

var userTotalBalance = userSavingsBalance + userCheckingBalance

Xcode complains that

Variable 'userCheckingBalance' used before being initialized

Variable 'userSavingsBalance' used before being initialized

because it can’t add values without knowing what they are.

There’s an easy way to fix this. We need to initialize our variables.

var userCheckingBalance = 0.0

var userSavingsBalance = 0.0

var userTotalBalance = userSavingsBalance + userCheckingBalance

We just assume that the values are 0 when we start. It doesn’t matter because our application is going to get actual values from the bank before the customer sees any balances. But customers without a savings account will see a savings account balance of 0. That could mislead them into thinking that they actually have a savings account. That’s not so good, but our code works, so we’ll stick with this approach for now.

Now suppose that this bank charges users monthly fee of $3.99 to have a checking account. Because this is a fixed amount, we can represent it with a constant. In Swift, constants are declared with the word let, so we can do this: 

var userCheckingBalance = 0.0

var userSavingsBalance = 0.0

let monthlyFee = 3.99

var userTotalBalance = userSavingsBalance + userCheckingBalance - monthlyFee

But what if the bank decides that they’re going to waive the monthly fee for customers who also have a savings account?  Even if they let their savings account balance fall to $0, they won’t be charged a monthly fee. 

Our app is going need some logic in order to handle this. If a customer has a savings account, there’s no monthly fee, otherwise, there is a monthly fee.

Think about how we might add this logic to our banking app. Let’s try this:

if userSavingsBalance >= 0 {

  userTotalBalance = userSavingsBalance + userCheckingBalance

} else {

  userTotalBalance = userSavingsBalance + userCheckingBalance - monthlyFee

}

We’re using an if…else statement to decide whether or not to charge a monthly fee. If a customer has a savings balance, there’s no fee, even if the balance is 0.  Otherwise (else), we deduct the monthly fee.

Do you see a problem? We have to initialize our variables in order to use them, so we set userSavingsBalance to 0. We have no way of knowing whether or not a customer actually has a savings account. With this approach, no one will be charged a monthly fee, because everyone will have a savings balance of at least 0.

We don’t have enough information to make our logic work. We need to know which customers don’t have a savings account.

This is a dilemma. We don’t know if userSavingsBalance will exist until a customer starts using our app, but we have to give it some initial value in order for our code to work.

Give me some options

There are several ways to solve this problem, but Swift provides a kind of variable that is perfect for this situation. It’s called an “Optional”. Regular variables like Int must have some value before we can use them. In contrast, optional variables may or may not have a value.  This is perfect for our banking app. We can make userSavingsBalance an optional double variable instead of a double variable. An optional double variable may have a value like 0.0 or no value. In Swift, no value is represented by the word “nil”. Here’s how we declare userSavingsBalance as an optional double:

var userSavingsBalance: Optional<Double>

When declared as an optional double, userSavingsBalance may or may not have a value. We can declare other types as optionals using the same syntax.

var someInt: Optional<Int>

var someString: Optional<String>

And just like regular variables, we can initialize optional variables if we want to.

var someString: Optional<String> = "myString"

But unlike regular variables, we can initialize optional variables with no value.

var someString: Optional<String> = nil

However,  there’s a catch. Unlike regular variables, the value stored in an optional variable can’t be accessed directly.

 Notice how the variable type is wrapped inside Optional<>. Think of an optional variable as a wrapped package. 

🎁

If you want to see what’s inside this package, you have to unwrap it.

The concept of optional variables being wrapped and invisible is essential to remember. Forgetting this is what leads to confusion about how to use them. The fact that they’re declared with Optional<> provides a clue, but it’s easy to forget because you won’t see optionals declared using Optional<>. It’s much more common to use a shorthand that looks like this:

var someOptionalInt: Int?

We just put a “?” after the type of variable we want to declare as an optional. This wraps the type inside an optional and gives it an initial value of nil.

 Int and Int? look almost the same, but they’re not! 

var someInt: Int

var someOptionalInt: Int?

someInt must be an integer, but someOptionalInt can be an integer or nil. We don’t know until we unwrap it. We’ll see how in Part 2.

In order to explore optional chaining, let’s make our banking app more realistic. In an app like this, we’d probably use a struct (short for structure) to organize customer information. If you’re not familiar with structs, think of them as a template for structuring (organizing) data. In Swift, they are defined like this:

struct Customer {

  var firstName: String

  var lastName: String

  var checkingBalance: Double

  var savingsBalance: Double?

  let monthlyFee = 3.99

}

We’ve defined a struct called Customer and added some variables to it. These variables are placeholders that define what information is stored in the struct. Even though we recognize them as variables, in the context of a struct they’re referred to as “properties". So we’ve defined some properties that each customer will have. You’ll notice that we’ve made savingsBalance an optional double because we know that a specific customer may or may not have a savings account.  Because structs are just templates that define the data we want for each customer, we’re going to use the template to create one for each customer. 

We now have a structure that defines the things we want to know about each customer. This struct is just a template, it doesn’t actually hold any information except for a constant called monthlyFee. We’ve initialized monthlyFee because we know what its value is.. In order to use this struct, we have to create one for each actual customer. This is called “instantiation”, meaning “to create an instance of”. The jargon can be confusing, but it just means doing this:

var someCustomer = Customer(firstName: "Tom", lastName: "Tresh", checkingBalance: 0)

We’ve created an actual instance of a customer called someCustomer by using our Customer template, and we’ve given it some actual data about this specific person.  Notice that we don’t have to provide an initial value for savingsBalance because it’s an optional

Here’s how we might use this in our banking app:

Level: Intermediate

In this post, we explored how to reliably animate changes to a view’s properties by avoiding if…else conditional statements inside a view body. We learned how to leverage the power of the SwiftUI ternary conditional operator to do this. That solution works well when we want to animate changes to a single view, but what if we want to animate a change from one view to another? We can do that too, but the solution is a bit more complicated.

Here’s what we’re going to create:

We’ve got two views, a blue circle in the center and a yellow rectangle offset to the left. When the user switches the toggle on, the circle appears to smoothly morph into the rectangle with a subtle bounce at the end. When the user switches the toggle off, the rectangle morphs into the circle.

Let’s begin by creating our body and giving it a toggle. Just like last time, we’ll use an @State Boolean variable to keep track of the state of our toggle, and our toggle will use the same bouncy animation we used before:

import SwiftUI

struct ContentView: View {

  @State private var showRectangle = false

  var body: some View {

    VStack {

      Spacer()

      Toggle("Show the rectangle", isOn: $showRectangle.animation(.bouncy)

      )

      .padding()

    }

  }

}

#Preview {

  ContentView()

}

Now we’ll create the circle and rectangle views and conditionally insert them based on the value of showRectangle:

import SwiftUI

struct ContentView: View {

  @State private var showRectangle = false

  var body: some View {

    VStack {

      Spacer()

      if showRectangle {

        rectangleView

      } else {

        circleView

      }

      Spacer()

      Toggle("Show the rectangle", isOn: $showRectangle.animation(.bouncy)

      )

      .padding()

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

      .frame(width: 150.0, height: 150.0)

  }

  var rectangleView: some View {

    Rectangle()

      .foregroundColor(.yellow)

      .shadow(color: .gray, radius: 5)

      .offset(x: -50)

      .frame(width: 150.0, height: 200.0)

  }

}

#Preview {

  ContentView()

}

No errors or warnings! We should be good to go. Run this in the preview window or simulator.

Hmmm. That’s not what we want. SwiftUI is doing something - it’s fading out the circle and fading in the rectangle. To see the difference, comment out the .animation(.bouncy) modifier. But where’s our smooth blending from one view to the other and the subtle bounce effect? Clearly, SwiftUI doesn’t have enough information to do what we want, even though this appears to be valid code. In my opinion a compiler warning would be nice here, but Xcode is silent.

The additional information that SwiftUI needs is provided by an instance method called matchedGeometryEffect(), which the Apple documentation tells us, 

"Defines a group of views with synchronized geometry using an identifier and namespace that you provide."

To use it, we have to add this method to each of the views we want to animate. Here’s how:

import SwiftUI

struct ContentView: View {

  @State private var showRectangle = false

  @Namespace private var myAnimation

  var body: some View {

    VStack {

      Spacer()

      if showRectangle {

        rectangleView

      } else {

        circleView

      }

      Spacer()

      Toggle("Show the rectangle", isOn: $showRectangle.animation(.bouncy)

      )

      .padding()

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation)

      .frame(width: 150.0, height: 150.0)

  }

  var rectangleView: some View {

    Rectangle()

      .foregroundColor(.yellow)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation)

      .offset(x: -50)

      .frame(width: 150.0, height: 200.0)

  }

}

#Preview {

  ContentView()

}

That works! The matchedGeometryEffect method takes a @Namespace property wrapper which we’ve called myAnimation and an id. It uses these to give SwiftUI enough information to synchronize the geometries of our two views, creating the appearance of a smooth transition from one to the other.

The matchedGeometryEffect method is pretty magical, but it can be tricky to use. For instance, view modifiers that affect the geometry of a view must appear after .matchedGeometryEffect() in your code, just as I’ve done with the .offset() and .frame() modifiers.

Our code works as expected and should be fine in the majority of cases, but can we do better? I suggested here that conditional statements inside a view might not be ideal. While the SwiftUI ViewBuilder can handle conditional content, there are the previously noted animation issues as well as potential performance issues related to the complexity of the view hierarchy. For a deep dive I recommend watching this WWDC21 talk, but for now, let’s see if we can achieve the same result without an if…else conditional.

You might be tempted to use a ternary operator inside our view like we did  here, but that won’t work here because body returns an opaque View of type 'some View'. Because a ternary operator in this case contains two different views (either a circle or a rectangle), Xcode will give you an error. And from a SwiftUI performance perspective, it’s actually better to always include both views in our view hierarchy and to use modifiers to alter their appearance.

In this case, the modifier we want to use is opacity. In the initial state we want the circle’s opacity to be 1 and the rectangle’s opacity to be 0. When the user slides the toggle to show the rectangle, we want the circle’s opacity to be 0 and the rectangle’s opacity to be 1. Let’s give it a try by changing our body:

 var body: some View {

    VStack {

      Spacer()

      ZStack {

        rectangleView

          .opacity(showRectangle ? 1 : 0)

        circleView

          .opacity(showRectangle ? 0 : 1)

      }

      Spacer()

      Toggle("Show the rectangle", isOn: $showRectangle.animation(.bouncy)

      )

      .padding()

    }

  }

No errors, but our animation is broken again and our circle isn’t centered anymore!. Why? Using matchedGeometryEffect() can be more complicated (and sometimes mysterious) than our first implementation. It actually accepts more parameters than we needed in our first solution, and in this case we need to use one of them called isSource. As the name implies, isSource is a Boolean that tells matchedGeometryEffect() which of the views it should use as the source when the view changes. In order to fix our animation, we need to make the circle the source when the rectangle will appear and vice versa. Fortunately, we already have a variable we can use to do this called showRectangle.

Here’s the final implementation:

import SwiftUI

struct ContentView: View {

  @State private var showRectangle = false

  @Namespace private var myAnimation

  var body: some View {

    VStack {

      Spacer()

      ZStack {

        rectangleView

          .opacity(showRectangle ? 1 : 0)

        circleView

          .opacity(showRectangle ? 0 : 1)

      }

      Spacer()

      Toggle("Show the rectangle", isOn: $showRectangle.animation(.bouncy)

      )

      .padding()

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation, isSource: !showRectangle)

      .frame(width: 150.0, height: 150.0)

  }

  var rectangleView: some View {

    Rectangle()

      .foregroundColor(.yellow)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation, isSource: showRectangle)

      .offset(x: -50)

      .frame(width: 150.0, height: 200.0)

  }

}

#Preview {

  ContentView()

}

Note that I’ve attached the .opacity() modifiers to the rectangleView and circleView within the ZStack.  I think this makes it easier to understand the behavior of the two views. But if you prefer to keep your view body as sparse as possible, you can add the .opacity() modifiers to the Circle() and Rectangle() inside the circleView and rectangleView variables, like this:

 var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation, isSource: !showRectangle)

      .frame(width: 150.0, height: 150.0)

      .opacity(showRectangle ? 0 : 1)

  }

  var rectangleView: some View {

    Rectangle()

      .foregroundColor(.yellow)

      .shadow(color: .gray, radius: 5)

      .matchedGeometryEffect(id: "ID", in: myAnimation, isSource: showRectangle)

      .offset(x: -50)

      .frame(width: 150.0, height: 200.0)

      .opacity(showRectangle ? 1 : 0)

  }

We’ve just scratched the surface of the power (and complexity) of matchedGeometryEffect(). You can read more about it here.

Level: Intermediate

Ternary conditional operators (often called the ternary operator in Swift) are found in many programming languages.

They’re called “ternary” because they take three inputs: A Boolean condition to evaluate, a result to return if that condition is true, and result to return if that condition is false.

In C like languages, including Swift, they take the form:

condition ? value if true : value if false

The condition can be any Boolean expression (it must evaluate to true or false).

In Swift, we can use it like this:

let shouldShowItem = true

var itemOpacity: Double

itemOpacity = shouldShowItem ? 1.0 : 0.0

When this code runs, the value of itemOpacity will be set to 1.0. Why?

shouldShowItem is true, so the ternary operator in the third line returns a value of 1.0

If we change the value of shouldShowItem to false, the value of itemOpacity will be set to 0.0.

There’s a more conventional way to achieve the same result:

let shouldShowItem = true

var itemOpacity: Double

if shouldShowItem {

  itemOpacity = 1.0

} else {

  itemOpacity = 0.0

}

Because many find the second example easier to read, the ternary operator wasn’t used much prior to the introduction of SwiftUI. But if you’re using SwiftUI, the ternary operator is essential. Even in circumstances where you can substitute a more conventional if…else statement, it’s usually a bad idea. Let’s see why.

We’re going to build an app that does this:

When the user slides the “Enlarge the circle” toggle to the on position, the circle get’s bigger, with a nice bouncy animation.

This is remarkably easy to create using SwiftUI. It just takes a few lines of code, so let’s give it a try.

in Xcode, create a new project. Select the App template and click “Next”.

Enter a product name and organization identifier. Make sure the interface is SwiftUI, then click “Next”.

Select ContentView.swift and edit it to look like this:

import SwiftUI

struct ContentView: View {

 @State private var bigCircle = false

  var body: some View {

    VStack {

      Spacer()

      if bigCircle {

        circleView

          .frame(width: 150.0, height: 150.0)

      } else {

        circleView

          .frame(width: 50.0, height: 50.0)

      }

      Spacer()

      Toggle("Enlarge the circle", isOn: $bigCircle.animation(.bouncy))

        .padding([.top, .leading, .trailing])

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

  }

}

#Preview {

  ContentView()

}

Voila! No warnings or errors.

Our toggle changes the value of the State boolean variable named bigCircle.

We define a circleView that’s a blue circle with a gray shadow.

We use this circleView in the body of our view. We use an if…else conditional statement to draw circleView in two different sizes depending on the value of bigCircle.

With just a few lines of code we’ve drawn a small blue circle at the center of the screen and given the user a toggle so they can change the size of the circle. Because everyone loves animation, we’ve added a bouncy animation modifier to our toggle.

Make sure your preview is in live mode and click the toggle.

Our code compiles and runs without errors, but something’s wrong.

Where’s our nice bouncy animation? 

Animations in SwiftUI are powerful and simple to implement. So simple that we can just add the .animation() method to a binding that changes state and SwiftUI will render all the intermediate steps needed to create a smooth animation from one state to the other. But it only works as intended when the change is confined to a single view. In our code we’ve defined a view called circleView. We use it here:

      if bigCircle {

        circleView

          .frame(width: 150.0, height: 150.0)

      } else {

        circleView

          .frame(width: 50.0, height: 50.0)

      }

It’s the only view we use, but in SwiftUI these two instances of circleView are two different views. Why? Because the Circle shape we use is a struct, and structs are value types, not reference types. Here’s the definition of Circle. @frozen public struct Circle : Shape {…}. It’s a struct that conforms to the Shape protocol. 

In SwiftUI, all views are structs. So even if we write:

if bigCircle {

        Circle()

      } else {

        Circle()

      }

SwiftUI treats each Circle() as a different view, just as if we’ve written:

if bigCircle {

        Circle()

      } else {

        Rectangle()

      }

So why don’t we get an error message when we try to apply .animation(.bouncy)? It’d be nice if we did, but as far as the compiler is concerned, this is valid code. And at runtime it’s actually trying to do what we ask. If you remove .animation(.bouncy) from your code, you’ll see the difference. SwiftUI is trying to animate between two different views, but it’s not what we want.

To fix this we need to restrict our animation to a single view. You might be tempted to try this:

Circle()

      .frame(width: 50.0, height: 50.0)

    if bigCircle {

      .frame(width: 150.0, height: 50.0)

    }

But you’ll get an error that says, "Reference to member 'frame' cannot be resolved without a contextual type”, because the compiler has no way of knowing what view you want to apply  .frame(width: 150.0, height: 50.0) to.

There are a couple of ways to solve this problem. Here’s one way:

import SwiftUI

struct ContentView: View {

  @State private var bigCircle = false

  var body: some View {

    VStack {

      Spacer()

      circleView

        .frame(width: mySize, height: mySize)

      Spacer()

      Toggle("Enlarge the circle", isOn: $bigCircle.animation(.bouncy))

        .padding([.top, .leading, .trailing])

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

  }

  var mySize: Double {

    if bigCircle {

      return 150

    } else {

      return 50

    }

  }

}

#Preview {

  ContentView()

}

Here we’ve added a computed variable called mySize. Its value changes when the value of bigCircle changes. Because there’s a single circleView, this works as expected.

But there’s a simpler way to do this that doesn’t require a computed variable or an if…else statement.  We can simply make use of Swift’s ternary operator to dynamically change the size of our circle when bigCircle changes. 

import SwiftUI

struct ContentView: View {

  @State private var bigCircle = false

  var body: some View {

    VStack {

      Spacer()

        circleView

      .frame(width: bigCircle ? 150 : 50, height: bigCircle ? 150 : 50)

      Spacer()

      Toggle("Enlarge the circle", isOn: $bigCircle.animation(.bouncy))

        .padding([.top, .leading, .trailing])

    }

  }

  var circleView: some View {

    Circle()

      .foregroundColor(.blue)

      .shadow(color: .gray, radius: 5)

  }

}

#Preview {

  ContentView()

}

Everything needed to make this work is in a single line of code: .frame(width: bigCircle ? 150 : 50, height: bigCircle ? 150 : 50)

We don’t need a computed variable. Thanks to the ternary operator, we can dynamically change the width and height of the circle when bigCircle changes.

At first, ternary operators may be more difficult to read than if…else conditionals. Just remember the they’re functionally identical. So you can read our single line as “If bigCircle, width = 150, else width = 50. If bigCircle, height = 150, else height = 50. “ 

So how do we animate a change from one view to another? That’s another topic for another day...

Level: Easy

If you’re a solo developer, all tasks belong to you. That includes creating app icons and formatting them correctly for different platforms.

Adding app icons to Xcode for iOS/iPadOS apps got much easier in Xcode 14.

Step 1- Create your icon as a 1024 x 1024 px .png file. I use Pixelmator Pro. (You’ll find useful design guidelines for creating your icon here)

Step 2- In Xcode Assets.xcassets add an iOS App icon.

Step 3- In the Attributes inspector, select Single Size.

Step 4- Drag your image onto the 1024 x 1024 px placeholder.

Step 5- In the General settings for your target, add the App Icon name to the App Icons and Launch Screen settings.

Xcode will generate all the image sizes required to submit your app.

But what if you also want to submit a Mac Catalyst version of your app?

That’s where things get more complicated, as I learned when I shipped a Mac Catalyst version of “Remembered: Back Up your Brain”

I discovered two issues:

1. Despite Apple’s documentation which suggests otherwise, Xcode 14 doesn’t have a single size option for macOS App Icons. As of Xcode 15, there’s still no single size option for macOS.

2. If you use your iOS icon artwork for your Mac Catalyst version, it’s going to look odd because,

• the borders won’t be rounded, and
• It’ll look about 24% bigger than most other Mac app icons.

Technically, Apple recommends but doesn’t require rounded corners or even a size that matches most macOS app icons. If you really want your app icon to have square corners, skip step 4 below.

Fortunately, it’s easy to fix these issues. It’s particularly easy to create macOS app icons if you’re a Photoshop, Adobe XD or Sketch user. You’ll find production templates from Apple here and can skip steps 1-5 below.

I use Pixelmator Pro for virtually all of my design needs, so I’m going to use it to show you how to create a macOS app icon, but you should be able to recreate these simple steps in your preferred layer-based design environment. if it has basic features and can export a .png file, you’re good to go.

Step 1- Create an empty document with a 1024 x 1024 px image layer. Pixelmator Pro has a Preset for this called “Mac App Icon 1024”.

Step 2- Change the opacity of the image layer to 0.

Step 3- Add a new layer with a round rectangle. Center it and set its dimensions to 824 x 824 px.

Step 4- Set the corner radius of your round rectangle to 185 px.

There’s considerable debate about the correct corner radius on various forums and discussion boards. This is why using Apple’s production templates is preferred if you have Sketch or XD. I chose 185 empirically by superimposing a round rectangle on top of Apple’s macOS Monterey Photoshop production template. It may not be pixel perfect, but it’s close. Others argue that the correct corner radius is anywhere from 160 to 228 px. A round corner isn’t required, so use what works for you.

Step 5- Apply a black shadow to the round rectangle with these parameters. This is also optional but will give your icon an appearance that’s similar to most others that users will have in their docks.

Congratulations! You now have a template upon which to add the artwork for your icon.

All good, but how do you tell Xcode to use your iOS icon for an iOS archive and your macOS icon for your Mac Catalyst archive?

As noted above, Xcode doesn’t (yet?) allow you to use a single .png file to generate all macOS icon sizes. You can generate these manually and drag them onto each placeholder, but do you really want to do that? I don’t.

There’s a better way. In the Mac App Store you’ll find many utilities that will take your .png file and generate the .appiconset folder that you can drop into Xcode. Some are free. I use “Assets Maker for Xcode”. Grab a copy and follow along:

Step 1- Open “Assets Maker for Xcode” or your preferred asset generator. Select Mac App, drag your mac icon .png file onto it and click “Create Assets”.

Step 2- Select a destination and name for your .appiconset file.

Step 3- This will create a folder containing a “Contents.json” file and .png files in various sizes.

Step 4- Drag this folder into Xcode Assets.xcassets.

Step 5- In the Attributes inspector, change the iOS selection from “None” to “Single Size”

Step 6- Drag your iOS app icon .png file onto the iOS icon placeholder.

You’re done! You now have an AppIcon that contains everything Xcode needs to generate icons for your iOS and Mac Catalyst archives.

In this post, I’ll review some of the tools I rely on as a solo independent developer of apps like Remembered for iOS, Remembered for Mac and Silly Sounds. Most of them are free. The others are reasonably priced. They all have a relatively quick learning curve. I list them here in no particular order. These are the apps and tools I rely on. The links are provided for your convenience. 

*** I do not participate in affiliate programs or otherwise receive compensation if you click a link or purchase one of these. ***

SF Symbols

Don’t even think about creating your own symbols/icons for use in your app without searching Apple’s free, expansive, versatile library. They integrate seamlessly with SwiftUI and UIKit. Can’t find what you need in this 4000+ symbol library? You can modify what’s there or even create your own.

Pixelmator Pro

I use Pixelmator Pro for practically everything other than coding. It’s an intuitive, powerful tool for drawing, illustrating and editing images. In order to submit your app to Apple, you’re going to need to create an app icon and screenshots for all supported devices. The specifications are here. Miss by one pixel and your app submission isn’t going anywhere. Pixelmator Pro has everything you need, and recently added templates make it even easier. It’s reasonably priced and a pleasure to use. Download the free trial and give it a try.

Rotato

Rotato boasts “3D mockup images and movies in minutes” and that’s no exaggeration. If you’ve seen high resolution iPhones, iPads, Macs or other devices sliding, spinning or flipping across your TV or other screens, chances are you’ve seen Rotato in action. It’s that near impossible blend of power and ease of use that most of us can only dream about achieving. Record your app in action in the Xcode simulator or on a device, then use Rotato to make it look like it came from a high-end video production studio. I also use it to create high quality app screenshot images for submission to the App Store. Pixelmator Pro recently added templates that make it easier to do this, but Rotato can generate iPhone screenshots (which it calls “snapshots”) for all iPhone sizes in one click.

iMovie

App previews aren’t required but are highly recommended. Having at least one increases the likelihood that your app will be noticed in the app store. Like screenshots, the specifications for app previews can seem overwhelming. iMovie simplifies this process by giving you the ability to create and export properly formatted videos. Record your app in action using the Xcode simulator or on a device, then follow this guide. Tip: When Apple says your preview video can’t be longer than 30 seconds, they mean 30, not 30.1 seconds. Trim your video in Xcode to make sure it’s no longer than 30.0 seconds.

EverWeb

When you submit your app to Apple for review, you’ll need to provide URLs for a website, user support and privacy policy. There are lots of “no code” web creation options out there. EverWeb arose as an alternative when Apple dropped iWeb and has done a good job of keeping up with modern features while remaining easy to use. I use it because it has built in support for responsive design, includes options for hosting and email, is regularly updated with new or improved features, and has plentiful tutorials. It sometimes gets a bad rap in the developer community because it’s built with Xojo (formerly RealBasic), but it’s the end product that matters. It has some quirks that I must relearn if I haven’t used it for a while, but it’s been a reliable design plus hosting solution for me.

Apps that I find useful but not essential

RocketSim

RocketSim provides numerous enhancements to the Xcode Simulator. You can use it to create screenshots with and without bezels, preview videos, and much more. It gets better with each release. I still use Rotato and Pixelmator Pro for screenshots, but have started using RocketSim to capture preview videos which I then edit in iMovie.

Art Text

Before Pixelmator Pro, Art Text was my go-to design tool. It focuses on text effects but is pretty versatile and simple to use. It’s a bit less expensive than Pixelmator Pro, so you might want to download the free trial if you decide Pixelmator Pro isn’t for you.

Assets Maker for Xcode

Meeting Apple’s strict requirements for app icons has gotten easier with newer versions of Xcode, but old habits die hard. I still use this handy app to generate the required app asset catalogs. Create an app icon in Pixelmator Pro or Art Text, drag it on to this app, done.

Keynote

Keynote isn’t essential, but I use it for text animation in movies on my website. iMovie provides some text animation capabilities, but it’s pretty limited. Text animations are easy to create in Keynote, and bringing them into iMovie is simple.

Digital Color Meter

Want to inspect/copy colors from your screen? You’ll find this in Applications/Utilities.

ImpressKit

Not an app, but a website where you can learn about marketing your app, and easily create and host press kits and press releases to let the world know about your app. Here’s an example.