Learn when to use transition and contentTransition in SwiftUI by asking one question: is the view entering or leaving, or is its content changing in place?

SwiftUI has two modifiers with remarkably similar names:

.transition(...).contentTransition(...)

They both describe how a change should look, and both need an animation to bring that change to life. But they solve two different problems.

Here is the distinction to remember:

Use transition when a view is inserted into or removed from the view hierarchy. Use contentTransition when a view stays in place but the content it displays changes.

That is the entire idea. Let’s make it visible.

The difference at a glance

transition: a view enters or leaves

Consider a view controlled by an if statement:

VStack {  Button(showMessage ? "Remove View" : "Insert View") {    withAnimation {      showMessage.toggle()    }  }  .buttonStyle(.bordered)    ZStack {      if showMessage {        Text("I enter and leave")          .font(.title3.bold())      }    }    .frame(height: 40)}

When showMessage becomes false, the Text view is removed. When it becomes true, the Text view is inserted again.

This can be visually improved by adding a transition to the view that is being inserted or removed

if showMessage {    Text("Hello, SwiftUI!")        .font(.title)        .transition(.slide)}

The .slide transition describes how that insertion and removal should happen.

However, must also apply an animation to the state property that is triggering the animation

Button(showMessage ? "Remove View" : "Insert View") {  withAnimation {    showMessage.toggle()  }}

There are several different transitions that you can apply

Many of these transitions have additional parameters like edges, offsets and scales.

There are two additional transitions that are rather special

Blur-replacement configurations

.transition(.blurReplace.transition(.blurReplace(.downUp)).transition(.blurReplace(.upUp))

The differences are very subtle

Combined Transitions

You can also combine transitions like this

.transition(    .move(edge: .trailing)        .combined(with: .opacity))

In every case, the important fact is not that some state changed. It is that the state change caused the view to enter or leave the hierarchy and the trigger must be within an animation block

If you enjoy my videos, I have a YouTube video on this topic as well

Mastering SwiftUI Transitions – Custom & Built-in Animations

https://www.youtube.com/watch?v=ZmdG0T_58wg

SF Symbol view-transition effects

As a special case of view transitions, there are now SFSymbol transitions too.

These transitions only affect views constructed by SFSymbols

.transition(.symbolEffect(.automatic)).transition(.symbolEffect(.appear)).transition(.symbolEffect(.disappear)).transition(.symbolEffect(.appear.up)).transition(.symbolEffect(.appear.down)).transition(.symbolEffect(.drawOn))   // iOS 26+.transition(.symbolEffect(.drawOff))  // iOS 26+

You can do much more with SFSymbol effect transitions and encourage you to watch my YouTube video on that topic.

SFSymbol Animations in iOS 17

https://www.youtube.com/watch?v=euia2GkPo7U

contentTransition: the view stays, its content changes

Now consider a counter:

struct CounterExample: View {  @State private var count = 0    var body: some View {    VStack(spacing: 20) {      Text(count, format: .number)        .font(.system(size: 64, weight: .bold))      HStack {        Button("Decrease") {          withAnimation {            count -= 1          }        }        Button("Increase") {          count += 1        }      }    }  }}

When you tap on Decrease or Increase the state value changes and the view updates. It is not moving in our out of the view, but the content is changing.

However, the transition from one number to another is not very exciting. We can improve this by applying a contentTransition. Like a transition it too requires two parts. A contentTransition modifier and an animation block surrounding the trigger.

Text(count, format: .number)    .font(.system(size: 64, weight: .bold))    .contentTransition(        .numericText(value: Double(count))    )

And

Button("Decrease") {    withAnimation {        count -= 1    }}Button("Increase") {    withAnimation {        count += 1    }}

In this case, we used a numericText content transition where it is observing the value of the count variable which has to be cast as a Double.

SwiftUI provides five main content-transition families, with two forms of numericText.

Sample content transitions

Once you know that the content is changing in place, SwiftUI offers several useful choices.

Numeric text

Text(count, format: .number)    .contentTransition(.numericText(value: Double(count)))

This is ideal for counters, scores, totals, timers, and changing measurements.

Opacity

Image(systemName: isDaytime ? "sun.max.fill" : "moon.fill")    .contentTransition(.opacity)

This gives changing text or images a simple cross-fade.

Interpolation

Text("Tap to animate")    .font(.system(size: emphasized ? 40 : 32))    .foregroundStyle(emphasized ? .blue : .red)    .contentTransition(.interpolate)

When the text contains matching glyphs, interpolation can animate properties such as size, position, and color.

Symbol replacement

Image(systemName: isLiked ? "heart.fill" : "heart")    .contentTransition(.symbolEffect(.replace))

This is designed for changes between compatible SF Symbols.

A simple decision test

When you are unsure which modifier to use, look at the code that responds to the state change.

Ask these questions in order:

1. Does an if, switch, collection update, or identity change cause a view to appear or disappear?

Start with transition.

2. Does the same Text, Image, or other view remain while its displayed content changes?

Start with contentTransition.

3. Did you provide an animation for the state change?

If not, neither transition will have an animated change to perform.

Final takeaway

The names are similar, but the jobs are not:

View enters or leaves       → transitionView stays, content changes → contentTransition

Once you focus on what actually changed—the hierarchy or the content—the choice becomes straightforward.

And as with all animation, restraint helps. A transition should clarify a change, not compete with it.

You can following along with me as I preform all of these steps in this YouTube video: Distribute Your macOS App Like a Pro DMG, Code Signing & Notarization

1. Archive the app in Xcode.
2. Export the notarized .app.
3. Verify the exported app's signature and Gatekeeper status.
4. Build a polished installer DMG with a background image and an Applications shortcut.
5. Convert the DMG to a compressed read-only image.
6. Sign, notarize, staple, and verify the final DMG.

The commands intentionally use placeholders so this document can be shared safely.

Placeholders Used in This Guide

Some values are known before you start. Others are discovered later from command output or created during the notarization setup. This guide introduces each value when you need it.

Values you choose at the beginning:

<<APPNAME>>                 # App bundle name without .app, for example: MyApp<<VOLUMENAME>>              # Mounted DMG volume name, for example: MyApp Installer<<DMGNAME>>                 # Final DMG filename without .dmg, for example: MyApp

Values you will collect or create later:

<<APPLE_ID>>                # Apple ID email for the Apple Developer account<<TEAM_ID>>                 # Apple Developer Team ID<<NOTARY_PROFILE>>          # Local Keychain profile name for notarytool<<APP_SPECIFIC_PASSWORD>>   # App-specific password generated at account.apple.com<<DEVELOPER_ID_CERT>>       # Developer ID Application certificate name or SHA-1 hash

1. Archive the App in Xcode

Archiving creates the distributable build using your release configuration, signing settings, hardened runtime, entitlements, and provisioning choices. For direct distribution outside the Mac App Store, this is the starting point for a properly signed Developer ID app.

In Xcode:

1. Select a generic macOS destination, not a simulator.
2. Choose Product > Archive.
3. When Organizer opens, select the archive.
4. Click Distribute App.
5. Choose Direct Distribution.
6. Continue through the signing and upload steps.
7. Wait for Apple to process/notarize the archive.
8. Export the notarized app when Xcode allows it.

Expected result:

Xcode Organizer shows the archive as validated/notarized, and you can export a signed .app bundle.

2. Create a Release Builds Folder

Keeping the exported app, temporary DMG, final DMG, and background image in one working folder makes the rest of the process easier to follow. It also avoids accidentally packaging the wrong copy of the app.

Create a folder somewhere convenient, such as your Desktop:

~/Desktop/ReleaseBuilds

In Finder:

1. Open your Desktop.
2. Create a new folder named ReleaseBuilds.
3. Copy the notarized app you exported from Xcode into that folder.

If you already have a background image for the DMG, this is also a good place to put it so everything for this release lives together.

3. Set the Starting Variables

Do this after copying the exported app into ReleaseBuilds and before running the first verification command.

1. Open Terminal.
2. Use cd to move into the ReleaseBuilds folder.
3. Copy the variable block below.
4. Replace the placeholders with your app name, volume name, DMG name, and exported app path.
5. Paste the edited block into Terminal and press Return.

After that, the early commands can use short names like $APP_PATH, $TEMP_DMG, and $FINAL_DMG instead of making you type the full app name and file paths over and over.

Template:

APP_NAME="<<APPNAME>>"VOLUME_NAME="<<VOLUMENAME>>"DMG_NAME="<<DMGNAME>>"APP_PATH="/path/to/${APP_NAME}.app"TEMP_DMG="${DMG_NAME}-temp.dmg"FINAL_DMG="${DMG_NAME}.dmg"

Example using fake values:

cd ~/Desktop/ReleaseBuildsAPP_NAME="MyGreatApp"VOLUME_NAME="MyGreatApp Installer"DMG_NAME="MyGreatApp"APP_PATH="$HOME/Desktop/ReleaseBuilds/MyGreatApp.app"TEMP_DMG="${DMG_NAME}-temp.dmg"FINAL_DMG="${DMG_NAME}.dmg"

With those example values, the guide will create:

MyGreatApp-temp.dmgMyGreatApp.dmg

And when a later command says:

codesign --verify --deep --strict --verbose=2 "$APP_PATH"

Terminal treats it as:

codesign --verify --deep --strict --verbose=2 "$HOME/Desktop/ReleaseBuilds/MyGreatApp.app"

The important thing: Keep using the same Terminal window as you work through the guide. The variables live in that Terminal session.

4. Verify the Exported App Signature

Notarization is not a substitute for local verification. Before packaging the app into a DMG, confirm that the .app bundle is signed correctly and that nested code, frameworks, helpers, and resources pass strict validation.

codesign --verify --deep --strict --verbose=2 "$APP_PATH"

Expected result:

/path/to/<<APPNAME>>.app: valid on disk/path/to/<<APPNAME>>.app: satisfies its Designated Requirement

If this fails, fix the app signing issue before building the DMG.

5. Inspect the App Signing Details

This confirms which Developer ID certificate signed the app. You may also need the team identifier later when storing notarization credentials.

codesign -dv --verbose=4 "$APP_PATH"

Look for these fields:

Authority=Developer ID Application: <<DEVELOPER_NAME>> (<<TEAM_ID>>)TeamIdentifier=<<TEAM_ID>>Runtime Version=...

Copy the value after TeamIdentifier=. You will need it later when you store notarization credentials.

Now save it as a Terminal variable:

TEAM_ID="<<TEAM_ID>>"

6. Check Gatekeeper Assessment for the App

Gatekeeper is what users encounter when opening software downloaded from the internet. This check confirms macOS sees the exported app as acceptable executable code.

spctl -a -t exec -vv "$APP_PATH"

Expected result:

/path/to/<<APPNAME>>.app: acceptedsource=Notarized Developer IDorigin=Developer ID Application: <<DEVELOPER_NAME>> (<<TEAM_ID>>)

The exact wording can vary by macOS version, but you want accepted and a Developer ID/notarized source.

7. Create a Writable Temporary DMG

The temporary DMG is the staging area. You need it writable so you can copy in the app, add the Applications shortcut, add the background image, and set Finder layout preferences.

Choose a size comfortably larger than your app bundle.

diskutil image create blank \  --size 100m \  --volumeName "$VOLUME_NAME" \  --format UDRW \  "$TEMP_DMG"

Expected result:

created: /path/to/<<DMGNAME>>-temp.dmg

If your app is larger, increase 100m to something appropriate, such as 250m or 500m.

8. Mount the Temporary DMG

Mounting exposes the writable disk image as a normal Finder volume under /Volumes, which lets you arrange the installer exactly how users will see it.

In Finder, double-click the temporary DMG:

<<DMGNAME>>-temp.dmg

Expected result: a new mounted volume appears on your Desktop and in Finder's sidebar.

/Volumes/<<VOLUMENAME>>

9. Copy the App into the Mounted Volume

The DMG should contain the app bundle users will drag into Applications.

In Finder:

1. Open the mounted <<VOLUMENAME>> volume.
2. Find your exported <<APPNAME>>.app.
3. Drag <<APPNAME>>.app into the mounted volume.

10. Add the Applications Shortcut

The Applications shortcut gives users the familiar drag-to-install experience: app on the left, Applications on the right.

ln -s /Applications "/Volumes/${VOLUME_NAME}/Applications"

You should now see both the application and the shortcut to the applications folder in the mounted volume.

11. Add the Hidden Background Folder

Finder can use an image stored inside the DMG as the window background. Keeping it in .background keeps the installer window clean for users and under normal circumstances, background folder will be hidden

mkdir -p "/Volumes/${VOLUME_NAME}/.background"

Then, in Finder:

1. Open the mounted volume.
2. Press Command-Shift-. to show hidden files.
3. Open the .background folder.
4. Drag your background image into that folder.

Expected result: the background image is inside /Volumes/<<VOLUMENAME>>/.background/.

12. Configure the Finder Window

Finder stores window layout metadata on the mounted volume. This gives users a clean installer window instead of a plain file listing.

Open the mounted DMG volume in Finder, then set:

1. View > As Icons
2. View > Show View Options or press Command-J
3. Enable Always open in icon view
4. Set icon size, commonly 96 or 128
5. Set text size, commonly 12
6. Set Background > Picture
7. Open the hidden .background folder in Finder.
8. Drag the background image from .background onto the picture drop target in the View Options window.
9. Position <<APPNAME>>.app on the left
10. Position Applications on the right
11. Resize the Finder window to the desired final size
12. Hide hidden files again with Command-Shift-.
13. Close the Finder window

13. Eject the Temporary DMG

Ejecting the mounted volume finalizes the changes you made to the writable temporary DMG.

In Finder:

1. Close the mounted DMG window.
2. Eject the <<VOLUMENAME>> volume from the Finder sidebar or Desktop.

If Finder says the volume is still in use, close any Finder windows showing the mounted DMG and try again.

14. Convert to a Compressed Read-Only DMG

Users should receive a final DMG that is smaller, read-only, and not accidentally modifiable.

diskutil image create from \  "$TEMP_DMG" \  "$FINAL_DMG" \  --format UDZO

You can remove the temporary writable image after confirming the final DMG exists and when mounted and opened, you can see the background image as well as the application and shortcut to the applications folder.

15. Create an App-Specific Password

The notarytool should not use your normal Apple ID password. Apple requires an app-specific password for command-line notarization when using Apple ID authentication.

At account.apple.com:

1. Sign in with the Apple ID for the developer account.
2. Open Sign-In and Security.
3. Choose App-Specific Passwords.
4. Generate a new password.
5. Give it a recognizable name, such as NotaryTool.
6. Copy it immediately.

Expected result:

Apple shows a one-time app-specific password.

Do not paste the real password into documentation, screenshots, source control, issue trackers, or chat. You cannot retrieve it later; if lost, revoke it and create another one.

16. Store Notarization Credentials in Keychain

Storing credentials once in Keychain avoids putting secrets directly into every notarization command.

Before running the command, decide on two values:

1. APPLE_ID: the Apple ID email address for your Apple Developer account.
2. NOTARY_PROFILE: a local nickname for these saved credentials. You choose this name. MyNotaryProfile is a common example.

Save those values in Terminal:

APPLE_ID="<<APPLE_ID>>"NOTARY_PROFILE="<<NOTARY_PROFILE>>"

Example using fake values:

APPLE_ID="developer@example.com"NOTARY_PROFILE="MyNotaryProfile"

Do not define the app-specific password as a Terminal variable. It is a secret, and it is only needed once so notarytool can save it securely in Keychain.

Run this command and replace <<APP_SPECIFIC_PASSWORD>> directly in the command with the app-specific password you just generated.

xcrun notarytool store-credentials "$NOTARY_PROFILE" \  --apple-id "$APPLE_ID" \  --team-id "$TEAM_ID" \  --password "<<APP_SPECIFIC_PASSWORD>>"

Expected result:

Credentials saved to Keychain.

17. Find and Save the Developer ID Certificate

Signing the DMG requires the correct Developer ID Application identity. You can sign with either the certificate name or its SHA-1 hash.

security find-identity -v -p codesigning

Look for:

1) <<SHA_1_HASH>> "Developer ID Application: <<DEVELOPER_NAME>> (<<TEAM_ID>>)"

The SHA-1 hash is not labeled in the output. It is the long 40-character string before the certificate name.

Example using fake values:

1) AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA "Developer ID Application: Example Developer (ABCDE12345)"2) BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB "Developer ID Application: Example Developer (ABCDE12345)"   2 valid identities found

In that example, either AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA or BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB is a SHA-1 hash.

Use the Developer ID Application identity, not a Mac Developer, Apple Development, or Installer certificate.

Copy either the SHA-1 hash or the full certificate name and save it in Terminal. If you see more than one Developer ID Application identity with the same certificate name, use one of the SHA-1 hashes instead of the name so codesign knows exactly which identity you mean.

DEVELOPER_ID_CERT="<<DEVELOPER_ID_CERT>>"

Example using a fake SHA-1 hash:

DEVELOPER_ID_CERT="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

Example using a fake certificate name:

DEVELOPER_ID_CERT="Developer ID Application: Example Developer (ABCDE12345)"

18. Sign the Final DMG

The app inside the DMG is already signed, but the DMG itself is a separate downloadable artifact. Signing it lets macOS verify that the disk image was created by your Developer ID certificate and has not been modified.

codesign \  --force \  --sign "$DEVELOPER_ID_CERT" \  "$FINAL_DMG"

Expected result:

# No output usually means success.

19. Verify the DMG Signature

This catches signing mistakes before notarization.

codesign --verify --verbose=2 "$FINAL_DMG"

Expected result:

<<DMGNAME>>.dmg: valid on disk<<DMGNAME>>.dmg: satisfies its Designated Requirement

20. Inspect the DMG Certificate Details

This confirms the DMG was signed by the intended Developer ID identity.

codesign -dv --verbose=4 "$FINAL_DMG"

Look for:

Authority=Developer ID Application: <<DEVELOPER_NAME>> (<<TEAM_ID>>)TeamIdentifier=<<TEAM_ID>>

21. Submit the DMG for Notarization

Notarization lets Apple scan and approve the distributable artifact. The --wait option keeps the command running until Apple returns a final status.

xcrun notarytool submit "$FINAL_DMG" \  --keychain-profile "$NOTARY_PROFILE" \  --wait

Expected successful result:

id: <<SUBMISSION_ID>>status: Accepted

If the status is not Accepted, fetch the log using the submission ID:

xcrun notarytool log "<<SUBMISSION_ID>>" \  --keychain-profile "$NOTARY_PROFILE"

Use the log to identify what Apple rejected. Common issues include unsigned nested code, missing hardened runtime, invalid entitlements, or packaging the wrong build.

22. Staple the Notarization Ticket

Stapling attaches the notarization ticket to the DMG. This lets users install the app even when macOS cannot immediately contact Apple's notarization servers.

xcrun stapler staple "$FINAL_DMG"

Expected result:

The staple and validate action worked!

23. Validate the Stapled Ticket

This confirms the ticket is attached to the DMG and readable.

xcrun stapler validate "$FINAL_DMG"

Expected result:

The validate action worked!

24. Final Gatekeeper Verification

This is the closest command-line check to what users will experience when opening the downloaded DMG.

spctl \  -a \  -t open \  --context context:primary-signature \  -vv \  "$FINAL_DMG"

Expected result:

<<DMGNAME>>.dmg: acceptedsource=Notarized Developer IDorigin=Developer ID Application: <<DEVELOPER_NAME>> (<<TEAM_ID>>)

Now all you have to do is publish the DMG for download. This can one on your website or through some shared folder. You can also publish it via GitHub Releases and the video mentioned at the top of this blog goes through that process.

In this post, we will investigate the difference between Xcode 26 and Xcode 27, explain why the change was made, and discuss the benefits you get simply by building your app with Xcode 27.

Consider the following code:

import SwiftUI@Observablefinal class DemoModel {    let id = UUID()    init() {        print("DemoModel initialized:", id)    }}struct ContentView: View {    @State private var refreshCount = 0    @State private var model = DemoModel()    var body: some View {        VStack {            Text("Parent refreshes: \(refreshCount)")                .font(.title2)            Button("Refresh Parent View") {                refreshCount += 1            }            .buttonStyle(.borderedProminent)            Divider()            VStack(spacing: 12) {                Text("Child View")                    .font(.headline)                Text(model.id.uuidString)                    .font(.caption.monospaced())                    .multilineTextAlignment(.center)                Text("Watch the console")                    .foregroundStyle(.secondary)            }            .padding()            .background(.thinMaterial, in: .rect(cornerRadius: 12))        }        .padding()    }}

If I execute this code in the preview canvas, when the view loads, the model's id property is used in the child view and it is also printed to the console.

Each time I tap the Refresh Parent View button, only the view enumerating the number of refreshes is updated. There is no reinitialization of the observable model.

This version works perfectly well. ContentView owns both the refresh counter and the model used by the lower portion of the interface.

Although there is nothing technically wrong with this design, the lower portion of the interface really belongs in its own view.

Refactoring the Child View

Let's extract the lower section into a separate ChildView and initialize the model as a SwiftUI @State property for that view.

struct ChildView: View {    @State private var model = DemoModel()    var body: some View {        VStack(spacing: 12) {            Text("Child View")                .font(.headline)            Text(model.id.uuidString)                .font(.caption.monospaced())                .multilineTextAlignment(.center)            Text("Watch the console")                .foregroundStyle(.secondary)        }        .padding()        .background(.thinMaterial, in: .rect(cornerRadius: 12))    }}

Then, in ContentView, remove the model from the parent ContentView then replace the VStack after the Divider with the ChildView.

struct ContentView: View {    @State private var refreshCount = 0    // @State private var model = DemoModel()    var body: some View {        VStack {            Text("Parent refreshes: \(refreshCount)")                .font(.title2)            Button("Refresh Parent View") {                refreshCount += 1            }            .buttonStyle(.borderedProminent)            Divider()            ChildView()        }        .padding()    }}

This version better reflects how SwiftUI views should own their own state. ContentView owns the refresh counter, while ChildView owns the DemoModel it displays.

We I execute this in the canvas we see a very different behaviour.

1. As before, when I load the view, the model is initialized and the id is printed to the console and used in the child view presentation. The difference however, is that it is the ChildView that is doing the initialization and not the parent ContentView.
2. When I tap on the refresh button, the UUID Displayed on the screen never changes.
3. The console prints multiple DemoModel initialized... messages.

The UUID proves that SwiftUI continues to use the original DemoModel stored in @State.

The console tells a different story. Every time the parent view is recreated, the expression DemoModel() is evaluated again, creating additional instances that are immediately discarded.

Same Code, but Xcode 27

If we open and run this same code in Xcode 27 we get an entirely different result.

The UUID still never changes, but this time the console prints only one initialization message.

What's Changed?

In Xcode 26 and earlier, @State is treated as PropertyWrapper whereas in Xcode 27, it is now a Macro

Every tap increments refreshCount, which causes SwiftUI to recreate the ContentView value.

In Xcode 26, recreating the view also reevaluated this expression:

@State private var model = DemoModel()

SwiftUI continued using the existing state storage, but the initialization expression still executed. The newly created object was immediately discarded because SwiftUI already had a stored state value.

The flow looked something like this:

Xcode 26Parent refresh      ↓ContentView recreated      ↓ChildView recreated      ↓DemoModel() called again      ↓New DemoModel instance created      ↓SwiftUI already has state storage      ↓New instance discarded

The important part is that the UUID on screen does not change. SwiftUI is still preserving the original state value. The problem is that extra DemoModel instances are being created along the way and then thrown away.

In Xcode 27, the initialization expression is evaluated lazily when the state storage is first created. Subsequent recreations of the view no longer evaluate DemoModel().

The flow is now much simpler:

Xcode 27Parent refresh      ↓ContentView recreated      ↓ChildView recreated      ↓Existing state storage reused      ↓No new DemoModel instance created

From your perspective as the developer, the code hasn't changed. The behavior behind the scenes has.

Why This Matters

In this sample, the initializer simply prints a message.

Real applications often do much more inside an initializer. They might:

• Open a database.
• Read files from disk.
• Register for notifications.
• Allocate large amounts of memory.
• Perform expensive calculations.
• Start asynchronous work.
• Create timers or observers.

Under the old implementation, that work could happen repeatedly even though every newly created object was immediately discarded.

The new implementation eliminates that unnecessary work.

The Benefits

The improvement is about more than performance.

Your code now behaves the way it appears to behave.

When you write:

@State private var model = DemoModel()

most developers naturally expect DemoModel() to be called exactly once.

That expectation is finally correct.

The benefits include:

• Less unnecessary object creation.
• Better runtime performance.
• Fewer accidental side effects from initializers.
• Reduced memory allocations.
• A simpler mental model for how @State works.

Perhaps the biggest improvement is that the code is now easier to reason about. The object you initialize is the object SwiftUI keeps.

Should You Change Your Existing Code?

The short answer is no.

If you're already using @State to own an @Observable object, there is nothing you need to rewrite. Your code continues to compile and behave exactly the same from the user's perspective.

What changes is what happens behind the scenes.

When you build your app with Xcode 27, SwiftUI no longer repeatedly evaluates the initialization expression for a @State property whenever the enclosing view is recreated. Instead, the initial value is created lazily when the state storage is first established.

You get the benefits automatically.

That means:

• Existing @State code continues to work.
• Fewer unnecessary objects are created.
• Expensive initializers run only when they are actually needed.
• Your app performs less unnecessary work.
• Your code more closely matches your expectations.

As developers, we often get excited about new APIs, new view modifiers, and entirely new frameworks. Sometimes, however, the most valuable improvements are the ones that make existing APIs behave more intuitively.

This is one of those improvements.

You won't need to change a single line of code to benefit from it, but understanding what changed gives you a much better mental model of how @State works in modern SwiftUI.

One issue I have with some SwiftUI picker-style controls, such as ColorPicker, DatePicker, and Toggle, is that they are basically label/content views. The label is aligned to the leading edge and the control itself is aligned to the trailing edge, often leaving more space between them than I want.

For example:

VStack {    ColorPicker("Select Color", selection: $color)    DatePicker("Select Date", selection: $date)    Toggle("Power", isOn: $isOn)}

By default, SwiftUI renders them like this:

But I might want to tighten up the space between the label and the control, and also specify the alignment. For example, here are the same three controls with the first using trailing alignment, the second using center alignment, and the third using leading alignment.

Using HStacks and Spacers

In my experience, most people would solve this by hiding the existing label with .labelsHidden(), embedding each picker in an HStack, adding a replacement Text view for the label, and then using Spacer views to get the desired alignment.

VStack {    HStack {        Spacer()        Text("Select Color")        ColorPicker("Select Color", selection: $color)            .labelsHidden()    }    HStack {        Text("Select Date")        DatePicker("Select Date", selection: $date)            .labelsHidden()    }    HStack {        Text("Power")        Toggle("Power", isOn: $isOn)            .labelsHidden()        Spacer()    }}

This works, but the main issue for me is that I am duplicating the label string.

The tendency might be to use an empty string for the picker label:

ColorPicker("", selection: $color)

However, if you provide an empty string, VoiceOver has no useful label unless you supply one another way.

A better solution

A better solution is to remove the spacers altogether and use a frame with a maxWidth of .infinity and an alignment for the edge you want.

Since the default alignment is center, there is no need to add a frame to the DatePicker.

VStack {    HStack {        Text("Select Color")        ColorPicker("Select Color", selection: $color)            .labelsHidden()    }    .frame(maxWidth: .infinity, alignment: .trailing)    HStack {        Text("Select Date")        DatePicker("Select Date", selection: $date)            .labelsHidden()    }    HStack {        Text("Power")        Toggle("Power", isOn: $isOn)            .labelsHidden()    }    .frame(maxWidth: .infinity, alignment: .leading)}

This is better, but it is still a lot of code and it still does not solve the issue of duplicating the label.

Instead, you can remove the HStack views altogether, along with the corresponding Text views, and apply the frame directly to the picker-style controls.

VStack {    ColorPicker("Select Color", selection: $color)        .frame(maxWidth: .infinity, alignment: .trailing)    DatePicker("Select Date", selection: $date)    Toggle("Power", isOn: $isOn)        .frame(maxWidth: .infinity, alignment: .leading)}

But now we are back to the same issue we had before, where the picker takes up the full width of the enclosing view.

There is a simple solution and that is to apply a fixedSize() modifier to the picker before the frame.

VStack {    ColorPicker("Select Color", selection: $color)        .fixedSize()        .frame(maxWidth: .infinity, alignment: .trailing)    DatePicker("Select Date", selection: $date)÷        .fixedSize()    Toggle("Power", isOn: $isOn)        .fixedSize()        .frame(maxWidth: .infinity, alignment: .leading)}

Now the controls only take up the space they need, while the frame controls the overall alignment.

Create A ViewModifier

If you use this technique a lot, you would be wise to create a ViewModifierand a corresponding View extension

struct EdgeAligned: ViewModifier {    let alignment: Alignment    func body(content: Content) -> some View {        content            .fixedSize()            .frame(maxWidth: .infinity, alignment: alignment)    }}extension View {    func edgeAligned(alignment: Alignment) -> some View {        self.modifier(EdgeAligned(alignment: alignment))    }}

With the extension, we can apply the modifier directly to any picker-style control and just specify the alignment.

VStack {    ColorPicker("Select Color", selection: $color)        .edgeAligned(alignment: .trailing )    DatePicker("Select Date", selection: $date)        .edgeAligned(alignment: .center)    Toggle("Power", isOn: $isOn)        .edgeAligned(alignment: .leading)}

Introduction

Swift enums are one of the most powerful types in the language. Most developers use them to model a fixed set of related values, such as navigation destinations, application state, network results, or user roles.

However, enums have another extremely useful purpose that often gets overlooked: acting as a namespace.

In many projects, you'll eventually find yourself collecting related constants, configuration values, helper methods, feature flags, API endpoints, validation rules, and other code that doesn't naturally belong to a specific type. The question then becomes: where should that code live?

Some developers reach for global constants. Others create utility structs. Still others create singleton objects. While all of these approaches work, there is often a cleaner solution.

In this blog post, we'll look at how enums can be used as namespaces, why they're often preferable to utility structs, how they differ from singletons, and when they are and are not appropriate.

The Problem

As Swift projects grow, it becomes increasingly common to accumulate values that need a home.

Consider this example of three properties that are created outside of any struct, class or enum:

let cornerRadius: CGFloat = 12let padding: CGFloat = 20let animationDuration: Double = 0.3

There is nothing technically wrong with this code, but these constants now live in the global namespace.

As your project grows, global values can become difficult to discover and maintain. They also increase the likelihood of naming conflicts. It is the "difficult to discover" concept that I find most problematic, particularly if I have been away from the project for a while.

Even worse, future developers may have no idea where a value came from when they encounter code like this:

.padding(padding)

The context is missing.

A Better Solution

One way to solve this problem is to create a namespace.

A namespace is a way of grouping related constants, functions, and types together under a common name.

All you need to do is to create the enum and then define your values as static properties or methods/functions.

enum UI {    // Static stored properties    static let cornerRadius: CGFloat = 12    static let padding: CGFloat = 20    static let animationDuration: Double = 0.3    // Static computed properties    static var cardShadowRadius: CGFloat {        cornerRadius / 2    }    // Static methods    static func opacity(        isEnabled: Bool    ) -> Double {        isEnabled ? 1.0 : 0.5    }    static func cardColor(        isSelected: Bool    ) -> Color {        isSelected ? .teal : .yellow    }}

Now, you get the benefit of Xcode's code completion. When you type the enum name followed by a period, You get a list of all the enum's static properties and methods to choose from. All of theses properties and methods for the enum are prefaced with the M icon which stands for member.

VStack {    Text("Hello")}.padding(UI.padding).background(    UI.cardColor(isSelected: true),    in: .rect(cornerRadius: UI.cornerRadius)).shadow(radius: UI.cardShadowRadius).opacity(UI.opacity(isEnabled: true))

The code is now much more self-documenting.

When you see:

UI.padding

you immediately know where the value comes from and what it represents.

Why Use an Enum?

At this point you might be wondering why we chose an enum rather than a struct or class.

The answer is simple: intent.

An enum with no cases cannot be instantiated.

enum UI {    static let padding: CGFloat = 20}

Attempting to create an instance results in a compiler error:

let ui = UI()

This tells every developer reading the code:

This type exists solely to organize related functionality.

That is exactly what we want from a namespace.

Why Not Use a Struct?

Many developers use a struct instead.

struct UI {    static let padding: CGFloat = 20}

This works perfectly well.

The problem is that the struct can still be instantiated.

let io = UI()

The instance serves no purpose because every member is static.

By using an enum, we prevent accidental instantiation entirely and make our intentions clearer.

What else can go in an enum namespace?

We have already seen static stored and computed properties along with static methods, but what else can go in an enum namespace? The answer is quite a bit, provided it is static.

Nested Enum namespaces

A nested enum is perfect when you want to create additional namespaces.

enum API {    static let baseURL =        "https://api.example.com"    enum Endpoints {        static let users = "/users"        static let videos = "/videos"        static let playlists = "/playlists"    }}// Example Usage:let url = API.baseURL + API.Endpoints.videos

Nested Enum with Cases

You can combine a namespace enum with another enum that actually has cases.

enum Theme {    enum Style {        case light        case dark        case system    }// Example Usage:let currentStyle: Theme.Style = .system

Nested Struct

A nested struct is useful when the namespace owns a related model.

enum AppInfo {    struct Version {        let major: Int        let minor: Int        let patch: Int    }}// Example Usage:let version = AppInfo.Version(    major: 1,    minor: 2,    patch: 0)

Nested Class

A nested class is useful when the namespace owns a related service or object that needs to maintain state over time.

enum Utilities {    final class Counter {        private(set) var count = 0        func increment() {            count += 1        }    }}// Example Usage:let counter = Utilities.Counter()counter.increment()print(counter.count)

Nested Protocols

Protocols are a great candidate because they often describe a group of related behaviors.

In this example, it is obvious that the protocol belongs to your networking layer.

enum Networking {    protocol Requestable {        var endpoint: String { get }    }}// Example Usage:struct UserRequest: Networking.Requestable {    let endpoint = "/users"}

Type Alias

Type aliases can become difficult to locate when they are global. It prevents global type aliases from cluttering a project

enum AppTypes {    typealias Completion =        (Result<Void, Error>) -> Void}// Example Usage:func save(    completion: AppTypes.Completion) {    // ...}

Enum Namespace vs Singleton

This is where many developers become confused.

At first glance these patterns can look similar.

Singleton

final class AppInfo {    static let shared = AppInfo()    private init() {}    var appName = "My App"}// Example Usage:AppInfo.shared.appName

Enum Namespace

enum AppInfo {    static let appName = "My App"}// Example Usage:AppInfo.appName

Although the call sites appear similar, the designs are fundamentally different. The singleton represents a single shared object that can maintain state throughout the life of the application. The enum namespace simply groups related values and functionality together and can never be instantiated.

In the case of the singleton, this is possible.

AppInfo.shared.appName = "My New App"

Whereas the enum namespace would produce an error if we tried to do this

AppInfo.appName = "My New App"

When to Use a Namespace

Namespaces are ideal when:

• Everything is static
• No state is stored
• No instance should ever exist
• The goal is organization

Examples include things such as layout constants, API endpoints, validation rules etc

When to Use a Singleton

Singletons are appropriate when:

• Shared state exists
• Resources are managed
• One instance must exist
• The object has a lifecycle

Examples include network managers, cache managers database coordinators etc.

These are fundamentally different from namespaces.

Benefits of Enum Namespaces

As we have discovered, enums:

• Prevent instantiation
• Improve discoverability
• Reduce global namespace pollution
• Make code more self-documenting

Drawbacks of Enum Namespaces

Like any pattern, enum namespaces are not perfect.

• They cannot store state
• They can become dumping grounds so avoid giant namespaces and create focused ones.

Conclusion

Using enums as namespaces is one of those simple Swift techniques that can significantly improve code organization.

By defining an enum with no cases and adding static members, you create a logical grouping of related functionality while preventing accidental instantiation. The pattern communicates intent clearly, reduces namespace pollution, and keeps code easier to discover and maintain.

Just remember that namespaces are not a replacement for extensions or singletons.

If functionality naturally belongs to an existing type, prefer an extension. If you need shared state or resource management, consider a singleton, class, actor, or protocol-based service.

But when all you need is a place to organize related constants, helper methods, and configuration values, an enum namespace is often the cleanest solution available in Swift.

SwiftUI makes presenting sheets incredibly easy, but as an application grows, managing multiple sheets can become messy. It's common to see several Boolean properties dedicated to controlling different presentations:

@State private var showingSettings = false@State private var showingProfile = false@State private var showingHelp = false

This approach works, but it doesn't scale well. Every new sheet requires another state property, additional presentation logic, and more maintenance.

In this blog post, I'll show you a technique I use to simplify sheet presentations by creating an enum that conforms to both View and Identifiable. The result is cleaner code, fewer state properties, and a more scalable architecture.

The Traditional Approach

Consider a view with three buttons that present three different sheets.

struct TradionionalView: View {    @State private var showingSettings = false    @State private var showingProfile = false    @State private var showingHelp = false    var body: some View {        NavigationStack {            VStack {                Button("Settings") {                    showingSettings = true                }                Button("Profile") {                    showingProfile = true                }                Button("Help") {                    showingHelp = true                }            }            .buttonStyle(.bordered)            .navigationTitle("Enum Sheets")            .sheet(isPresented: $showingSettings) {                SettingsView()            }            .sheet(isPresented: $showingProfile) {                ProfileView()            }            .sheet(isPresented: $showingHelp) {                HelpView()            }        }    }}

Although functional, this solution has several drawbacks:

• Multiple Boolean state properties
• Multiple sheet modifiers
• More code to maintain
• Greater chance of presentation conflicts

A Better Solution

Instead of tracking multiple Boolean values, we can track a single enum value representing the sheet that should be presented.

First, create an enum that conforms to Identifiable and View.

enum ActiveSheet: Identifiable, View {    case settings    case profile    case help    var id: Self { self }    var body: some View {        switch self {        case .settings:            SettingsView()        case .profile:            ProfileView()        case .help:            HelpView()        }    }}

This enum serves two purposes:

1. It identifies which sheet should be presented.
2. It knows how to build the view associated with each case.

Presenting the Sheet

Now we only need a single optional state property.

@State private var activeSheet: ActiveSheet?

The main view becomes much simpler.

struct EnumSheetView: View {    @State private var activeSheet: ActiveSheet?    var body: some View {        NavigationStack {            VStack {                Button("Settings") {                    activeSheet = .settings                }                Button("Profile") {                    activeSheet = .profile                }                                Button("Help") {                    activeSheet = .help                }            }            .buttonStyle(.bordered)            .navigationTitle("Enum Sheets")            .sheet(item: $activeSheet) { sheet in               sheet            }        }    }}

That's it.

The sheet modifier receives the enum instance and simply presents it because the enum itself conforms to View.

Why This Works

The .sheet(item:) modifier requires an optional value that conforms to Identifiable.

By making the enum conform to Identifiable, SwiftUI can determine when a new sheet should be presented.

var id: Self { self }

Because each enum case is unique, using self as the identifier works perfectly.

At the same time, conforming to View allows each case to generate its own destination view.

var body: some View {    switch self {    case .settings:        SettingsView()    case .profile:        ProfileView()    case .help:        HelpView()    }}

Because the enum conforms to View, there is no need to add @ViewBuilder to the body property here. The switch branches each return a view, and SwiftUI can infer the result.

The enum becomes both the navigation state and the destination view.

Supporting Associated Values

This pattern becomes even more powerful when working with associated values.

Consider this, where I have a new enum that is similar to ActiveSheet, except that the help case now has an associated value that is a String.

enum ActiveSheet2: Identifiable, View {    case settings    case profile    case help(String)    var id: String {        switch self {        case .help:            return "help"        default:            return String(describing: self)        }    }    var body: some View {        switch self {        case .settings:            SettingsView()        case .profile:            ProfileView()        case .help(let helpString):            HelpView(helpString: helpString)        }    }}

Note. Because the enum has at least one case with an associated value, we needed to change the id property to String and provide a specific value for the help case. For the other two cases that do not have associated values, the id property can be String(describing:

For the enum body, we can extract the associated value from the case and pass that in to the HelpView that can also accept a String parameter

case .help(let helpString):    HelpView(helpString: helpString)}

Presenting a specific user becomes straightforward.

Button("Help") {    activeSheet = .help("This is the associated help string for this second view")}

The enum now carries both the destination type and any data required by the destination.

The Final Refinement

Once the enum conforms to View, the sheet presentation code can be simplified even further.

Many developers write:

.sheet(item: $activeSheet) { sheet in    sheet}

While perfectly valid, the closure is simply returning the value it receives.

Since ActiveSheet already conforms to View, we can shorten this to:

.sheet(item: $activeSheet) { $0 }

This works because the closure parameter is an instance of ActiveSheet, and ActiveSheet is itself a view.

At this point, the enum serves three distinct roles:

• Navigation state
• Sheet identifier
• Sheet content

The entire presentation logic is reduced to a single line of code.

.sheet(item: $activeSheet) { $0 }

This is one of the most compelling reasons to adopt this pattern. The presentation code becomes almost trivial while remaining fully type-safe.

The Evolution of the Pattern

It's interesting to see how this approach evolves as your SwiftUI knowledge grows.

Step 1: Multiple Boolean Properties

@State private var showingSettings = false@State private var showingProfile = false@State private var showingHelp = false

Step 2: A Single Enum State

@State private var activeSheet: ActiveSheet?

Step 3: The Enum Becomes the Destination

enum ActiveSheet: Identifiable, View {    case settings    case profile    case help    var id: Self { self }    var body: some View {        switch self {        case .settings:            SettingsView()        case .profile:            ProfileView()        case .help:            HelpView()        }    }}

Step 4: Presentation Logic Becomes One Line

.sheet(item: $activeSheet) { $0 }

At this stage, the enum completely encapsulates the sheet presentation logic. All the view needs to do is assign the appropriate case.

Advantages of This Pattern

Single Source of Truth

Only one state property controls all sheet presentations.

@State private var activeSheet: ActiveSheet?

Easy to Extend

Adding another sheet only requires a new enum case.

case about

And one additional switch branch.

case .about:    AboutView()

Better Organization

All sheet destinations live in one place instead of being scattered throughout the view hierarchy.

Type Safety

The compiler ensures every case is handled in the switch statement.

Less Boilerplate

No more collection of Boolean flags cluttering your view.

When Should You Use This?

This pattern works especially well when:

• A view can present multiple sheets
• Sheet destinations are known in advance
• You want centralized presentation logic
• You want to reduce state management complexity

For simple views with a single sheet, the traditional Boolean approach is perfectly acceptable. However, once you have three or more destinations, this enum-based approach often becomes easier to maintain.

Complete Example

enum ActiveSheet2: Identifiable, View {    case settings    case profile    case help(String)    var id: String {        switch self {        case .help:            return "help"        default:            return String(describing: self)        }    }    var body: some View {        switch self {        case .settings:            SettingsView()        case .profile:            ProfileView()        case .help(let helpString):            HelpView(helpString: helpString)        }    }}struct EnumAssociatedValueView: View {    @State private var activeSheet: ActiveSheet2?    var body: some View {        NavigationStack {            VStack {                Button("Settings") {                    activeSheet = .settings                }                Button("Profile") {                    activeSheet = .profile                }                                Button("Help") {                    activeSheet = .help("This is the associated help string for this second view")                }            }            .buttonStyle(.bordered)            .navigationTitle("Enum Sheets")            .sheet(item: $activeSheet) { sheet in                sheet            }        }    }}

The Same Pattern Works with fullScreenCover

One of the benefits of having your enum conform directly to View is that the same approach works with fullScreenCover.

Instead of:

.sheet(item: $activeSheet) { $0 }

You can simply write:

.fullScreenCover(item: $activeSheet) { $0 }

The enum doesn't care whether it is being presented as a sheet or a full-screen cover. It is still responsible for generating the destination view.

struct EnumSheetView: View {    @State private var activeSheet: ActiveSheet?    var body: some View {        NavigationStack {            VStack {                Button("Settings") {                    activeSheet = .settings                }                Button("Profile") {                    activeSheet = .profile                }                                Button("Help") {                    activeSheet = .help                }            }            .buttonStyle(.bordered)            .navigationTitle("Enum Sheets")            .fullScreenCover(item: $activeSheet) { $0 }        }    }}

This flexibility can be particularly useful when requirements change. You may initially present content as a sheet and later decide it should be full-screen. With this pattern, the only change required is swapping the presentation modifier.

.sheet(item: $activeSheet) { $0 }

becomes

.fullScreenCover(item: $activeSheet) { $0 }

Everything else remains exactly the same.

The enum continues to provide:

• Navigation state
• Unique identification
• Destination content

This further demonstrates how powerful it can be to allow the enum to own the presentation logic.

Final Thoughts

Using enums that conform to View is a simple but powerful SwiftUI technique. It allows you to combine navigation state and destination views into a single type, resulting in cleaner, more maintainable code.

The next time you find yourself adding a fourth or fifth Boolean property just to present another sheet, consider replacing them with a single enum. Your future self will thank you.

GitHub Repo:

You can find a the completed source code on GitHub.

https://github.com/StewartLynch/EnumSheets

Introduction

In the previous article Swift Initializers: Understanding Initializers in Structs, we explored initializers in structs.

Structs are relatively straightforward because they do not support inheritance.

Classes introduce additional complexity because they participate in inheritance hierarchies. Swift must ensure that both a class and all of its superclasses are fully initialized before an object can be used.

The other important and significant difference between structs and classes is that classes do not provide a memberwise initializer. All classes must include an initializer if any stored property does not have a default value.

In this article, you'll learn how class initializers work, the difference between designated and convenience initializers, initializer inheritance, required initializers, failable initializers, and Swift's two-phase initialization process.

Why Class Initializers Are Different

If you create a class with properties that have default values and you do not provide an initializer, you cannot create a new instance of that class and specify different values for the properties at the time of creation.

class ClassUser {    var name: String = "Stewart"    var isPremium: Bool = false}let user1 = ClassUser()

If there were a struct, however, you still get a memberwise initializer by default and have all of the different options for initializers.

struct StructUser {    var name: String = "Stewart"    var isPremium: Bool = false}let user2 = StructUser()let user3 = StructUser(isPremium: true)let user4 = StructUser(name: "Emily")let user5 = StructUser(name: "Aidan", isPremium: true)

Classes with no default property values

All stored properties in the class must be initialized so if there are no default values, these must be addressed in the initializer.

An initializer is a special type of member of a class or struct whose job is to create and prepare a new instance for use.

The init keyword is identifies the initializer and the initializer parameters are the values and types that callers can provide during initialization. So if your properties do not have default values assigned, the initializer must have a parameter that is used in the initializer body assign the provided values to the corresponding object properties.

If the parameter names are the same as the property names, then in the initializer body, self.is used in front of the property name to refer to the property and avoid ambiguity.

class User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }}

Constant Properties and Initialization

The rules for constant properties in classes are the same as those for constant properties in structs. They must receive values before initialization completes and they cannot be changed afterwards

class ClassUser {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }}let user = ClassUser(name: "Stewart", isPremium: false)user.isPremium = true // Error

Initializer Parameter Labels

You can add additional external parameter labels to that are different from the property names. The purpose of external initializer parameter labels is to make code more readable and self-documenting at the point where an instance is created.

class ClassUser {    var nom: String    var estPremiume: Bool    init(name nom: String, isPremium estPremiume: Bool) {        self.nom = nom        self.estPremiume = estPremiume    }}let user = ClassUser(name: "Stewart", isPremium: true)

Default Parameter Values

You can provide default parameter values for one or more of your properties in the initializer parameters to make an initializer easier to use by providing sensible defaults for parameters that callers don’t always need to specify.

Each default parameter value will add an additional initializer option upon creation.

class User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool = false) {        self.name = name        self.isPremium = isPremium    }}let user = User(name: "Stewart")  // isPremium is falselet user2 = User(name: "Stewart", isPremium: true)

Designated Initializers

A designated initializer is the primary initializer of a class. Its responsibility is to ensure that all of the class’s stored properties receive values and that initialization continues up the inheritance chain by calling a designated initializer in the superclass as you will see. It is responsible for fully initializing the class.

class User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }}

Convenience Initializers

A convenience initializer is an initializer that provides an easier or more specialized way to create an instance, while delegating the actual work of initialization to a designated initializer.

If a designated initializer is the master initializer, a convenience initializer is a shortcut.

class Video {    let title: String    let duration: Int    init(title: String, duration: Int) {        self.title = title        self.duration = duration    }    convenience init(title: String) {        self.init(            title: title,            duration: 0        )    }}let video = Video(title: "Understanding Initializers") // Duration = 0let video2 = Video(title: "Understanding Initializers", duration: 40)

Now you may be wondering how this differs from the example in Default Parameter Values above and this example there is really no difference. Why not just write it like this?

class Video {    let title: String    let duration: Int    init(title: String, duration: Int = 0) {        self.title = title        self.duration = duration    }}let video = Video(title: "Understanding Initializers") // Duration = 0let video2 = Video(title: "Understanding Initializers", duration: 40)

However, you can take advantage of convenience initializers to communicate intent. For example, in the convenience initializer for this class, we can change the parameter label to clarify what this initializer is intended for.

class Video {    let title: String    let duration: Int    init(title: String, duration: Int) {        self.title = title        self.duration = duration    }    convenience init(draftTitle: String) {        self.init(            title: draftTitle,            duration: 0        )    }}let video = Video(draftTitle: "Understanding Initializers") // Duration = 0let video2 = Video(title: "Understanding Initializers", duration: 40)

Designated vs Convenience Initializers

Designated initializers fully initialize the class.

Convenience initializers must call another initializer in the same class using self.init(...).

Class Inheritance

In the article on structs, initialization was relatively straightforward because structs do not support inheritance.

Classes are different.

A class can inherit properties and behavior from another class.

Consider this example:

class Person {    let name: String      init(name: String) {        self.name = name    }}

Now let’s create a subclass:

class Employee: Person {    let employeeID: Int    init(name: String, employeeID: Int) {        self.employeeID = employeeID        super.init(name: name)    }}

An Employee contains everything that belongs to a Person plus its own additional information.

Person

​ └─ name

Employee

├─ name

└─ employeeID

When an Employee is created, Swift must ensure that:

1. employeeID receives a value.
2. name receives a value.
3. Both the Employee portion and the Person portion are properly initialized.

This is where initialization becomes more complicated than it was for structs.

class Employee: Person {    let employeeID: Int    init(name: String, employeeID: Int) {        self.employeeID = employeeID    }}

What value should name have?

The superclass has not been initialized.

Swift prevents situations like this by enforcing a set of initialization rules.

Building an Object from the Bottom Up

The subclass initializes its own stored properties first:

self.employeeID = employeeID

Then it asks the superclass to initialize its properties

super.init(name: name)

Only when every class in the hierarchy has finished initialization is the object considered ready to use.

Without these rules, Swift could allow partially initialized objects to exist

let employee = Employee(...)

might contain a valid employeeID but an uninitialized name.

Swift’s initialization system prevents that from ever happening.

This focus on safety is the reason Swift introduces designated initializers, convenience initializers, and the delegation rules that we’ll examine next.

Understanding Swift's Three Delegation Rules

When Swift introduced designated and convenience initializers, it also introduced three rules that govern how they interact.

Rule 1

A Designated Initializer Must Call a Designated Initializer from Its Immediate Superclass

class Person {    let name: String    init(name: String) {        self.name = name    }}class Employee: Person {    let employeeID: Int    init(name: String, employeeID: Int) {        self.employeeID = employeeID        super.init(name: name) // This calls the Person designated initializer    }}

• Subclass properties must be initialized before calling super.init().

• Designated initializers move up the inheritance chain.

Rule 2

A Convenience Initializer Must Call Another Initializer in the Same Class

class User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }    convenience init(name: String) {        self.init(name: name, isPremium: false) // this calls the User initializer    }}

• Convenience initializers move across the same class.

Rule 3

A Convenience Initializer Must Ultimately End Up Calling a Designated Initializer

Every initialization path must eventually reach a designated initializer.

Remember

Convenience → AcrossDesignated → Up

Overriding Initializers

A subclass can override an initializer of the superclass.

Overriding an initializer allows a subclass to customize how an inherited initialization process works.

In this example, the Employee class overrides the initializer inherited from Person.

Notice the use of the override keyword. This tells Swift that we’re replacing the implementation provided by the superclass.

The override initializer in the Employee class first initializes the employeeID, giving every user a unique ID during initialization and only then can the initializer delegate to the superclass

class Person {    let name: String    init(name: String) {        self.name = name    }}class Employee: Person {    let employeeID: Int    override init(name: String) {        self.employeeID = Int.random(in: 1000...9999)        super.init(name: name)    }}

Swift follows these steps.

Employee.init(name:)

​ │

​ ▼

employeeID initialized

​ │

​ ▼

Person.init(name:)

​ │

​ ▼

name initialized

​ │

​ ▼

Object ready to use

Required Initializers

Sometimes a superclass needs to ensure that every subclass provides a particular initializer.

The purpose of required is not to force a subclass to call super.init(name:).

The purpose of required is to force a subclass to provide an initializer with the same signature.

Consider this class

class Person {    let name: String    required init(name: String) {        self.name = name    }}

Now consider this subclass

class Employee: Person {    let employeeID: Int    init(name: String,employeeID: Int) {        self.employeeID = employeeID        super.init(name: name)    }}

This fails because the required superclass init must be provided by the Employee subclass.

class Employee: Person {    let employeeID: Int    required init(name: String) {           self.employeeID = 0           super.init(name: name)       }    init(name: String,employeeID: Int) {        self.employeeID = employeeID        super.init(name: name)    }}

Failable and Throwing Initializers

Failable and throwing initializers work exactly the same in classes as they do in structs. The primary difference is that subclasses must also account for failures or errors that may occur when calling superclass initializers. If a superclass initializer can fail or throw, subclasses must handle that behavior as part of their own initialization process.

class Person {    let name: String    init?(name: String) {        guard !name.isEmpty else {            return nil        }        self.name = name    }}class Employee: Person {    let employeeID: Int    init?(        name: String,        employeeID: Int    ) {        self.employeeID = employeeID        super.init(name: name)    }}let employee = Employee(name: "",employeeID: 1001) // nil

In this example, super.init(name: name) fails because name is empty. Since the superclass initializer is failable, the subclass initializer must also be failable

Final Example

Here is an example of a Course class with a VideoCourse subclass

The Course has a throwing initializer as well as a convenience initializer.

Similarly, VideoCourse has a throwing initializer and a convenience initializer o its own.

enum CourseError: Error {    case emptyTitle    case invalidDuration}class Course {    let title: String    let lessonCount: Int    let isPublished: Bool    init(        title: String,        lessonCount: Int,        isPublished: Bool    ) throws {        guard !title.isEmpty else {            throw CourseError.emptyTitle        }        self.title = title        self.lessonCount = lessonCount        self.isPublished = isPublished    }    convenience init(title: String) throws {        try self.init(            title: title,            lessonCount: 1,            isPublished: false        )    }}class VideoCourse: Course {    let durationInMinutes: Int    init(        title: String,        lessonCount: Int,        isPublished: Bool,        durationInMinutes: Int    ) throws {        guard durationInMinutes > 0 else {            throw CourseError.invalidDuration        }        self.durationInMinutes = durationInMinutes        try super.init(            title: title,            lessonCount: lessonCount,            isPublished: isPublished        )    }    convenience init(title: String) throws {        try self.init(            title: title,            lessonCount: 1,            isPublished: false,            durationInMinutes: 60        )    }}// Uses the videoCourse initializerlet swiftUICourse = try VideoCourse(    title: "Mastering SwiftUI",    lessonCount: 42,    isPublished: true,    durationInMinutes: 540)// Uses the VideoCourse convenience initializerlet draftCourse = try VideoCourse(    title: "Introduction to Swift")// Fails the validation in VideoCourse where the duration must be > 0let course = try VideoCourse(    title: "SwiftUI",    lessonCount: 20,    isPublished: true,    durationInMinutes: 0)// Fails the validation where a Course title cannot be emptylet course2 = try VideoCourse(    title: "",    lessonCount: 20,    isPublished: true,    durationInMinutes: 10)

Conclusion

Class initialization builds on the concepts you learned with structs but adds inheritance, designated initializers, convenience initializers, required initializers, and two-phase initialization.

Remember:

Convenience goes across. Designated goes up.

Introduction

Over the years, I have created a number of videos address the topic of initializers in Swift. If you are interested in those videos instead of reading this blog, you can find them here.

Everyone has their own learning style, so I thought that for those of you who prefer written content over YouTube videos, I would create an blog post and see if that works for you.

This is the first of two posts on initializers and in this one, I will focus on initializers in structs.

One of the first things you'll encounter when learning Swift is the concept of an initializer. Every instance of a struct must be initialized before it can be used. An initializer ensures that all stored properties have valid values before an instance becomes available.

We'll begin with the basics and progressively explore more advanced initialization techniques.

Why Do We Need Initializers?

When you create an instance of a struct, you need to provide values for all its stored properties.

Swift requires every stored property to have a value before an instance can exist.

For example, consider the following struct.

struct User {    var name: String    var isPremium: Bool}

If we just try to create an instance of user withouth providing values for all of its stored properties, we get an error. Fortunately, as you will see shortly, Swift will do its best to prevent us from trying to do this.

let user = User() // Error

Default Property Values

When you create your struct, you can provide default values for all of the store properties and when you do this, where we failed previous, we now succeed.

struct User {    var name: String = "Guest"    var isPremium: Bool = false}

let user = User() // OK

The Memberwise Initializer

Earlier, I mentioned that Swift will do its best to prevent us from trying to create an instance of a struct without providing values for all of its stored properties. This is unique to structs and does not apply to classes as you will learn in the next post. Swift automatically creates a memberwise initializer for structs that do not define their own initializer.

This means, when you start to create an instance of your struct, Xcode will automatically provide you with all of the properties that have not yet been initialized so you can provide values for them

struct User {    var name: String    var isPremium: Bool}let user = User(name: "Stewart", isPremium: true)

Constant Properties and Initialization

One of the primary reasons initializers exist is to provide values for constant properties.

struct User {    let name: String    let age: Int}

let user = User(name: "Stewart", age: 75)

After initialization, these values cannot be changed.

user.name = "Bob" // Error

Constants make your types safer because they cannot be modified after creation. Some of the most common uses for constants are IDs and creation dates.

Memberwise Initializers and Default Values

If you have properties that do have a default value assigned, you will get additional memberwise initializes so that you can override the default value.

struct User {    var name: String    var isPremium: Bool    var age = 74}let user = User(name: "Stewart", isPremium: true)orlet user = User(name: "Stewart", isPremium: true, age: 75)

If there is more than one property that has a default value assigned, Xcode will collapse them into a single line where the ones with default values are dimmed out so of you press enter on your keyboard you will get only those properties that do not have a value assigned and the other values will be assigned their default values.

struct User {    var name: String    var isPremium: Bool    var age = 74    var sex = "M"}

If, when creating the instance, you continue to type the names or partial names of the properties that have default values, they will be no longer be dimmed, and tapping on the keyboard will crate the memberwise initializer for all of those properties

The other alternative is to use the right arrow key on your keyboard to present all possible initializers for the structure and you can choose which one you want.

Custom Initializers

If memberwise initializers did not exist, as you will see in the next post for classes, you would have to create your own initializer.

For example, in our struct that we started with

struct User {    var name: String    var isPremium: Bool}

The initializer, which is basically a method that requires parameters for all properties that do not have a default value and assign those parameters to the corresponding properties.

init(name: String, isPremium: Bool) {  self.name = name  self.isPremium = isPremium}

This is what we will have to do with classes as you will see in the next post.

The confusing part for beginners is the use of the syntax self.name = name

self.name refers to the actual property instance, and not the parameter, so we need to avoid ambiguity.

There is no reason why we need to use the same strings for our parameter labels as our properties however. This is just convention. If we do not use the same strings, then we can avoid using self. For example the following is a perfectly legitimate initializer.

Note that when creating an instance of User, the initializer parameter labels are used.

struct User {    var name: String    var isPremium: Bool    init(initialName: String, initialIsPremium: Bool) {        name = initialName        isPremium = initialIsPremium    }}let user = User(initialName: "Stewart", initialIsPremium: true)

I am not a supporter of doing this however, because it can lead to confusion. It is likely wiser to use external parameter labels instead.

Initializer Parameter Labels

Initializer parameters support both external and internal names.

struct Video {    let nom: String    init(videoTitle nom: String) {        self.nom = nom    }}

Usage:

let video = Video(videoTitle: "Swift Initializers")

Here:

• videoTitle is the external label
• nom is the internal parameter name

When an instance is created, the initializers uses the external label and then assigns whatever was provided to the property in your struct that has the internal label.

Good labels can create self-documenting code, particularly if you are dealing with an API where the property names are not obvious.

let video = Video(videoTitle: "Swift Initializers")

This may clearer to English speakers than:

let video = Video(nom: "Swift Initializers")

Omitting External Labels

Sometimes, you don't want to have to provide a label at all and you can do this by providing an _ as the external parameter label

struct Video {    let title: String    init(_ title: String) {        self.title = title    }}

let video = Video("Swift Initializers")

Use omitted labels sparingly and only when the meaning is obvious.

Preserving the Memberwise Initializer

One of the initial drawbacks of creating a custom initializer is that you lose the memberwise version. This can be resolved however, by creating an extension to the struct, and creating your custom initializer in the extension instead, you get both

struct User {    let name: String    let isPremium: Bool}extension User {    init(name: String) {        self.init(name: name, isPremium: false)    }}

Now both the memberwise initializer and the custom initializer are available.

Multiple Initializers

You can also create multiple initializers for a struct. By doing so, you can create a version of an initializer that will assign a default value for one of the properties as you see in this example, where the second initializer assigns false to the stored isPremium property.

struct User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }    init(name: String) {        self.name = name        self.isPremium = false    }}

You can use multiple initializers when there are multiple valid ways to create an instance.

Initializer Delegation

And there is an another way to accomplish the same thing as above by using initializer delegation. Delegation can avoid duplication by having one initializer call another

For example, here, the second initializer

struct User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool) {        self.name = name        self.isPremium = isPremium    }    init(name: String) {        self.init(name: name, isPremium: false)    }}

Convenience Initializer for Structs

There is a simpler way to accomplish exactly the same thing as the above two example. You can provide a default value right within the initializer itself

struct User {    let name: String    let isPremium: Bool    init(name: String, isPremium: Bool = false) {        self.name = name        self.isPremium = isPremium    }}

Both

Failable Initializers

Initializers can be failable too. You add ? to the end of of the init.

struct EmailAddress {    let value: String    init?(value: String) {        guard value.contains("@") else {            return nil        }        self.value = value    }}

let valid = EmailAddress(value: "stewart@example.com") // valid Optional<EmailAddress>let invalid = EmailAddress(value: "invalid") // nil

Use init? when initialization should either succeed or fail.

Throwing Initializers

Initializers can also throw errors and this can be handy if you want to provide detailed failure information. These are better in my opinion than Failable initializers.

enum PasswordError: Error {    case tooShort    case missingNumber}struct Password {    let value: String    init(value: String) throws {        guard value.count >= 8 else {            throw PasswordError.tooShort        }        guard value.contains(where: \.isNumber) else {            throw PasswordError.missingNumber        }        self.value = value    }}

Final Example

Putting it all together, here is an example of a Course struct that

• Default parameter values
• Validation
• Throwing initialization
• Delegating initialization

enum CourseError: Error {    case emptyTitle    case invalidLessonCount}struct Course {    let title: String    let lessonCount: Int    let isPublished: Bool    init(        title: String,        lessonCount: Int,        isPublished: Bool = false    ) throws {        guard !title.isEmpty else {            throw CourseError.emptyTitle        }        guard lessonCount > 0 else {            throw CourseError.invalidLessonCount        }        self.title = title        self.lessonCount = lessonCount        self.isPublished = isPublished    }    init(draftTitle: String) throws {        try self.init(            title: draftTitle,            lessonCount: 1,            isPublished: false        )    }}

Conclusion

Most structs begin life with default values or Swift's synthesized memberwise initializer. As your types become more sophisticated, custom initializers allow you to validate input, simplify APIs, and prevent invalid state.

A good progression is:

1. Start with the memberwise initializer.
2. Add default values where appropriate.
3. Create custom initializers when business rules emerge.
4. Delegate whenever possible.
5. Use failable or throwing initializers when validation is required.

Understanding these patterns will make your Swift code safer, clearer, and easier to maintain.

------

YouTube videos on Initializers

Here are some videos that I have created on YouTube on Initializers.

The first two were back in 2020

Initializers Part I

https://youtu.be/qtR13ygYEns)

Initializers Part II

https://youtu.be/We4rLsgKAws

And then I created another one in 2024 with much of the same content, but presented in a slightly different way.

Understanding Swift Initializers

https://youtu.be/ElfPQZ9MVTQ

Return to introduction

As I am doing that, I thought that it might be helpful to write a blog post for my website about how to generate a QR code from a string and present it on the screen so that is what this blog post is about.

The Goal

We want a tiny helper that lets us write this:

if let image = QRCodeGenerator.image(from: "https://www.createchsol.com") {    image        .interpolation(.none)        .resizable()        .scaledToFit()}

The helper should hide the Core Image setup so the view does not have to know anything about filters, contexts, image extents, or scaling transforms.

Why Use an Enum?

For this example, QRCodeGenerator is an enum with static functions:

enum QRCodeGenerator {    static func image(from text: String) -> Image? {        // Generate a QR code image    }}

This is a nice fit because the type does not need to store app state. It is more like a toolbox than an object. You are not creating "a QR code generator" that has a lifecycle; you are calling a utility function that converts input into output.

Using an enum with no cases also prevents accidental initialization:

let generator = QRCodeGenerator() // Not possible

That is exactly what we want for a simple namespace.

The Core Image Filter

Apple gives us a built-in QR code filter through Core Image:

CIFilter.qrCodeGenerator()

The filter expects its message as Data, so a Swift String needs to be converted first:

filter.message = Data(text.utf8)

It also supports an error correction level:

filter.correctionLevel = "M"

The common levels are:

• L: Low
• M: Medium
• Q: Quartile
• H: High

Higher correction levels make the QR code more resilient if it is partially damaged or obscured, but they can also make the code denser. M is a sensible default for everyday generated codes.

The QRCodeGenerator Type

There are two imports besides SwiftUI.

I import CoreImage.CIFilterBuiltins so I can use Core Image’s typed, Swift-friendly filter APIs like CIFilter.qrCodeGenerator(). It avoids older string-based filter creation and gives clearer, safer code with autocomplete for properties like message and correctionLevel

I import UIKit because the generator returns a UIImage.

Here is the full helper:

import CoreImage.CIFilterBuiltinsimport SwiftUIimport UIKit@MainActorenum QRCodeGenerator {    private static let context = CIContext()    static func image(from text: String) -> Image? {        guard let uiImage = uiImage(from: text) else { return nil }        return Image(uiImage: uiImage)    }    static func uiImage(from text: String) -> UIImage? {        let filter = CIFilter.qrCodeGenerator()        filter.message = Data(text.utf8)        filter.correctionLevel = "M"        guard let outputImage = filter.outputImage else { return nil }        let scaledImage = outputImage.transformed(            by: CGAffineTransform(scaleX: 12, y: 12)        )        guard let cgImage = context.createCGImage(            scaledImage,            from: scaledImage.extent        ) else {            return nil        }        return UIImage(cgImage: cgImage)    }}

There are two public functions here:

• image(from:) returns a SwiftUI Image, which is convenient for displaying in a view.
• uiImage(from:) returns a UIImage, which is useful if you later want to share, save, or render the QR code into another image (and I do that in the sample project referenced at the end of this post).

The SwiftUI function simply builds on top of the UIKit function.

Why Scale the Output Image?

Core Image's QR code output starts very small. If you display it directly and let SwiftUI stretch it, the result can become blurry.

This line scales the Core Image output before turning it into a CGImage:

let scaledImage = outputImage.transformed(    by: CGAffineTransform(scaleX: 12, y: 12))

Then, when displaying the final image in SwiftUI, use:

.interpolation(.none)

That tells SwiftUI not to smooth the hard edges. QR codes are supposed to look like crisp little block mosaics, not soft watercolor paintings.

A Minimal SwiftUI Example

Here is a small view that uses the helper:

import SwiftUIstruct ContentView: View {    @State private var text = ""    @State private var qrCodeText = ""    private var qrCodeImage: Image? {        guard !qrCodeText.isEmpty else { return nil }        return QRCodeGenerator.image(from: qrCodeText)    }    var body: some View {        NavigationStack {            Form {                Section("QR Code Content") {                    TextField("Enter text or a URL", text: $text)                        .textInputAutocapitalization(.never)                        .autocorrectionDisabled()                    Button("Generate QR Code") {                        let trimmedText = text.trimmingCharacters(                            in: .whitespacesAndNewlines                        )                        guard !trimmedText.isEmpty else { return }                        qrCodeText = trimmedText                    }                    .disabled(                        text.trimmingCharacters(in: .whitespacesAndNewlines).isEmpty                    )                }                if let qrCodeImage {                    Section("Preview") {                        qrCodeImage                            .interpolation(.none)                            .resizable()                            .scaledToFit()                            .frame(width: 240, height: 240)                            .padding()                            .background(.white)                    }                }            }            .navigationTitle("QR Code Generator")        }    }}

Notice the two pieces of state:

@State private var text = ""@State private var qrCodeText = ""

text is what the user is currently typing. qrCodeText is the committed value used to generate the QR code.

That small separation keeps the UI predictable. The QR code changes only when the user taps the button, not every time a character is typed.

Handling Failure

Both of the QRCodeGenerator image functions return optionals:

static func image(from text: String) -> Image?static func uiImage(from text: String) -> UIImage?

That is intentional. QR generation can fail, especially with very large strings. Returning nil gives the view a clean way to show a fallback message:

if let image = QRCodeGenerator.image(from: qrCodeText) {    image        .interpolation(.none)        .resizable()        .scaledToFit()} else {    ContentUnavailableView(        "QR Code Unavailable",        systemImage: "qrcode",        description: Text("Enter shorter text and try again.")    )}

Where the Full Sample App Goes Further

You can find a full sample application on GitHub. https://github.com/StewartLynch/QRCodeGenerator

The full GitHub sample app builds on this focused helper with:

• A larger text editor
• Empty-state handling
• Reset behavior
• A polished preview
• Share sheet support
• A custom share image that includes both the QR code and the original text

But the core idea remains the same: keep the QR generation logic isolated in one small type, then let SwiftUI focus on the user experience.

That separation is the quiet win. The view handles interaction. The generator handles generation. Each part has one job, and neither has to pretend to be the other.

Many apps give users a simple choice for how the interface should look:

• Follow the system appearance
• Always use light mode
• Always use dark mode

SwiftUI makes this surprisingly easy. The trick is to model the choice once, save it with @AppStorage, and apply it at the root of your app with preferredColorScheme.

In this post, we will build an appearance mode setting that can be reused in almost any SwiftUI application.

The Goal

We want the user to choose an appearance mode from inside the app. Once selected, the app should update immediately and remember that choice the next time it launches.

The finished behavior looks like this:

• System follows the device's current light or dark mode setting.
• Light forces the app to use light mode.
• Dark forces the app to use dark mode.
• The selected value persists across launches.
• Navigation views and modal sheets inherit the selected appearance.

Create the Appearance Mode Type

Start by creating an enum to represent the three supported modes.

import SwiftUIenum AppearanceMode: String, CaseIterable, Identifiable {    case system    case light    case dark    var id: Self { self }    var title: String {        switch self {        case .system:            "System"        case .light:            "Light"        case .dark:            "Dark"        }    }    var iconName: String {        switch self {        case .system:            "sun.righthalf.filled"        case .light:            "sun.max.fill"        case .dark:            "moon.fill"        }    }    var colorScheme: ColorScheme? {        switch self {        case .system:            nil        case .light:            .light        case .dark:            .dark        }    }}

There are a few useful details here.

CaseIterable lets us build a picker by looping over all cases. Identifiable makes the enum convenient to use in ForEach. The title and iconName properties keep display details close to the option they describe.

The most important property is colorScheme.

var colorScheme: ColorScheme? {    switch self {    case .system:        nil    case .light:        .light    case .dark:        .dark    }}

preferredColorScheme accepts an optional ColorScheme. Passing .light or .dark forces that appearance. Passing nil tells SwiftUI not to override the system appearance.

That makes nil the perfect value for the System option.

Save the Selection with AppStorage

Because AppearanceMode is backed by a String raw value, it works well with @AppStorage.

@AppStorage("appearanceMode") private var appearanceMode = AppearanceMode.system

This stores the user's choice in UserDefaults. When the value changes, SwiftUI updates any view that depends on it. When the app launches again, the saved value is restored automatically.

You can use any key name you like, but keep it stable once your app ships. Changing the key later would make existing users lose their saved appearance preference.

Apply the Appearance at the App Root

The appearance mode should be applied as high in the view hierarchy as possible. In most apps, that means the App entry point.

import SwiftUI@mainstruct MyApp: App {    @AppStorage("appearanceMode") private var appearanceMode = AppearanceMode.system    var body: some Scene {        WindowGroup {            ContentView()                .preferredColorScheme(appearanceMode.colorScheme)        }    }}

Applying preferredColorScheme here means the choice affects the whole app, including pushed navigation destinations and presented sheets.

If you apply the modifier deeper in the hierarchy, you may end up with only part of the interface changing appearance. That can be useful for special cases, but for a user-facing app setting, the root is usually the right place.

Add a Picker to the Interface

Now you need a way for the user to change the value.

Here is a simple toolbar menu:

struct ContentView: View {    @AppStorage("appearanceMode") private var appearanceMode = AppearanceMode.system    var body: some View {        NavigationStack {            VStack {                Image(systemName: "globe")                    .imageScale(.large)                    .foregroundStyle(.tint)                Text("Hello, world!")            }            .padding()            .navigationTitle("Mode Changer")            .toolbar {                ToolbarItem(placement: .bottomBar) {                    Menu {                        Picker("Appearance", selection: $appearanceMode) {                            ForEach(AppearanceMode.allCases) { mode in                                Label(mode.title, systemImage: mode.iconName)                                    .tag(mode)                            }                        }                    } label: {                        Image(systemName: appearanceMode.iconName)                    }                }            }        }    }}

The picker writes directly to the same @AppStorage value. As soon as the selection changes, the app-level preferredColorScheme receives the new value and the interface updates.

Why Use a Menu?

A menu works well when the setting is available from a toolbar. It keeps the interface tidy while still making the choice easy to reach.

For a settings screen, you may prefer a segmented picker or a list row:

Picker("Appearance", selection: $appearanceMode) {    ForEach(AppearanceMode.allCases) { mode in        Label(mode.title, systemImage: mode.iconName)            .tag(mode)    }}

The important part is not the picker style. The important part is that every picker binds to the same stored appearanceMode value.

Make Sure Sheets and Navigation Inherit the Mode

Because the color scheme is applied at the app root, child views do not need to know anything about the appearance setting.

struct NavigationStackView: View {    var body: some View {        VStack {            Text("This view was pushed onto the navigation stack.")            Image(systemName: "star.fill")        }        .font(.largeTitle)        .padding()        .navigationTitle("Pushed View")    }}

Presented sheets also inherit the selected mode:

struct ModalSheetView: View {    @Environment(\.dismiss) private var dismiss    var body: some View {        NavigationStack {            VStack {                Text("Presented as a modal sheet.")                Image(systemName: "apple.logo")            }            .font(.largeTitle)            .padding()            .toolbar {                Button(role: .close) {                    dismiss()                }            }        }    }}

These views stay clean because appearance mode is an app-level concern, not a screen-level concern.

The Complete Pattern

The reusable pattern is:

1. Create an AppearanceMode enum.
2. Store the selected value with @AppStorage.
3. Apply preferredColorScheme at the App root.
4. Bind any picker or settings control to the same stored value.

Once those pieces are in place, you can expose the setting anywhere in your app.

Final Thoughts

Appearance mode is a small feature, but it is one of those details that makes an app feel more considerate. Some users want their apps to follow the system. Others want a specific app to stay light or dark regardless of the device setting.

With SwiftUI, supporting all three options only takes a small enum, a stored preference, and one app-wide modifier.

That is a tidy little feature with a lot of user-facing polish.

If you want to download the code for a sample project using this technique you can find on my GitHub.

ModeChanger

The site itself is not especially unusual. It has an About page, a YouTube tutorials page, an app portfolio, and a blog. But keeping those pages up to date can become surprisingly repetitive. Each new video needs a thumbnail, a title, a release date, and a link. Each app needs artwork, a description, a source, a download URL, and sometimes a separate app page. Blog entries need images and markdown content. Even simple site-wide details like the logo, header, footer, and social links need to stay consistent across every page.

So instead of continuing to hand-edit web pages, I decided to build a macOS app that could become the content management system for my own site.

The result is CTSiteBuilder, a SwiftUI app that lets me manage the website content in one place and export the whole thing as a static website.

This site you are viewing this blog on was generated with this application.

Starting With the Content

The first step was not the UI. It was understanding the shape of the website.

I listed the pages I needed:

• About
• YouTube Tutorials
• App Portfolio
• Blog

Then I broke those pages down into the actual pieces of data they needed. The About page needed a title, an about paragraph, a banner image, social links, a Ko-fi callout, and a newsletter callout. The Tutorials page needed playlist information, current video information, thumbnails, YouTube links, release dates, and a way to mark whether a video had been released. The Portfolio page needed app records grouped by source, such as App Store, Gumroad, and GitHub. The Blog page needed entries with dates, images, titles, and markdown content.

That became the foundation of the app. Rather than thinking of the site as a collection of HTML files, I treated it as structured data.

Using SQLiteData as the Backbone

For persistence I used SQLiteData. Each major part of the site has its own table-backed model: site configuration, about page, social links, tutorials page, playlists, videos, portfolio page, portfolio apps, blog page, and blog entries.

This gave the project a clean separation:

• SwiftUI is responsible for editing the content.
• SQLiteData is responsible for storing it.
• The exporter is responsible for turning it into web pages.

That separation mattered. Once the data model was in place, it became much easier to add features without rethinking the entire app. For example, adding newsletter fields to the About page or adding a released flag to videos was handled as a database migration, not a rewrite.

The app also supports CloudKit synchronization through SQLiteData, so the content can be synced through iCloud. I added a manual "Force iCloud Resynchronization" action for the point where the CloudKit schema has been deployed and I want to make sure local website records are pushed again.

Building the Editor

The main app UI uses a SwiftUI NavigationSplitView with sections for Site Settings, About Page, YouTube Tutorials, App Portfolio, Blog, and Export.

Each section is an editor for a specific part of the website. Site Settings handles shared identity: the site name, logo, live URL, test URL, header title, header subtitle, and footer copyright. The page editors handle their own page title, page name, markdown content, images, and related child records.

The child records were important. Social links, playlists, videos, portfolio apps, and blog entries all need full create, edit, and delete support. Some also need ordering, so I added sort order support and drag-to-reorder behavior where it makes sense.

Images are stored with the records as data. The app supports choosing an image through a file picker or dragging an image directly into the editor. That may sound small, but it makes the app feel much more like a tool I would actually want to use.

Markdown In, HTML Out

I wanted writing content to remain comfortable, especially for about text and blog entries. Markdown was the obvious choice.

The app lets me write longer text in markdown, then converts it to HTML during export. That means I can keep the editing experience lightweight while still producing proper web pages. Blog entries become individual detail pages, and the blog index shows excerpts with "Read More" links.

This also kept the website flexible. I can write content naturally in the app without thinking too much about the final HTML structure.

Exporting a Static Website

The export process was the major turning point.

All the site data lives in SQLite, but the final output is a static website. When I click export, CTSiteBuilder creates the HTML files, writes image assets into an images folder, creates individual blog detail pages in a blog folder, and copies the shared stylesheet.

The exported pages are generated from templates bundled with the app. There are separate templates for About, Tutorials, Portfolio, Blog, and Blog Entry pages, plus a shared CSS file.

That template approach was intentional. I did not want the design to be buried entirely in Swift code. By keeping HTML templates and CSS as export assets, I can adjust the design of the website without changing the underlying database or editor logic.

The exported site supports:

• A shared header and footer.
• Site logo and name on every page.
• Navigation generated from the page records.
• Responsive layout for mobile screens.
• Light and dark mode styling.
• Markdown-rendered content.
• Image export for logos, thumbnails, banners, blog images, and social icons.

The Tutorials page also exports an interactive video browser. Released videos are listed in reverse date order, and selecting a video displays the thumbnail, details, and an embedded player. The Portfolio page groups apps by source. The Blog page generates both the listing page and separate pages for each entry.

Deployment Workflow

Once the static site export was working, the next obvious step was deployment.

The app includes an export section where I can choose an export folder, generate the site, and then deploy it. I built in rsync support because it is a good fit for static websites: it transfers only changed files and works over SSH.

I also added dry-run support. That way I can preview what rsync would change before uploading anything. For safety, the rsync deployment avoids deleting unrelated files at the root of the remote site. It only prunes generated files inside the blog and images folders.

There is also FTP deployment support, including a remote manifest so previously generated files can be removed when they no longer exist locally. But rsync is the workflow I expect to lean on most.

What I Like About This Approach

The thing I like most is that the app is tailored to the actual website.

It is not a generic website builder. It does not try to solve every possible publishing problem. It solves my publishing problem: maintaining the CreaTECH Solutions website, keeping tutorials and apps current, writing blog posts in markdown, and exporting a clean static site when I am ready.

That made the project much more approachable. I could start with a concrete list of pages and fields, build a database around that structure, add editing screens, and then focus on generating exactly the website I needed.

It also shows why building small custom tools can be so satisfying. A lot of the time, the best app is not the most universal one. It is the one that understands your workflow.

The Feature Set Today

CTSiteBuilder now includes:

• Site-wide settings for branding, URLs, header text, and footer text.
• Editors for About, Tutorials, Portfolio, and Blog pages.
• CRUD support for social links, playlists, videos, portfolio apps, and blog entries.
• Image import through file picking and drag and drop.
• Markdown support for longer content.
• SQLiteData persistence with database migrations.
• CloudKit synchronization through SQLiteData.
• Static HTML export from bundled templates.
• Responsive CSS with light and dark mode support.
• Generated image assets and blog detail pages.
• FTP deployment support.
• Rsync deployment with dry-run mode and selective pruning.

Final Thoughts

This project started with a simple question: what would make updating my website easier?

The answer was not another admin panel or a full web CMS. It was a native Mac app built around the exact content I publish.

That is what I enjoy about this kind of project. SwiftUI gives me a fast way to build the editing experience, SQLiteData gives me a structured and syncable data layer, and a static export keeps the final website simple, fast, and easy to host.

The end result is both a tool and a workflow. I can manage the content locally, sync it through iCloud, export the finished pages, test the result, and deploy it when ready.

For me, that is the sweet spot: a custom app that removes friction from a real recurring task.

In June of 2019 I as interviewed by Sean Allen for his "Origin Stories" theme on his "iOS Dev Discussion" podcast. He felt, after reading my blog that I had a story to share so I jumped at the chance to build my network of fellow developers with the exposure the podcast would bring.

Self Taught vs Self Directed

I don't say that I am self taught. I say that I am a self directed learner because I don't believe anyone can teach themselves to be an iOS developer. We all learn from others whether that be through some kind of structured degree program or boot camp or by watching videos, reading other blog posts and asking questions on Twitter, a Facebook group or heaven forbid, Stack Overflow.

Building A Network

To be a self directed learner you have to be able to build your network of fellow developers or learners; preferably both. You learn from others who know more from you, but just as valuable is learning by sharing what you know with others who are at the same level or still catching up to you.

After Sean's interview, my network started to grow. I also decided through Patreon and GitHub to support some of the people I respect the most for sharing their content for free. Two key people for me at that time were Paul Hudson of Hacking With Swift and Mark Moeykens of Big Mountain Studio. Both offer quality content and at the time, everything they did was free. Both now offer other paid services like Paul's Hacking With Swift Plus and Mark's exceptional SwiftUI resources, which I am happy to support and pay for. You get what you pay for. I am only mentioning Sean, Paul and Mark here because they, unbeknownst to them, played a big part in my progress to become a YouTuber. There are too many to mention here and there are lots of bloggers and YouTubers who deserve credit, but that is not the point of this blog.

In the beginning...

It seems that my interview with Sean struck a chord with some people as my Twitter feed started to grow. Some people reached out to me to say that they are able to identify with my path and encouraged me to keep going. Last year, 2019, before Christmas, Paul Hudson started his 100 Days of SwiftUI. I had been learning SwiftUI from the start but was lacking a structured learning path so I started right at Day 1, committed to work through it to the end. I tweeted about my progress as did many others. One of my followers reached out to me who too was working through the course and had some questions and wondered if I could help him out. His name is Chris and we developed a bit of a rapport. I had more experience than he had and I found that I was able to offer him some suggestions. I have been at this a long time and made a lot of mistakes along the way. I have a background in education and so I know a thing or two about learning and teaching. The one thing I pride myself in is making sure that I do my homework. I want to make sure that the information that I am offering is accurate, structured, applicable and easy to understand.

I hesitate to say it, but I believe that I was a mentor to Chris, It made me feel good. But more than that, it made me analyze how I did things and I realized that in the past, I was not always adhering to best practice.

In my previous company, I was responsible for creating short product videos for YouTube that would show our users how to take advantage of certain features of the product. I created over 100 different videos for that channel so I had some experience with YouTube. That company's product also had a tool that allowed our customers to use a proprietary language based on BASIC to create additional tools that could be used to enhance the functionality of the product. I developed courses to teach those clients how to code those tools. I traveled across North America and parts of Europe teaching 3 day courses on the topic. Later on, the product evolved to a web based tool with an API so I transformed my focus into building web based tools. I continued, after leaving the company to consult and teach coding classes related to that product. Well, the product is basically grandfathered now and the consulting and demand for my services dried up. In my retirement, I needed something to keep my brain active and I realized that my self worth relied a lot on the positive feedback I was getting from my teaching. So, on Jan 12, 2020, I revised my only personal YouTube channel to start focusing on tutorials about coding in Swift.

My YouTube Channel

I wanted to focus on Swift and SwiftUI Fundamentals. In one of my earlier posts, I categorized the videos as being based on a line from an old song by Rod Stewart and the Faces. "I wish I knew what I know now, when I was younger." If only I knew what I know now about clean code when I first started out, then I would be a better coder now. I look at some of my old projects now and the code is atrocious. If I wanted to implement something I would watch a video, read a few blog posts and copy and paste someone else's code and tweak it until I got the results I wanted. Needless to say, there is no common architecture between apps and even within a single app there might be several different ones.

What I found was that when I was preparing for a video, I had to do a lot of research and make sure that what I wanted to cover followed best practices. This, more than anything has made me a much better developer. There is nothing better than to put yourself out there for the world to see and to comment or criticize on. It seems to work. With over 75 videos on my channel now, I have not yet had a negative review and the feedback has been really encouraging.

My channel is not really for beginners, nor it is for experienced developers though I think there is something there for those categories too. My focus is on people like me. People who have left the starting gate in their coding experience but constantly need reinforcement and review to stay on top of things and improve their skills in their quest to land a software development position.

My channel videos are focussed around 4 different themes. Focussed Playlists, Swift/SwiftUI Fundamentals, Techniques and Developer Tools.

I am guided by the following principals:

• Research carefully the topic I am about to present.
• Don't ramble — stay on topic.
• Provide practical examples.
• Only publish quality videos that I am proud of.
• Always credit other developers if I borrow and share something that they have published.
• Publish at least one video a week every Sunday

You will never see my face on a video. I don't think there is any need for a talking head in a YouTube video about coding. You may have a different opinion, but the focus is on the code, not me. Besides, I am afraid that if some of my younger audience actually saw how old I am they would be turned off and dismissive. There is definitely a prejudice with respect to the older generation and a failure to recognize that we have something to offer after all.

The process

With those principals in mind, this is how I go about creating my videos.

I start each new video idea by mulling the topic over in my mind and thinking about the best way to present the topic. I use Raindrop.io to gather resources. I often am thinking about many ideas at the same time. There is no fixed amount of time allocated to this task.<br>Once I have decide what the topic is for this week, I try to come up with a sample project or playground that I can work through during the video recording. This will go through many iterations until I am satisfied. Next, I loosely script out the step by step process for creating the project so that I can follow it when recording. Once the script is complete, I use Camtasia to record myself without audio. When the recording is complete, I create a Keynote presentation that I can use as an introduction and export it as a .mov and import it in as the beginning of the video. I then go through the video, editing out any false moves and corrections. The next step is to actually script the entire video, word for word. That's correct. I watch my own videos and write a transcript. When that is done, I use Audacity to record my voice over. I then edit the audio file by removing mistakes, unwanted noises and I normalize the volume. When I am satisfied, I export it as an MP3 and import it in to Camtasia. This is where the fun begins. I have to match the audio with the video. Sometimes I have to extend a frame and on other occasions I have to speed up the video. I seldom edit the audio once I have imported it. I know enough about how I recorded the video that I know when to pause and slow down during the recording of my voice over script. The final video production stage is to add annotations, call outs and zoom and transition effects so that it is clear what I am talking about and what I want the viewer to focus on. The final step is to upload to YouTube and set a date that I want to release it. When it comes to the release date, I post on Twitter, a number of iOS related YouTube groups, Reddit and LinkedIn and update my web site to point to the video. As you can see it is a lengthy, well thought out process and that is why I limit myself to one a week. It is not unusual for it to take 3 days to produce a 20 - 30 minute video. There are some downsides to this of course. My style is not for everyone. I have not had anyone tell me that the content is invalid, but I have had some comments about the lack of spontaneity and enthusiasm in my presentation style.

How Am I Doing?

I posted my first video on Jan 12, 2020 on creating and using a Swift Package with Swift Package Manager. The feedback I was positive and encouraging but not many viewers. Still, I hung in there. By May, I had reached 500 subscribers. By July I hit 1000 and by November I was at 2000 subscribers. I am averaging somewhere between 200 - 250 new subscribers a month now. Today, as I write this blog I have reached the YouTube threshold of a minimum 4000 watch hours over a 12 month period that entitles me to add ads to my videos. I am still undecided here in that regard. It would be nice to make some revenue after all, but I don't believe I have the numbers to really make anything worthwhile.

I am aways surprised by what content gets the most feedback. Some topics I am really excited about turn out to be not very interesting to others. One video though that really took off was one where I took a concept that I saw Paul Hudson do on his HWS+ feed that converts an SVG to a UIBezier Path in SwiftUI and animates it. I extended that thought in a video. Another time, Mark Moeykens mentioned my name and channel in one of his videos and that resulted in a number of new subscribers. Now it is mostly word of mouth and the fact that I now have over 70 videos in the channel and that they are more discoverable in a Google search.

I once put out a survey asking what kind of videos people wanted to see based on my categories of Fundamentals, Techniques and software development tools. The lowest was for videos on software development tools, yet by far the two most viewed videos I have the ones about Raidrop.io and Typora. I guess I appeal to more than one segment of the YouTube population.

Anyway, that is where I am today. Can I call myself a YouTuber? I think probably yes, but I am still looking to increase my viewing audience as I believe that there are many people who would benefit from what I have to offer. You can find my channel at https://youTube.com/StewartLynchand feel free to reach out to me on Twitter @StewartLynch. You can also visit my web site at https://www.createchsol.com to find out about my apps and other things about me. I would love to hear from you and get your feedback on how I am doing.

I ended up becoming a Math teacher and in 1980, an Apple II+ was introduced to my classroom. I started coding in BASIC, writing all sorts of little utilities that would help me explain concepts and give students a chance to build and review their skills. Still, I wasn't a 'software developer'. By 1986, computers were all throughout the school district but most teachers had no real idea what to do with them. I was seconded from the classroom to work with teachers and students to integrate the use of computers into the classroom. That ended my teaching career. For the next 20 years (with the exception of 3 years in hell as a High School Vice Principal), I worked my way up the chain in two different school districts, leaving in 2007 as the Director of Technology, responsible for IT in both the education and corporate sectors of one of the larger school districts in the Vancouver area.

During my career as an IT director, we purchased a very efficient and extremely flexible email/collaboration system that governed the way we communicated and shared information in our District. The software was flexible and customizable and allowed for the development of add-on tools that could enhance and extend the functionality of the product. I was in heaven. I got to develop all sorts of tools that allowed me to streamline the system administration and communicate with district SQL databases to give secure, real-time access to district data sources. Programming was a break from the endless, tedious meetings and I became quite competent. The district started marketing the tools I created and made a substantial profit from sales.

I began to establish a relationship with the software company and got certified as a trainer so I could share my skills with others all over the US and Canada. This brought in more money for the District. I became a very vocal supporter and evangelist of sorts for the software and eventually, they made me an offer that I couldn't refuse.

Not retiring, recareering!<br>I took the early retirement and went to work for this software company. But….. not as a 'software developer'. I was a "Senior Services Engineer". I did a fair amount of training, but also was able to continue developing tools as value-added products for our customers. Still…. it was made very clear to me that I was not a 'software developer'. I was a hacker. I was undisciplined and could never contribute to the core product. I was basically self taught and had a lot of very bad habits. If any of the real developers looked at my code, that would be very evident. Well, as often happens in the private sector, the division downsized and I was forced into another retirement.

A new beginning<br>Now what was I do do? This was 2014. What else happened in 2014? Swift, the new programming languge for iOS development was released. This fuelled my passion and set me in a new direction that consumes me to this day.

Like a lot of people, I started taking Udemy courses on how to develop apps for the iPhone using Swift. This got me started and I was able to launch my first app to the app store shortly afterwards, but in hindsight, I am not conviced that this was the best way to go.

A false start<br>The instructors advertised taking you from nowhere to being a full fledged iOS developer. Sure, I was able to create and publish an app on the App Store, but could I really call myself a software developer? These courses showed you how to create and utilize a lot of the APIs but lacked explanations. They did not follow best practice nor use recognized design patterns. My method for developing apps was basically copying code from someone else and substituting in my own values to fit my needs. I asked a lot of questions on Stack Overflow and accepted the abuse for asking questions that had already been answered. I lacked the ability to even frame a question correctly it seems. There was very little understanding of what I was actually doing. It worked, but when I had to go back to those apps a couple of years later to update and enhance, I had a really difficult time understanding and replicating what I did. There was a lot of redundant code and work arounds to get things working.

There is no easy route to being a software developer<br>That is when I decided that I needed to be more methodical in my learning and go back to square one. I wasn't able to attend any boot camps so I decided to invest my money in purchasing highly recommended resources that could teach me the right way to code and to be able to develop software that could stand the test of time. This also meant dedicating a lot of time reading, following tutorials and practising what I learned.

An ongoing adventure<br>My adventure continues. I have just published my 9th iPhone app. Three of these apps have Apple Watch companion applications. I learned how to use Swift to develop Mac apps and one of my iPhone apps has a Mac version on the Mac app store, I also studied Kotlin and recreated my first iPhone app as an Android app and published it on the Google Play Store.

Recommended Resources<br>So who did I rely on to reroute my learning? There are lots of good resources out there, but there are several that I would like to acknowledge as giving me ongoing inspiration and encouragement.

Ray Wendrerlich (https://www.raywenderlich.com/, @rwenderlich)<br>The resources and instructors available at raywenderlich.com are outstanding. I have purchased just about every book they have published and am an annual video subscriber. I look forward each week to see what new tutorials are published. I started with the Swift and iOS Apprentice books which provided me with a solid grounding in best practices.

Hacking with Swift (https://www.hackingwithswift.com/, @twoStraws)<br>Paul Hudson is a machine. Every one of his publications is so well laid out and presented, that I have to discipline myself to continue through to the end of each publication for fear of missing some key point. Again, I have purchased almost all of his books and it is just a matter of time before I purchase the remaining ones. He is a Swift Conference rock star and his presentation style is without compare.

YouTubers<br>There are a lot of YouTube series available as well that deserve mention. More than I have space for. There are three in particular that I would like to point out.

Mark Moeykens - Big Mountain Studio @bigmtnstudio<br>Mark has a special way of presenting material and is inspiring. He has a sense of design that appeals to me and if you look at my more recent apps you will definitely see his influence. I have appreciated his contributions so much that I have become a patron of his on Patreon.

Sean Allen - @seanallen_dev<br>Sean is another inspiring developer. He went from no programming experience to a full time developer in a very short period of time after enrolling in a developer Boot Camp. He shares his experience on his YouTube Channel and his weekly news updates on everything Swift. He has combined with Paul Hudson to present the Swift Over Coffee podcast. Sean is a breath of fresh air. He is not judgemental and always willing to offer assistance.

Code With Chris - @CodeWithChris<br>Chris is a long time YouTuber with an excellent set of YouTube videos. He also has a great FaceBook page where people can ask and answer questions. Perfect for the developer who is just starting out.

Twitter<br>Twitter is how I start my day. I have created my own twitter list of 70 individuals who live and breath iOS/Swift development. Every day the latest news and resources are highlighted and referenced in tweets. It is a fantastic resource. In addition to the above twitter accounts that I have already referenced, there are many more worth following. Here are just a few of the best: @swiftbysundell, @hanning_thomas, @DigitalLeaves, @objcio, @NatashaTheRobot, @johnsundell, @abargh, @ayabibagib, @mennenia, @davedelong, @harlanhaskinsm @subdigital, @erucasadun, @bendodson

Newsletters<br>I subscribe to several newsletters that publish weekly Swift updates and links to resources. Here at just a few of them

IOS Dev Weekly<br>Indie iOS Focus Weekly<br>Swift Developments<br>Use Your Loaf<br>Swift Weekly<br>iOS Dev Nuggets<br>So. Am I a Software Developer?<br>The question I guess is still open. Does it really matter? I am 6X years old and still going strong. I have no desire to get a job as a software developer. My age is against me, though I think that I am as qualified now as a lot of junior developers. I don't need a job. I just need something to keep my brain working and provide me with a little extra income to pay for my vacations. Don't count us old folks out, but also don't for a minute think that just because we are senior citizens we don't have something to contribute.

I don't go to conferences or meetups because I have experienced age discrimination in the past and don't need the aggravation. I communicate with a lot of people via email or online chats. When my age is unknown, what I have to offer is given more attention and my questions are more likely to be considered.

Still, I feel incredibly blessed to be able to come up with an idea and create a tool that can be useful to me and others. It is a great community to be in. Maybe one day I will be a software developer.