It worked really well. The two models catch different things. Claude is better at synthesis and communication. Codex reads more carefully — it traces code paths, checks edge cases, doesn’t declare done too early. They investigate independently, and that’s what makes the results better.

But the relay was miserable.

Links got stripped, formatting degraded, but those weren’t the real problem. The real problem was that every handoff still depended on me. Copy the output, paste it into the other session, wait, copy back, paste again. My attention stayed trapped inside the loop when it could’ve been somewhere more useful. That was the actual pain — a workflow that wouldn’t move without me.

I didn’t want to change the workflow itself. I just wanted to stop being the human message bus.

The Harness Article That Confirmed Everything

Then I came across Anthropic’s Harness design for long-running application development, mentioned in a YouTube video. I read the whole thing and it did two things at once.

First, it confirmed what I’d already been experiencing: having a separate session verify work independently — without the anchoring bias of having built it — produces better results. That was exactly what I’d been seeing with Claude and Codex.

Second, it turned that experience into a clearer system. I’d been focused mostly on the “different model” part. The article made the “separate evaluator” part much more explicit. Even another Claude session helps if it’s independent enough. The separation itself is load-bearing.

And honestly, it makes sense: if the original session thought the code was wrong, it wouldn’t have written it that way. It’s the same benefit pair programming has always had — a second pair of eyes catches what the author’s brain filters out. These LLMs aren’t that different from us here.

That combination — confirmed by experience, then clarified by research — was the moment it clicked. This wasn’t just some personal quirk in how I like to work. It seemed generally useful. So I turned the workflow into a proper plugin and called it TandemKit.

The Coordination Problem That Actually Needed Solving

My first design had four top-level sessions: Planner, Generator, and two Evaluators — one Claude, one Codex. They coordinated through plain text files. When one session was done, it would write a sync file, and the other would wait in the background until that file changed. It worked perfectly in Claude. But Codex just wouldn’t wait reliably. No matter what I tried — different file-watching approaches, different signaling mechanisms — Codex would either miss that it was its turn or skip the wait entirely.

I was on my fifth or sixth workaround for this when I discovered that OpenAI had just released an official Codex plugin for Claude Code — codex-plugin-cc. Claude could now invoke Codex internally, see its response, and resume the same Codex session later. Exactly what I needed.

That didn’t make the Claude-Codex exchange invisible. Everything is still written to markdown files under TandemKit/, one file per round. The full mission history stays on disk — every investigation, every convergence exchange, every evaluation verdict.

That archive is useful, too. When something weird surfaces weeks later, git history doesn’t just give you a commit message — it gives you the whole conversation behind the commit, so you can actually dig into why a decision was made. It’s also great for improving the workflow itself: reading old missions is often the fastest way to notice that a rule belongs in AGENTS.md or a local skill.

What changed was the plumbing. Instead of juggling a fragile fourth terminal, TandemKit now calls one persistent Codex subagent on demand through codex-plugin-cc and resumes it whenever it needs another independent pass.

What a Mission Actually Is

I’ve been using AI agents every day for close to a year now, and a mission is the size of work I keep landing on: big enough to benefit from separate planning, generation, and evaluation, but small enough that the whole thing can still be implemented and fully verified within one set of sessions.

If the work is smaller than that — a quick one-file fix, a tiny refactor, a straightforward rename — I just use Claude Code directly. TandemKit’s multi-session loop uses more tokens and more ceremony than that kind of change deserves.

If the work is larger than that, I split it before starting. That’s where PlanKit fits in naturally: it takes ideas through Ideas → Roadmap → Features → Missions. By the time something reaches “mission,” it’s not a vague feature bucket anymore — it’s already shaped into a session-sized piece of work.

A Recent Mission in Practice

I wanted to add App Store Connect localization support to TranslateKit, my AI-powered app localization tool. The idea was simple: instead of manually managing app metadata in App Store Connect, developers could edit names, subtitles, descriptions, and keywords for all their localizations directly inside TranslateKit — synced via Apple’s API.

That was too big for one mission. So I split it in two: one mission for the App Store Connect API connection — JWT authentication, credential handling, fetching metadata, updating metadata — and one mission for the UI changes needed to surface all of that in the app. Data layer first, UX layer second.

During planning, Claude and Codex surfaced edge cases I hadn’t thought through. For example: what happens if the user wants to add a new language, but there’s no new App Store Connect version yet? Already-released versions can’t be edited, so the system has to decide — cache the changes locally, prompt the user to create a version first, or offer to auto-create one across platforms.

And if TandemKit creates a new version, what number should it use? Look at the history and guess? Ask the user to type one in? Offer common next-version options to pick from? Those are product decisions, not implementation details, and they belong in the spec before any code exists.

During evaluation of the API mission, Claude initially marked the feature as passing because the happy path worked and the existing-version tests were green. Codex traced the less obvious branch and found the real gap: when no editable App Store Connect version existed yet, the code created the new version record but never retried the localization write in the same flow. So the “new language” path looked successful while silently doing nothing until the user ran sync again — exactly the kind of code-path bug a second model catches.

The fix was small: retry the write after version creation, add tests for that branch. But without the second pass, it would’ve slipped through.

Three Sessions, Autonomous Loop

YOU  -- planning
  |
  `--> [1] Planner Session
             Claude ---------> Codex (background)
              |    <- findings - |
              `---- converge ----'
                         |
                      Spec.md  <-- you approve before continuing

YOU  -- start both sessions, then step away
  |
  |--> [2] Generator Session
  |          implements against Spec.md
  |          commits at milestones
  |
  `--> [3] Evaluator Session
             Claude ---------> Codex (background)
              |    <- findings - |
              `---- converge ----'
                         |
                 FAIL -> Generator fixes -> loop
                 PASS -> Review Briefing -> you

The Planner is the only interactive step. Once you approve Spec.md, the Generator and Evaluator run on their own until you get either a FAIL to fix or a PASS with a review briefing.

How Claude and Codex Actually Agree

The obvious move here is scoring: both models rate the work, average the scores, pass if it’s above some threshold. But scores hide failures. An 8/10 can still mean two critical criteria completely failed and everything else was fine.

So TandemKit evaluates criterion by criterion. Each finding gets two dimensions attached to it:

• Agreement level: agreed, partially agreed, or disputed

• Severity level: HIGH, MEDIUM, or LOW

Claude and Codex investigate independently and write their findings to files. Then Claude reads what Codex found, creates a merged evaluation — keeping what it agrees with, explaining where it differs — and Codex reviews that merge. Any disagreement means re-reading the actual source files, not arguing from memory.

The convergence rule is simple: the loop continues until no HIGH or MEDIUM findings remain in the partially agreed or disputed buckets. If the same disagreement survives three rounds, TandemKit stops iterating and presents both positions to you.

Usually 2-4 rounds.

Why Not Agent Teams

You might wonder: doesn’t Claude Code have Agent Teams for exactly this? It does, but Agent Teams requires API billing — not included in Claude Max — and can’t integrate with Codex.

If Claude Max already costs you $100+/month, adding $20/month for ChatGPT Plus is a reasonable add — you get an independent second model, plus image generation for UI mockups, icons, and other visuals Claude doesn’t produce.

Everything Is Plain Text

Every investigation, every convergence exchange, every evaluation round is stored as readable files in your project:

TandemKit/001-ConnectAPIClient/
├── Spec.md
├── Planner-Discussion/
│   ├── Claude-01.md    ← Claude's investigation
│   ├── Codex-01.md     ← Codex's independent findings
│   └── Claude-02.md    ← converged plan
├── Generator/
│   └── Round-01.md
└── Evaluator/
    ├── Round-01.md     ← FAIL: version created, localization write not retried
    └── Round-02.md     ← PASS

Open the files and you can trace the full reasoning trail.

Getting Started

The README on GitHub has the full setup flow and shows how the sessions hand off to each other. If this sounds like the workflow you’ve been stitching together by hand, that’s the place to start:

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

This distinction matters enormously in production.

The Math That Surprised Me

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

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

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

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

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

The Symptoms

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

How to Calculate the Right Value

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

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

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

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

And I’m genuinely glad Apple pivoted to server-based LLMs instead of going local-only. Having seen by now how amazing Claude Code can be with the right context engineering, I know a local-only solution would have taken years to reach usable quality. Apple made the right call here to pivot from the original Swift Assist idea, but they clearly didn’t have time to build a complete solution for the initial release. As someone loyal to the Apple ecosystem for development, it’s frustrating to see such obvious gaps in what could be an incredible tool. So for the first time in my 14 years developer career, I’m no longer using Xcode as my daily driver.

Claude Code in Cursor summarizes what context it has thanks to Context Engineering.

I ended up running Claude Code in Cursor’s terminal instead – getting Cursor’s editor awareness with Claude Code’s superior tools like web search, planning mode, and the generous 5-hour usage window. I’ve been fully embracing the chat interface and trying to teach AI to understand how to write good code through extended context engineering (guidelines, reference documentation). Meanwhile, Xcode’s AI integration – while promising due to its native IDE position – lacks fundamental features that make this kind of AI-driven development productive.

Here’s what’s keeping me from making the switch back to Xcode.

The 7 Missing Features in Xcode AI

1. Request queuing was the first limitation I noticed in Xcode right away. When I’m developing, thoughts and questions come fast. Having to wait for each response breaks my rhythm completely. Thinking ahead while waiting is one of the biggest time savers when working with AI. Both Cursor and Claude Code let me queue requests seamlessly, keeping me in the flow. Xcode just blocks all input.

Xcode 26 blocks new chat input while processing the previous one.

2. Context engineering support is where Xcode completely falls short. There’s no support for context files like .cursorrules or CLAUDE.md. Without automatic context loading, all the work I’ve done on context engineering – teaching the AI my coding standards, architectural patterns, error handling approaches, and more – simply isn’t possible in Xcode. I have to repeatedly explain my guidelines in every conversation. Claude Code and Cursor both automatically load my lead guideline, then understanding when to read which more detailed guideline. This transforms AI from a generic code generator into an actually useful assistant. Not in Xcode.

The Coding Assistant telling me it has no way to teach it about my project or guidelines.

3. Build validation shows Xcode wasn’t designed for AI-driven development. The AI can’t validate its own code changes by running builds or even access build output when I run them. It can’t even read console logs when I explicitly ask it to. Sure, Xcode lets you select an error after building and ask the AI to fix it – but that’s designed for a different workflow. It’s only useful when you manually write code and make a mistake, which rarely happens. But when AI writes code for me? Build errors occur constantly. Having to build myself and then manually press to fix it is super annoying. The AI should just be able to build and look at the errors itself. With Claude Code, I simply let it run xcodebuild and the AI sees all errors immediately. It does ask me for permission, but when granted, it can iterate, fix, and rebuild until everything compiles – no manual intervention needed.

The Coding Assistant telling me it can’t read the console output.

4. Git integration is completely absent – no history searching, no comparing versions, no automated commits following my guidelines. I can’t tell it to compare my current code with a previous version to update documentation files based on recent changes, or bring back some working code from previous commits. Claude Code can search my git history, bring back working code from previous commits, and create properly formatted commits by analyzing the actual changes and finding a good message that follows my commit guidelines. It can even help update documentation by comparing what changed since the last version.

The Coding Assistant telling me it can’t access git history.

5. Terminal and CLI access is the biggest gap. No command line access means no swift-format, no custom scripts, no automation. As an indie developer juggling multiple responsibilities, this is a serious limitation. I can’t teach it to run a code formatter before I make a commit, can’t have it execute my test suites, can’t run any of the custom scripts that streamline my development process. Claude Code runs any terminal command I need. It formats code before commits, runs my test suites, executes deployment scripts, manages dependencies, and handles my entire automation workflow. One terminal tool gives access to everything – git, xcodebuild, package managers, you name it. Modern AI is good in this!

❇️ If Apple just added terminal access alone, above points 3 and 4 would be resolved as well! Of course giving full command line access is risky. But Claude Code solves this nicely by asking for permission the first time and supporting an allow & deny list in a simple config file.

6. Project file limitations show how Xcode wasn’t designed for modern AI context engineering workflows. Many projects span multiple repositories – like TranslateKit with its app, server, and open source package components. My context engineering guidelines live in the parent folder containing no Xcode project, yet I need AI access to them across all components. When I drag a folder to Xcode to open it in the editor, I just get an error. It can only open single text files, Xcode projects, or Swift Package manifest files – but not arbitrary folders. It also hides dotfiles, so I can’t see or edit things like GitHub Actions workflows. Cursor on the other hand opens any folder, shows hidden files, and works across my entire multi-repo development environment. Xcode should support this, too!

The error dialog when I try to open an arbitrary folder in Xcode.

7. Web search and documentation access are also missing entirely. The AI can’t even search within Xcode’s own downloaded documentation files. When I need current information or API references, I’m on my own. Claude Code has built-in web search. When I ask about the latest Swift evolution proposals or new APIs introduced at WWDC25, it just finds the answer. Not in Xcode 26.

Asked about the new frameworks introduced by Apple in 2025, it 100% hallucinates.

These seven limitations add up to a fundamental problem: Xcode’s AI feels like a tech demo rather than a productivity tool. Each missing piece forces me back to manual workflows that Claude Code handles seamlessly.

My Roadmap for Apple: 5 Release Milestones

Here’s how Apple could address these gaps and bring me back to Xcode in 2026:

Xcode 26.1 (October 2025): Adds request queuing and context file support (e.g. Xcode.md). These features should be easy to implement and have no risk of unnecessary side effects.

Xcode 26.2 (December 2025): Specific tool integrations for git, xcodebuild, and swift-format. Since these are all built-in to Xcode or Apple technologies, I can see Apple engineers use their existing experience to provide these tools to AI with safe conservative actions.

Xcode 26.3 (March 2026): Web search, latest documentation integration, and opening arbitrary folders with hidden file access. These integrations are all low-risk, but take time to get right.

Xcode 26.4 (May 2026): Full terminal access with command-specific allow/deny lists.

I understand Apple’s security concerns, but developers can handle the responsibility. Trust us with the tools we need, Apple, please!

Xcode 27 (September 2026, announced at WWDC 26): Features “only Apple can do”, such as deep Simulator integration (imagine AI navigating your app to test if its changes worked as expected), or SwiftUI preview access (so AI can see what it’s UI code looks like). Maybe even an “app builder” mode that makes SwiftUI a secondary artifact, bringing app development to a whole new audience. This is where Apple could surprise us with something we didn’t see coming. Not just “catching up” but truly surpassing the competition.

The Bottom Line

I’ve always loved Xcode and genuinely want to use it exclusively again. Apple has unique advantages no competitor can match – seamless IDE integration, Simulator control, SwiftUI preview capabilities. But right now, Claude Code is dramatically more capable with a 5x productivity difference. Tasks that take hours in Xcode happen in minutes with Claude Code, mainly because it doesn’t depend on me for simple tasks like pressing “build”.

Apple needs to move fast. Every day that passes, more developers are establishing deep workflows with other tools. I’ll be watching each point release eagerly, and the moment Xcode’s AI becomes competitive, I’ll be first in line to return. Until then, I’ll keep Claude Code open in my terminal, dreaming of the day when Xcode will truly blow my mind again and make the shift to becoming an AI-first IDE.

What’s your experience with Xcode’s AI integration? Have you found workarounds for these limitations, or are you also using alternatives?

1. Foundation Models: On-Device AI

The biggest game-changer this year is Foundation Models – Apple’s on-device AI framework that brings powerful 3-billion parameter models directly to your apps. What makes this special?

• Privacy-first: Everything runs on-device with no server delays

• Structured output: Use the @Generable macro to guarantee typed responses

• Tool calling: AI can interact with your app’s functions automatically

• Partial results: Update your UI as responses generate in real-time

Related Sessions

• Meet the Foundation Models framework

• Deep dive into the Foundation Models framework

• Explore prompt design & safety for on-device foundation models

• Bring on-device AI to your app using Foundation Models

2. Xcode Gets ChatGPT Integration

Apple surprised everyone by integrating ChatGPT directly into Xcode instead of their promised Swift Assist. This brings:

• Native AI assistance with code generation and documentation

• Support for multiple AI providers (ChatGPT, Claude, local models)

• Git-like history for AI changes to revert changes easily

• Context-aware code suggestions (like document, explain, etc.)

The #Playground macro also transforms debugging – create SwiftUI preview-style playgrounds for any data type, not just views. Great for prompt engineering!

Related Sessions

• What’s new in Xcode

• Optimize SwiftUI performance with Instruments

• Record, replay, and review: UI automation with Xcode

3. SwiftUI WebView Finally Arrives

After years of requests, WebView is now native in SwiftUI:

WebView(url: URL(string: "https://swift.org")!)

Combined with the new WebPage type for advanced control, including JavaScript execution and scroll synchronization. This opens up hybrid app experiences that were previously complex to implement – and required UIKit/AppKit bridging.

Related Sessions

• Meet WebKit for SwiftUI

• What’s new in SwiftUI

• What’s new in Safari and WebKit

• What’s new for the spatial web

4. AlarmKit: Third-Party Alarm Apps

AlarmKit breaks through focus modes and system restrictions, enabling:

• True alarm apps that can wake users

• Live Activities integration (required) for snooze functionality

• Custom alarm sounds and experiences possible

• Perfect for timers, wake up alarms, and prayer/medication reminder apps

Related Session

• Wake up to the AlarmKit API

5. App Store Connect Analytics Overhaul

App Store Connect gets a major upgrade:

• Monthly Recurring Revenue (MRR) finally available

• New Analytics APIs for third-party tools

• Offer codes for non-subscription products (on all platforms)

• Improved navigation with analytics moved into individual apps

Related Sessions

• What’s new in App Store Connect

• Optimize your monetization with App Analytics

• What’s new in StoreKit and In-App Purchase

• Automate your development process with the Connect API

6. visionOS Spatial Revolution

Major visionOS improvements include:

• Persistence: Widgets, windows, and volumes stay pinned between sessions

• Nearby sharing: Multi-user shared experiences in the same room

• APMP support: 180°, 360°, and Wide FOV spatial video support

• Enhanced SwiftUI 3D layout tools making development easier

• Swift Charts 3D: Bring dimensional data visualization to spatial apps

Related Sessions

• What’s new in widgets

• What’s new in visionOS 26

• Explore video experiences for visionOS

• Bring Swift Charts to the third dimension

7. Swift 6 Concurrency Made Approachable

Approachable concurrency solves Swift 6 adoption issues:

• Default @MainActor isolation reduces warnings

• Gradual opt-in to concurrency with @concurrent

• Finally makes Swift 6 migration realistic for existing app projects

Related Sessions

• What’s new in Swift

• Embracing Swift concurrency

• Elevate an app with Swift concurrency

8. Wi-Fi Aware: Beyond Bluetooth

Wi-Fi Aware enables experiences like AirPlay/AirDrop:

• High-performance local communication

• Greater range than Bluetooth, cross-platform standard

• Support for more simultaneous connections (AirPods-like)

• Perfect for media streaming and multiplayer experiences

Related Session

• Supercharge device connectivity with Wi-Fi Aware

9. String Catalog Enhancements

Localization gets more accurate & more flexible:

• AI-generated comments for translation context

• String symbols with auto-completion (for manual strings)

• Multi-select operations for bulk updates (including new refactor)

Related Sessions

• Explore localization with Xcode

10. Icon Composer & Layered Icons

The new Icon Composer app creates:

• Layered icons with up to 4 layers with built-in effects

• Preview all icon styles (including controversial “clear” style)

• Unified .icon file format to drop to Xcode

• Can also export flat images for marketing purposes

Related Sessions

• Create icons with Icon Composer

• Say hello to the new look of app icons

• Meet Liquid Glass

• Get to know the new design system

Watch the Full Breakdown

This article covers only a small fraction of new APIs, but there’s so much more to explore in my comprehensive video breakdown. I go through everything new that’s interesting and share my perspective on what will matter most for your apps:

What are you most excited to implement in your apps? Let me know in the comments on YouTube or on other socials (links below)!

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

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

Tips for Writing Effective Feedback

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

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

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

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

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

Make It a Habit

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

In this post, I’ll share the foundation I’ve built for enhanced error descriptions and invite you to join me in creating a comprehensive dictionary of user-friendly error messages for Swift developers.

The Problem with System Error Messages

Let’s look at some real examples of unhelpful system error messages:

// File system error
"The file couldn't be opened because it doesn't exist."
// Better message: "The file 'report.pdf' could not be found. Please verify the file name and location."

// Core Data error
"The operation couldn't be completed. (Cocoa error 133000.)"
// Better message: "The database has a validation error. One or more required fields are empty or have invalid values."

These default messages have several problems:

1. They’re often too technical for end users

2. They lack context about what was being attempted

3. They rarely offer suggestions for how to resolve the issue

4. They’re sometimes just plain wrong or misleading

5. They may expose implementation details that users shouldn’t see

Apple has thousands of error codes across dozens of frameworks, and many of these have existed for decades. While they’ve improved newer APIs, many older frameworks still return messages designed for developers, not users.

The Solution: Community-Curated Error Mappings

ErrorKit provides a function called userFriendlyMessage(for:) that maps system errors to more helpful messages:

do {
    let data = try Data(contentsOf: url)
    // Process data...
} catch {
    // Instead of showing the default message
    // showAlert(error.localizedDescription)

    // Show an enhanced message
    showAlert(ErrorKit.userFriendlyMessage(for: error))
}

Behind the scenes, this function analyzes the error and returns a better description based on a growing set of known error types:

// Example from ErrorKit's implementation
enum FoundationErrorMapper: ErrorMapper {
    static func userFriendlyMessage(for error: Error) -> String? {
        let nsError = error as NSError

        // URL loading errors
        if nsError.domain == NSURLErrorDomain {
            switch nsError.code {
            case NSURLErrorNotConnectedToInternet:
                return String(localized: "You are not connected to the Internet. Please check your connection.")
            case NSURLErrorTimedOut:
                return String(localized: "The request timed out. Please try again later.")
            // Many more cases...
            }
        }

        // File system errors
        if nsError.domain == NSCocoaErrorDomain {
            switch nsError.code {
            case NSFileNoSuchFileError:
                return String(localized: "The file could not be found.")
            // Many more cases...
            }
        }

        // More domains and error codes...

        return nil // Fall back to default handling
    }
}

Current Coverage and Examples

ErrorKit includes mappings for common errors across key Apple frameworks:

Foundation

• Network: NSURLErrorNotConnectedToInternet → “Your device isn’t connected to the internet. Please check your connection and try again.”

• File System: NSFileNoSuchFileError → “The file ‘report.pdf’ could not be found. Please verify the file name and location.”

Core Data

• Validation: NSValidationErrorMinimum → “The database failed validation. Please check your inputs and try again.”

• Store Management: NSPersistentStoreCoordinatorError → “Database error. This might be due to a recent app update or file corruption.”

MapKit

• Directions: MKErrorDirectionsNotFound → “No directions found for the requested route.”

• Location: MKErrorLocationUnknown → “Current location unavailable. Please check location permissions.”

Why We Need a Community Response

In an ideal world, Apple would fix all its confusing error messages. And to be fair, they’ve improved things—newer frameworks like SwiftUI are much clearer. But decades of legacy APIs still return cryptic, technical messages that may never be touched again.

This is where our community can make a real impact. No single developer has seen every obscure error—but together, we’ve seen most of them. By sharing what we’ve already figured out and rewriting these messages in plain language, we can create a resource that saves everyone time and improves the experience for developers and users alike.

How You Can Contribute

If you’ve rewritten a system error message to make it more helpful, you’re already doing the work—now you can share it. Here are the 3 general steps:

1. Spot a bad message
   Note the error domain and code, the operation that triggered it, and any useful info from the userInfo dictionary.

2. Write a better version
   Use plain language. Be specific. Offer a helpful next step when it makes sense.

3. Submit it on GitHub
   Open a pull request or issue on the ErrorKit repo with your improved message, the original context, and any notes.

Even small contributions can help thousands of developers and improve the user experience for millions!

Beyond Apple Frameworks: Mapping Any Library’s Errors

While Apple frameworks are the primary focus, ErrorKit’s error mapping system works with any error type. The ErrorMapper protocol allows developers to create custom mappings for third-party libraries:

// Example mapper for Alamofire networking errors
enum AlamofireErrorMapper: ErrorMapper {
    static func userFriendlyMessage(for error: Error) -> String? {
        switch error {
        case let afError as Alamofire.AFError:
            switch afError {
            case .sessionTaskFailed(let underlying):
                if let urlError = underlying as? URLError {
                    switch urlError.code {
                    case .notConnectedToInternet:
                        return String(localized: "Your device isn't connected to the internet. Please check your connection and try again.")
                    case .timedOut:
                        return String(localized: "The server took too long to respond. Please try again later.")
                    default:
                        return nil
                    }
                }
                return nil
            case .responseValidationFailed(let reason):
                if case .unacceptableStatusCode(let code) = reason {
                    return String(localized: "The server returned error \(code). Please check your request or try again later.")
                }
                return nil
            default:
                return nil
            }
        default:
            return nil
        }
    }
}

// Register for immediate use
ErrorKit.registerMapper(AlamofireErrorMapper.self)

This extensibility opens up possibilities for:

• Adding custom mappings in your app for popular libraries like Alamofire

• Creating mapper packages for closed-source SDKs like Stripe, Admob, etc.

• Sharing error mappings within teams or organizations

Conclusion

Error messages significantly impact user experience yet often go overlooked in development. ErrorKit’s userFriendlyMessage(for:) function creates a framework for transforming this through community collaboration—one where developers pool their knowledge to make the entire Swift ecosystem more user-friendly.

If you’ve decoded cryptic error messages, your experience is valuable. By contributing to ErrorKit, you can fix these issues not just for yourself, but for every Swift developer who faces the same challenges. Check out ErrorKit and share your solutions to build this community resource:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Have you encountered cryptic error messages in Apple frameworks? Have you made them more helpful for yourself? Let me know on socials (links below)!

Previous articles in this series:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

2. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

3. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

If you’ve ever supported an iOS app, you’ve received this frustratingly vague user feedback. No steps to reproduce, no error message, no context—just the dreaded “doesn’t work” report that leaves you with more questions than answers.

Even the most detail-oriented users rarely know what information you need to diagnose issues. And when they do try to help, they might not have the technical knowledge to provide the right details. This disconnect creates a frustrating experience for everyone involved.

In this post, I’ll share two practical approaches I’ve implemented in ErrorKit to bridge this gap: a simple feedback button that automatically collects diagnostic logs, and a structured approach to error analytics that helps you identify patterns even without direct user reports.

The Missing Context Problem

When users encounter issues, several challenges make diagnosis difficult:

1. They don’t know what information you need

2. They can’t easily access system logs

3. They struggle to remember and articulate exact steps

4. Complex issues may involve multiple components

5. Intermittent issues are hard to reproduce on demand

Without proper context, debugging becomes a guessing game. You might spend hours trying to reproduce an issue that could be solved in minutes with the right information.

Solution 1: Feedback Button with Logs Attached

The first solution is to make it ridiculously easy for users to send you complete information. ErrorKit provides a SwiftUI modifier that adds a mail composer with automatic log collection:

struct ContentView: View {
    @State private var showMailComposer = false

    var body: some View {
        VStack {
            // Your app content

            Button("Report a Problem") {
                showMailComposer = true
            }
            .mailComposer(
                isPresented: $showMailComposer,
                recipient: "support@yourapp.com",
                subject: "YourApp Bug Report",
                messageBody: """
                   Please describe what happened:



                   ----------------------------------
                   Device: \(UIDevice.current.model)
                   iOS: \(UIDevice.current.systemVersion)
                   App version: \(Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String ?? "Unknown")
                   """,
                attachments: [
                    try? ErrorKit.logAttachment(ofLast: .minutes(30))
                ]
            )
        }
    }
}

This creates a simple “Report a Problem” button that:

1. Opens a pre-filled email composer

2. Includes device and app information

3. Automatically attaches recent system logs

4. Provides space for the user to describe the issue

The log attachment is the secret sauce here. When the user taps this button after encountering an issue, you get a comprehensive picture of what was happening in and around your app when the problem occurred.

Leveraging Apple’s Unified Logging System

ErrorKit uses Apple’s unified logging system (OSLog/Logger) to collect diagnostic information. If you’re not already using structured logging, here’s a quick intro:

import OSLog

// Create loggers
let logger = Logger()
// or with subsystem and category
let networkLogger = Logger(subsystem: "com.yourapp", category: "networking")

// Log at appropriate levels
logger.debug("Detailed connection info")      // Development debugging
logger.info("User tapped submit button")      // General information
logger.notice("Profile successfully loaded")   // Important events
logger.error("Failed to load user data")      // Errors that should be fixed
logger.fault("Database corruption detected")   // System failures

// Format values and control privacy
logger.info("User \(userId, privacy: .private) logged in from \(ipAddress, privacy: .public)")

The unified logging system provides several advantages over print() statements:

• Log levels for filtering information

• Privacy controls for sensitive data

• Efficient performance with minimal overhead

• Persistence across app launches

Comprehensive Log Collection

A key advantage of ErrorKit’s approach is that it captures not just your app’s logs, but also relevant logs from:

1. Third-party frameworks that use Apple’s unified logging system

2. System components your app interacts with (networking, file system, etc.)

3. Background processes related to your app’s functionality

This gives you a complete picture of what was happening in and around your app when the issue occurred—not just the logs you explicitly added.

Controlling Log Collection

You can customize log collection to balance detail and privacy:

// Collect logs from last 30 minutes with notice level or higher (default)
try ErrorKit.logAttachment(ofLast: .minutes(30), minLevel: .notice)

// Collect logs from last hour with error level or higher (less verbose)
try ErrorKit.logAttachment(ofLast: .hours(1), minLevel: .error)

// Collect logs from last 5 minutes with debug level (very detailed)
try ErrorKit.logAttachment(ofLast: .minutes(5), minLevel: .debug)

The minLevel parameter filters logs by importance:

• .debug: All logs (very verbose)

• .info: Informational logs and above

• .notice: Notable events (default)

• .error: Only errors and faults

• .fault: Only critical errors

This gives you control over how much information you collect while still providing the context you need for diagnosis.

Alternative Methods for More Control

If you need more control over log handling, ErrorKit offers additional approaches:

Getting Log Data Directly

For sending logs to your own backend or processing them in-app, use loggedData:

let logData = try ErrorKit.loggedData(
    ofLast: .minutes(10),
    minLevel: .notice
)

// Use the data with your custom reporting system
analyticsService.sendLogs(data: logData)

Exporting to a Temporary File

For sharing logs via other mechanisms, use exportLogFile:

let logFileURL = try ErrorKit.exportLogFile(
    ofLast: .hours(1),
    minLevel: .error
)

// Share the log file
let activityVC = UIActivityViewController(
    activityItems: [logFileURL],
    applicationActivities: nil
)
present(activityVC, animated: true)

Solution 2: Smart Error Analytics with Grouping IDs

While the feedback button helps users report issues they notice, many problems go unreported. Users might encounter an error, shrug, and try again—never telling you about it. That’s where error analytics comes in.

ErrorKit provides tools to automatically track errors and group them intelligently:

func handleError(_ error: Error) {
    // Get a stable ID that ignores dynamic parameters
    let groupID = ErrorKit.groupingID(for: error)

    // Get the full error chain description
    let errorDetails = ErrorKit.errorChainDescription(for: error)

    // Send to your analytics system
    Analytics.track(
        event: "error_occurred",
        properties: [
            "error_group": groupID,
            "error_details": errorDetails,
            "user_id": currentUser.id
        ]
    )

    // Show appropriate UI to the user
    showErrorAlert(message: ErrorKit.userFriendlyMessage(for: error))
}

Sample global error handling function to add to your app.

The magic here is in the groupingID(for:) function. It generates a stable identifier based on the error’s type structure and enum cases, ignoring dynamic parameters and localized messages.

This means that errors with the same underlying cause will have the same grouping ID, even if specific details (like file paths or user IDs) differ:

// Both generate the same groupID: "3f9d2a"
ProfileError
└─ DatabaseError
   └─ FileError.notFound(path: "/Users/john/data.db")

ProfileError
└─ DatabaseError
   └─ FileError.notFound(path: "/Users/jane/backup.db")

This approach provides several benefits:

1. Identify common issues: See which errors occur most frequently

2. Prioritize fixes: Focus on high-impact problems first

3. Track resolution: Monitor if error rates decrease after fixes

4. Detect new issues: Quickly identify new error patterns after releases

5. Correlate with user segments: See if some errors affect specific users

Combine Both Approaches for Max Insight

A powerful approach is to combine automatic analytics with user-initiated feedback, so you might want to do something like this:

func handleError(_ error: Error) {
    // Always track for analytics
    trackErrorAnalytics(error)

    // For serious or unexpected errors, prompt for feedback
    if isSerious(error) {
        showErrorAlert(
            message: ErrorKit.userFriendlyMessage(for: error),
            feedbackOption: true
        )
    } else {
        // For minor issues, just show a message
        showErrorAlert(message: ErrorKit.userFriendlyMessage(for: error))
    }
}

func showErrorAlert(message: String, feedbackOption: Bool = false) {
    // Implementation of an alert that optionally includes a
    // "Send Feedback" button that opens the mail composer with logs
}

This creates a comprehensive system where:

1. All errors are tracked for analytics, giving you broad patterns

2. Serious errors prompt users for detailed feedback with logs

3. Users can always initiate feedback for issues you might not track

Best Practices for Logging

To maximize the value of log collection, consider these best practices:

1. Structure Logs for Context

Provide enough context in your logs to understand what was happening:

// Instead of:
Logger().error("Failed to load")

// Use:
Logger().error("Failed to load document \(documentId): \(ErrorKit.errorChainDescription(for: error))")

2. Choose Appropriate Log Levels

Use log levels strategically to control verbosity:

• .debug for developer details only needed during development

• .info for tracking normal app flow

• .notice for important events users would care about

• .error for problems that need fixing but don’t prevent core functionality

• .fault for critical issues that break core functionality

3. Protect Sensitive Information

Use privacy modifiers to protect user data:

Logger().info("Processing payment for user \(userId, privacy: .private)")

4. Log Key User Actions

Create breadcrumbs of user activity to understand the path to errors:

Logger().notice("User navigated to profile screen")
Logger().info("User tapped edit button")
Logger().notice("User saved profile changes")

5. Log Start and Completion of Important Operations

Bracket significant operations to identify incomplete tasks:

Logger().notice("Starting data sync")
// ... sync implementation
Logger().notice("Completed data sync")

The Impact on Support and Development

Implementing these tools can transform both user experience and development workflows:

For Users:

• Simplified Reporting: Submit feedback with a single tap

• No Technical Questions: Avoid frustrating back-and-forth communications

• Faster Resolution: Issues can be diagnosed and fixed more quickly

• Better Experience: Shows users you take their problems seriously

For Developers:

• Complete Context: See exactly what was happening when issues occurred

• Reduced Support Time: Less time spent asking for additional information

• Better Reproduction: More reliable reproduction steps based on log data

• Efficient Debugging: Quickly identify patterns in error reports

• Data-Driven Priorities: Focus on fixing the most common issues first

Conclusion

ErrorKit’s approach bridges that frustrating gap between a user saying “it doesn’t work” and actually knowing what happened. I’ve found that automatic log collection combined with smart error analytics creates a feedback loop that actually works.

What’s really powerful is getting detailed logs when users choose to report problems while also catching the issues they never mention. This dual approach has transformed how I understand and fix problems in my apps. If you’re tired of debugging issues blindfolded, ErrorKit includes all these logging tools and error handling improvements—tools I built because I needed them myself:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

How do you handle user feedback and error reporting? Have you found other effective techniques that actually help? Tell me on socials (links below)!

Previous articles in this series:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

2. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

Following article in this series:

1. Making Swift Error Messages Human-Friendly—Together

In this post, I’ll explain the nesting problem and show you how I’ve solved it in ErrorKit with a simple protocol that makes typed throws practical without boilerplate. As a bonus, you’ll see how proper error chaining can dramatically improve your debugging experience.

Typed Throws: The Promise and the Problem

First, let’s look at what Typed Throws gives us in Swift 6:

// Instead of just 'throws', we can specify the error type
func processFile() throws(FileError) {
    if !fileExists {
        throw FileError.fileNotFound(fileName: "config.json")
    }
    // Implementation...
}

This enables better error handling at the call site:

do {
    try processFile()
} catch FileError.fileNotFound(let fileName) {
    print("Could not find file: \(fileName)")
} catch FileError.readFailed {
    print("Could not read file")
}
// No generic catch needed if we've handled all possible FileError cases!

The benefits are clear:

• Compile-time verification of error handling

• No need for type casting with as? in catch blocks

• Self-documenting API that tells callers exactly what can go wrong

• IDE autocompletion for error cases

The Nesting Hell Problem

The problem arises when working with multi-layered applications. Consider this:

// Database layer throws DatabaseError
func fetchUser(id: String) throws(DatabaseError) {
    // Database operations...
}

// Profile layer needs to call the database layer
func loadUserProfile(id: String) throws(ProfileError) {
    do {
        // ⚠️ Problem: This throws DatabaseError, not ProfileError
        let user = try fetchUser(id: id)
    } catch {
        // Manual error conversion needed
        switch error {
        case DatabaseError.recordNotFound:
            throw ProfileError.userNotFound
        default:
            throw ProfileError.databaseError(error) // Need a wrapper case
        }
    }
}

This creates several problems:

1. Wrapper Cases Explosion: Every error type needs wrapper cases for all possible child errors

2. Manual Error Mapping: Repetitive do-catch blocks with explicit error conversion

3. Type Proliferation: Error types grow with each layer, becoming harder to maintain

4. Lost Context: Details about the original error often get lost in translation

For small apps, this might be manageable. For larger apps with many layers, it quickly becomes what can be described as “nesting hell”.

The Solution: The Catching Protocol

ErrorKit solves this with a simple protocol called Catching:

public protocol Catching {
    static func caught(_ error: Error) -> Self
}

This protocol requires a single enum case named caught that wraps any error into your type. Here’s how you use it:

enum ProfileError: Throwable, Catching {
    case userNotFound
    case invalidProfile
    case caught(Error) // Single case for all other errors

    var userFriendlyMessage: String {
        switch self {
        case .userNotFound:
            return "User not found."
        case .invalidProfile:
            return "Profile data is invalid."
        case .caught(let error):
            // Use the wrapped error's message
            return ErrorKit.userFriendlyMessage(for: error)
        }
    }
}

Note that Throwable is a drop-in replacement for Error (see previous post).

Now, the magic happens with the catch function that comes with the protocol:

func loadUserProfile(id: String) throws(ProfileError) {
    // For known errors, throw them directly
    guard isValidID(id) else {
        throw ProfileError.invalidInput
    }

    // For operations that may throw other error types, use the catch function
    let user = try ProfileError.catch {
        // Any error thrown here will be automatically wrapped
        // into ProfileError.caught(error)
        return try fetchUser(id: id)
    }

    // Rest of implementation...
}

Note that the catch function returns whatever you return in the closure.

The catch function automatically wraps any errors thrown in its closure into your error type. No manual do-catch blocks, no explicit error mapping—it just works. Even multiple try expressions are possible.

The catch Function’s Secret Sauce

The catch function is elegantly simple:

extension Catching {
    public static func `catch`<ReturnType>(
        _ operation: () throws -> ReturnType
    ) throws(Self) -> ReturnType {
        do {
            return try operation()
        } catch {
            throw Self.caught(error)
        }
    }
}

This function:

1. Takes a throwing closure

2. Tries to execute it

3. Returns the result if successful

4. Automatically wraps any thrown error using your caught case

5. Preserves the return type of the operation

The best part? It works seamlessly with Swift 6’s typed throws, maintaining type safety while eliminating boilerplate.

Preserving the Error Chain for Debugging

One of the biggest benefits of this approach is that it preserves the complete error chain. Instead of losing context when errors cross boundaries, each layer adds information while keeping the original error intact.

ErrorKit leverages this to provide powerful debugging with the errorChainDescription(for:) function:

do {
    try await updateUserProfile()
} catch {
    print(ErrorKit.errorChainDescription(for: error))

    // Output shows the complete chain:
    // AppError
    // └─ ProfileError
    //    └─ DatabaseError
    //       └─ FileError.notFound(path: "/Users/data.db")
    //          └─ userFriendlyMessage: "Could not find database file."
}

This hierarchical view tells you:

1. Where the error originated (FileError)

2. The exact path it took through your application (FileError → DatabaseError → ProfileError → AppError)

3. The specific details of what went wrong (file not found, with the path)

4. The user-friendly message that would be shown to users

This level of insight is invaluable during debugging, especially for complex applications where errors might originate deep in the call stack.

Structured Error Chain Output

The error chain description works by recursively inspecting the error structure:

static func errorChainDescription(for error: Error) -> String {
    // Recursive implementation that builds a hierarchical description
    Self.chainDescription(for: error, enclosingType: type(of: error))
}

See here for the full implementation of chainDescription inside ErrorKit.

The function uses Swift’s reflection capabilities to:

1. Inspect the error using the Mirror API

2. For errors conforming to Catching, extract the wrapped error

3. For enum errors, capture case names and associated values

4. For struct or class errors, include type metadata

5. Format everything in a hierarchical tree structure

This provides far more information than standard error logging, particularly for complex error hierarchies.

Built-in Support in ErrorKit

All of ErrorKit’s built-in error types (like FileError or NetworkError) already conform to Catching, so you can use them right away:

func saveUserData() throws(DatabaseError) {
    // Automatically wraps SQLite errors, file system errors, etc.
    try DatabaseError.catch {
        try database.beginTransaction()
        try database.execute(query)
        try database.commit()
    }
}

Real-World Example: A Typical Application

Let’s see how this works in a more complete example:

// Data Access Layer
func fetchUserData(id: String) throws(DatabaseError) {
    guard database.isConnected else {
        throw DatabaseError.connectionFailed
    }

    // This could throw file system errors
    try DatabaseError.catch {
        let query = try QueryBuilder.build(for: id)
        return try database.execute(query)
    }
}

// Business Logic Layer
func processUserProfile(id: String) throws(ProfileError) {
    guard isValidID(id) else {
        throw ProfileError.invalidInput
    }

    // This automatically wraps DatabaseError
    let userData = try ProfileError.catch {
        return try fetchUserData(id: id)
    }

    // Process the user data...
}

// Presentation Layer
func displayUserProfile(id: String) throws(UIError) {
    // This automatically wraps ProfileError (which might contain DatabaseError)
    let profile = try UIError.catch {
        return try processUserProfile(id: id)
    }

    // Display the profile...
}

If a database connection fails, here’s what you’ll see in the error chain:

UIError
└─ ProfileError
   └─ DatabaseError.connectionFailed
      └─ userFriendlyMessage: "Unable to establish a connection to the database. Check your network settings and try again."

This tells you exactly what happened and where the error originated, making debugging much easier. The added context can give you the right hint to fix the issue!

Conclusion

Swift 6’s typed throws is a powerful addition to the language, but it introduces challenges for error propagation across layers. The Catching protocol offers a simple, elegant solution that maintains type safety while eliminating boilerplate.

Combined with ErrorKit’s errorChainDescription function, error handling becomes a powerful debugging tool. Use ErrorKit now and profit from many other improvements that make error handling in Swift more useful in real-world apps:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Have you started using Swift 6’s typed throws? How are you handling error propagation across layers in your apps? Let me know on socials (links below)!

Previous article in this series:

1. Swift Error Handling Done Right: Overcoming the ObjC Legacy

Following articles in this series:

1. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

2. Making Swift Error Messages Human-Friendly—Together

“The operation couldn’t be completed. (YourApp.YourError error 0.)”

If so, you’re not alone. This confusing behavior has been tripping up Swift developers—from beginners to experts—since the language was introduced. Today, I want to explain why this happens and present a solution that makes Swift error handling more intuitive.

The Surprising Behavior of Swift’s Error Protocol

Let’s look at a simple example that demonstrates the problem:

enum NetworkError: Error {
   case noConnectionToServer
   case parsingFailed

   var localizedDescription: String {
      switch self {
      case .noConnectionToServer:
         return "No connection to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }
}

// Using the error
do {
   throw NetworkError.noConnectionToServer
} catch {
   print("Error message: \(error.localizedDescription)")
   // Expected: "No connection to the server."
   // Actual: "The operation couldn't be completed. (AppName.NetworkError error 0.)"
}

What went wrong? We defined a clear error message, but Swift ignored it completely!

Why This Happens: The NSError Bridge

This confusing behavior occurs because Swift’s Error protocol is bridged to Objective-C’s NSError class behind the scenes. When you access localizedDescription, Swift doesn’t use your property—it creates an NSError with a domain (your module name), a code (the enum case’s integer value), and a default message.

This design might make sense for Objective-C interoperability, but it creates a terrible developer experience, especially for those new to Swift.

The “Official” Solution: LocalizedError

Swift does provide an official solution: the LocalizedError protocol. Here’s how you’re supposed to use it:

enum NetworkError: LocalizedError {
   case noConnectionToServer
   case parsingFailed

   var errorDescription: String? { // Note: Optional String
      switch self {
      case .noConnectionToServer:
         return "No connection to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }

   // There are also these optional properties that are rarely used
   var failureReason: String? { return nil }
   var recoverySuggestion: String? { return nil }
   var helpAnchor: String? { return nil }
}

While this works, it has several problems:

• All properties are optional (String?), so the compiler won’t help you if you forget to handle a case

• Only errorDescription affects localizedDescription; the other properties are often ignored

• The naming doesn’t clearly indicate which property affects the displayed message

• It still uses a legacy approach based on Cocoa error handling patterns

A Better Solution: The Throwable Protocol

After experiencing this frustration too many times, I created a simpler solution as part of ErrorKit—a protocol called Throwable:

public protocol Throwable: LocalizedError {
   var userFriendlyMessage: String { get }
}

This protocol has several advantages:

• It has a single, non-optional requirement—no more forgetting cases

• The name userFriendlyMessage clearly expresses intent

• It extends LocalizedError for compatibility (no extra work for you!)

• It follows Swift naming conventions with the -able suffix

Here’s how you use it:

enum NetworkError: Throwable {
   case noConnectionToServer
   case parsingFailed

   var userFriendlyMessage: String {
      switch self {
      case .noConnectionToServer:
         return "Unable to connect to the server."
      case .parsingFailed:
         return "Data parsing failed."
      }
   }
}

// Using the error
do {
   throw NetworkError.noConnectionToServer
} catch {
   print("Error message: \(error.localizedDescription)")
   // Now correctly shows: "Unable to connect to the server." 🎉
}

With Throwable, what you see is what you get—your error messages appear exactly as intended, with no surprises.

Quick Development with String Raw Values

For rapid prototyping, Throwable also works seamlessly with string raw values:

enum NetworkError: String, Throwable {
   case noConnectionToServer = "Unable to connect to the server."
   case parsingFailed = "Data parsing failed."
}

// That's it! No extra implementation needed

The raw string values automatically become your error messages, eliminating boilerplate during early development. Later, when you’re ready for proper localization, you can switch to using String(localized:) in a full implementation of userFriendlyMessage.

Ready-To-Use Error Types

To further reduce boilerplate, ErrorKit includes pre-defined error types for common scenarios:

func fetchData() async throws {
    guard isNetworkAvailable else {
        throw NetworkError.noInternet
    }

    guard let url = URL(string: path) else {
        throw ValidationError.invalidInput(field: "URL path")
    }

    // More implementation...
}

These built-in types include:

• NetworkError for connectivity and API issues

• FileError for file system operations

• DatabaseError for data persistence issues

• ValidationError for input validation

• PermissionError for authorization issues

• And several more…

Each built-in type already conforms to Throwable and provides localized user-friendly messages out of the box, saving you time while maintaining clarity.

Quick One-Off Errors with GenericError

For those situations where you need a custom message without defining a whole new error type, ErrorKit provides GenericError:

func quickOperation() throws {
    guard condition else {
        throw GenericError(userFriendlyMessage: "The operation couldn't be completed because a specific condition wasn't met.")
    }

    // More implementation...
}

This is perfect for early development or unique error cases that don’t warrant a dedicated error type.

Benefits Beyond Better Messages

Adopting Throwable doesn’t just fix error messages—it brings several additional benefits:

1. Clarity for new developers: The protocol clearly indicates how to define error messages

2. Compile-time safety: The non-optional requirement ensures all cases have messages

3. Localization support: Works perfectly with String(localized:) for internationalization

4. Reduced boilerplate: Especially with raw string values and built-in types

5. Improved user experience: Clear error messages help users understand what went wrong

6. Better debugging: Meaningful error messages make debugging faster

Making the Transition

The best part? Throwable is a drop-in replacement for Error:

// Before
enum AppError: Error {
    case configurationFailed
}

// After
enum AppError: Throwable {
    case configurationFailed

    var userFriendlyMessage: String {
        switch self {
        case .configurationFailed:
           return "Failed to load configuration."
        }
    }
}

Existing code using throws, do/catch, and other error handling patterns work exactly the same—the only difference is that now your error messages actually appear as intended.

Conclusion

Swift’s error handling is powerful, but its message handling has been a confusing pain point for too long. The Throwable protocol provides a simple, intuitive solution that aligns with Swift’s design principles while fixing a longstanding issue.

By adopting Throwable for your error types, you get clearer error messages, reduced boilerplate, and a more intuitive developer experience. Combined with built-in error types and the GenericError fallback, it creates a comprehensive approach to error handling that works the way you’d expect.

If you want to try this approach in your own projects, check out ErrorKit, which includes the Throwable protocol, built-in error types, and many other error handling improvements for Swift:

github.comFlineDev / ErrorKitSimplified error handling with built-in user-friendly messages for common errors. Fully localized. Community-driven

Have you encountered this error message confusion in your Swift development? How have you addressed it? Let me know on social media (links below)!

Following articles in this series:

1. Unlocking the Power of Swift 6’s Typed Throws with Error Chains

2. Better Error Reporting in Swift Apps: Automatic Logs + Analytics

3. Making Swift Error Messages Human-Friendly—Together

Swift macros, introduced in Xcode 15 with Swift 5.9, are a powerful feature that enables code generation and compile-time metaprogramming. While they offer excellent developer productivity benefits, they’ve introduced a new challenge for CI/CD pipelines, particularly in Xcode Cloud.

When you first use a macro locally, Xcode displays a dialog asking you to trust the macro’s package before it can be executed. This works fine on your development machine, but becomes problematic in automated environments like Xcode Cloud where there’s no way to click “OK” on a dialog box.

If you’ve tried to build a project using Swift macros in Xcode Cloud, you’ve likely encountered this frustrating error:

Target must be enabled before it can be used.

A Complete Solution

After some research, I’ve found a reliable solution that works consistently for Xcode Cloud builds using Swift macros. Here’s how to implement it:

Step 1: Create a CI Scripts Folder

First, let’s create a dedicated folder for our CI scripts:

1. Right-click your project in Xcode

2. Select “New Group”

3. Name it ci_scripts

Step 2: Create the Post-Clone Script

Next, we’ll create a post-clone script that Xcode Cloud will automatically execute after cloning your repository:

1. Right-click the ci_scripts folder

2. Select “New File” → “Empty File”

3. Name it ci_post_clone.sh

Step 3: Add the Script Content

Copy and paste the following code into your new ci_post_clone.sh file:

#!/bin/sh

# Exit on error (-e), undefined vars (-u), and pipeline failures (-o pipefail)
set -euo pipefail

# Disable Xcode macro fingerprint validation to prevent spurious build errors
defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES

This script does one crucial thing: it disables Xcode’s macro fingerprint validation, which is what triggers the trust dialog in the first place.

Step 4: Make the Script Executable

Open Terminal, navigate to your project folder, and run:

chmod +x ci_scripts/ci_post_clone.sh

This command makes your script executable, which is required for Xcode Cloud to run it properly.

Step 5: Commit and Trigger a Build

Commit the new file to your repository and push the changes. This will trigger a new build in Xcode Cloud, which should now complete successfully without the macro trust error.

How It Looks

When properly set up, your project structure should include the CI scripts folder with the post-clone script:

Why This Works

Xcode Cloud automatically executes any script named ci_post_clone.sh located in a ci_scripts directory at the root of your project. Our script modifies the Xcode preferences to disable macro fingerprint validation, effectively bypassing the trust requirement.

The command defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES changes a specific Xcode preference that controls whether macros need to be explicitly trusted before they can be used.

Security Considerations

Some developers suggest copying the macros.json file (which contains trusted macro fingerprints) from your local machine to the CI environment. However, I believe this approach isn’t necessarily more secure than simply disabling validation.

The key consideration here is context: Xcode Cloud runs in a sandboxed environment specifically for building your application. It’s not executing arbitrary code on production systems. If you can’t trust your development team and your release workflow, you likely have more significant security concerns than macros running in a CI environment.

The Growing Importance of This Solution

As Swift continues to evolve, more and more third-party packages are implementing macros to provide powerful features with minimal boilerplate. For example:

• TranslateKit SDK offers localization macros

• Various logging and debugging libraries are adopting macros

• UI frameworks are using macros to simplify view declarations

This trend will only accelerate as developers discover new use cases for compile-time metaprogramming. Having a reliable solution for handling macros in CI pipelines will become increasingly important for Swift projects.

Now that you’ve solved the macro trust issue, you can take full advantage of Xcode Cloud’s capabilities. In fact, I’ll be exploring how to utilize Xcode Cloud for App Store deployments in my next article and accompanying video. This approach can save you valuable time waiting for builds, especially if you ship on multiple Apple platforms (iOS, macOS, visionOS) like I do. Stay tuned for that and happy coding!

Yet, as I dug deeper into String Catalogs, I realized something interesting: Apple’s deep SwiftUI integration offered possibilities that weren’t achievable through Xcode extensions. Instead of fighting the tide, I decided to embrace it. Over a single weekend, I built a simple tool that could parse String Catalogs and handle machine translations. That tool became TranslateKit.

An Unexpected Success Story

What started as a weekend project for personal use quickly became my most successful app to date. Developers worldwide embraced TranslateKit’s simplicity and efficiency. The feedback exceeded my expectations for such a quickly written app, and with it came valuable insights about what developers really needed from a localization tool. Just recently, a fellow indie developer shared on Bluesky:

1/ I've always wanted to localize @glusight.app, but I initially thought it'd require significant refactoring, which I wasn't prepared for. However, my new project, setup with localization from the start made it clear how easy Apple and tools like @translatekit.app make the process.

#BuildInPublic

— slowbrewed.studio (@creativewith.in) 2025-02-03T15:42:08.641Z

This resonated deeply with me. Many developers overestimate the effort required to localize their SwiftUI apps. Getting to 90% localization coverage is surprisingly straightforward with today’s tools, and reaching that last 10% is becoming easier than ever.

Consider this: About 80% of the world’s population doesn’t speak English. Lack of localization is statistically the number one reason globally for an app being inaccessible to users. Every app should be localized – it’s not just about reaching more users, it’s about making your app truly accessible. And I’ve made it my mission to make this as easy as possible for Indie developers.

The Evolution to TranslateKit 3

After a year of learning from user feedback, I realized I could do much better. The biggest pain point? Setting up API keys. Developers found themselves registering for various translation services, dealing with credit cards, and managing API quotas. It was too much friction for what should be a simple process.

Then there were the translation quality issues. While my machine translation integrations were good, they often missed crucial context by translating each string in isolation. A button that made perfect sense in English could become awkwardly verbose or totally miss the context in other languages. By processing strings in batches and providing full app context to the AI, TranslateKit 3 maintains consistency and an appropriate tone across your entire app.

Project-wide management was another crucial improvement. Previously, developers had to remember to drag and drop their InfoPlist.xcstrings file separately – leading to situations where apps would be localized but permission dialogs would still appear in English. Now, TranslateKit handles your entire project at once, ensuring nothing gets missed.

This led to a complete rebuild, focusing on what matters most to developers:

1. Zero setup required - no more API keys or service registrations

2. Context-aware AI translations that understand your app’s purpose

3. Project-wide localization that catches everything, including permission texts

4. Intelligent handling of your app’s brand terms and terminology

5. Support for language-specific nuances like formality and cultural context

The results? Translation errors reduced by about 90% compared to traditional services. On top of that, TranslateKit 3 introduces AI proofreading, a unique feature that can improve any existing translations, whether they’re from an older version of TranslateKit or any other source. Just select the languages to check and let the AI fine-tune your translations for even better accuracy.

See for yourself what Noah, the developer behind Proxyman, is saying:

love this feature.

Meanwhile, Google Translate is so stupid, it tried to translate universal terms like HEAD, GET, Proxy, REST ... to Chinese, which is completely wrong pic.twitter.com/YaxCan3kUH

— Noah Tran (@_nghiatran) February 17, 2025

Noah about the localization of his very large app Proxyman.

And with the new pay-what-you-need pricing approach, localization is finally affordable for all indie developers. You can test the waters by adding a single language for just $1 (with a free first month to try it out), or go all in and reach 5x more users by adding the top 10 languages to an average-sized app in just 4 minutes, for less than $5. I hope this makes app localization as affordable as possible and removes one more barrier for developers considering it.

Looking Beyond iOS

But I didn’t stop there. As I shared in my recent post about the TranslateKit SDK, SwiftUI developers can now benefit from automatic key generation with the #tk macro and access over 2,000 pre-translated common UI texts with a call like TK.Action.cancel. Both will help further improve the accuracy of localization. And while iOS development will always be my primary focus, I’ve designed TranslateKit’s core translation system to be platform-agnostic, paving the way for supporting other app platforms in the future, Android and Flutter being the first.

I’m putting the finishing touches on a comprehensive video guide that will show just how straightforward app localization has become. Because sometimes, seeing is believing – and I want every developer to know they can make their app global without the headaches they might expect. For now, this 50 sec video must suffice:

Try It Yourself

The best way to understand how easy localization has become is to try it. Add a String Catalog to your project, build your app, and you might be surprised to find it already mostly has all the entries to be localized. With TranslateKit 3, you can translate them with context-aware AI, ensure consistency across your entire project, and reach users worldwide faster than ever.

The journey from RemafoX to TranslateKit has taught me that sometimes, what seems like a setback can lead to building something even better. By embracing new technologies and really listening to developer needs, I’ve created a tool that makes app localization easier & better. Patience always pays off in the end!

To understand how far localization has come—and where it still falls short—let’s take a quick look back: At the pre-String Catalogs era, developers relied on a combination of .strings and .stringsdict files, organized in language-specific folders like en.lproj. This system, while functional, had several drawbacks:

1. Missing safety checks for unused or missing translations

2. Manual synchronization needed between different language files

3. No built-in support for extracting strings from code

Tools like SwiftGen and BartyCrouch emerged to address these issues, providing type safety and automated extraction. And the community established best practices around using semantic keys (e.g., "Onboarding.Page1.title") to provide context for translators and group related strings together.

String Catalogs: A Game-Changer with Trade-offs

String Catalogs introduced by Apple in 2023 solved several long-standing issues:

✅ Automatic key extraction from code ✅ Built-in safety checks for missing translations ✅ Visual progress tracking in Xcode ✅ Unified file format for all languages ✅ Backward compatibility with older iOS versions

However, Apple’s recommended approach of using English strings as keys, while improving readability in code, introduced new challenges:

❌ Related strings are scattered alphabetically ❌ Reduced context for translators ❌ No grouping by feature or screen

The lack of grouping in String Catalogs is not helpful while translating.

Just as importantly, there’s a significant gap in the iOS development ecosystem around localization that mirrors where we were with icons before SF Symbols. Before SF Symbols, every developer had to create or source their own icons, leading to inconsistent experiences across apps. SF Symbols solved this by providing a standardized, comprehensive set of icons that ensure consistency and save tremendous development time.

The localization space desperately needs a similar solution. Every app needs common UI strings like “Save,” “Cancel,” “Done,” “Privacy Policy,” or “Terms and Conditions” – and these should be consistent across apps just like icons are. Users benefit from this consistency in the same way they benefit from consistent iconography. Yet currently, each developer must translate these common UI elements independently, leading to varying translations for the same concepts across different apps in different languages.

Enter TranslateKit: The Missing Piece

The open-source TranslateKit SDK bridges these gaps, offering a comprehensive solution that maintains best practices while fully embracing the benefits of String Catalogs. Just as SF Symbols revolutionized icon usage in iOS apps, this new Swift package aims to do the same for localization.

1. Semantic Key Generation Without the Hassle

The #tk macro brings back semantic keys while keeping code clean and readable:

struct OnboardingView: View {
  var body: some View {
    // Generates key: OnboardingView.Body.welcomeToMyApp
    Text(#tk("Welcome to MyApp"))
  }
}

This approach:

• Automatically generates semantic keys based on code context

• Preserves code readability

• Provides essential context for translators

• Groups related strings together in String Catalogs

Auto-generated semantic keys, naturally grouping related strings together.

And all you need to write is #tk() around your String literals. Super simple!

2. Pre-localized Common UI Elements

Just as SF Symbols standardized icon usage, we need consistency in UI text. TranslateKit provides over 2,000 strings pre-localized to all 40 languages supported by Apple in the iOS operating system.

They are divided into 4 categories, making it easy to discover what you need:

// Actions
Button(TK.Action.save) { saveData() }
// => en: "Save", de: "Sichern", etc.

// Labels
Text(TK.Label.privacyPolicy)
// => en: "Privacy Policy", de: "Sichern", etc.

// Messages
Text(TK.Message.areYouSure)
// => en: "Privacy Policy", de: "Datenschutzerklärung", etc.

// Placeholders
ProgressView(TK.Placeholder.loadingDots)
// => en: "Loading…", de: "Laden…", etc.

Benefits:

• Matches system UI translations from Apple (Consistency)

• Ensures professional quality for common UI elements (Accuracy)

• Reduces localization overhead (save Time & Money)

3. Context-Aware Translations

Modern localization isn’t just about translating words—it’s about understanding context. While automatic key generation helps with this in 90% of the cases, in some cases you might need to additionally specify the optional c parameter:

struct DocumentView: View {
    let fileName: String

    var body: some View {
        Button(#tk("Delete '\(fileName)'?",
                   c: "Example: Delete 'MyStats.csv'?")) {
            handleDelete()
        }
    }
}

This comment parameter is most commonly needed when you have dynamic data in your string like in the example above. It’s important to always provide typical sample data in the comment to make it clear. Otherwise translators might not know how to translate properly.

What’s Next?

This article covered how TranslateKit SDK modernizes the core localization workflow. If you’re interested in more advanced topics like pluralization, formatters & more, subscribe to my YouTube channel to signal your interest in more detailed videos:

FlineDev

✨ TranslateKit SDK works perfectly together with TranslateKit for Mac, an accurate, AI-powered translation tool to localize the rest of your app! It’s super fast & affordable, try free now to reach more users.

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

The Wrong Way

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

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

The Right Way

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

Or using Label explicitly:

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

Why This Matters

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

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

Beyond Buttons

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

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

The .editorconfig Standard

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

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

root = true

[*.swift]
indent_style = space
indent_size = 3

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

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

Why This Beats Global Settings

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

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

Adoption

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

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

How to Enable It

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

1. Tap your profile icon or go to Settings

2. Select Notifications

3. You will see a list of all your apps

4. For each app, toggle on Customer Reviews

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

Why This Matters for Indie Developers

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

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

A Word of Caution

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

In this article, I’ll share a selection of the styles I’ve found most valuable in my daily development work across apps like TranslateKit, FreemiumKit, and CrossCraft. While HandySwiftUI contains many more utilities, these particular styles have proven their worth time and time again in real-world applications and could be helpful for your SwiftUI projects as well.

Primary, Secondary, and Pulsating Buttons

Create visually appealing buttons with pre-made styles for different use cases:

struct ButtonShowcase: View {
   var body: some View {
       VStack(spacing: 20) {
           // Primary button with prominent background
           Button("Get Started") {}
               .buttonStyle(.primary())

           // Secondary button with border
           Button("Learn More") {}
               .buttonStyle(.secondary())

           // Attention-grabbing pulsating button
           Button {} label: {
              Label("Updates", systemImage: "bell.fill")
                 .padding(15)
           }
           .buttonStyle(.pulsating(color: .blue, cornerRadius: 20, glowRadius: 8, duration: 2))
       }
   }
}

Horizontal, Vertical, Fixed Icon-Width Labels

Multiple label styles for different layout needs:

struct LabelShowcase: View {
   var body: some View {
       VStack(spacing: 20) {
           // Horizontal layout with trailing icon
           Label("Settings", systemImage: "gear")
               .labelStyle(.horizontal(spacing: 8, iconIsTrailing: true, iconColor: .blue))

           // Fixed-width icon for alignment
           Label("Profile", systemImage: "person")
               .labelStyle(.fixedIconWidth(30, iconColor: .green, titleColor: .primary))

           // Vertical stack layout
           Label("Messages", systemImage: "message.fill")
               .labelStyle(.vertical(spacing: 8, iconColor: .blue, iconFont: .title))
       }
   }
}

All parameters are optional with sensible defaults, so you can use them like .vertical(). You only need to specify what you want to customize.

Vertically Labeled Contents

Structured form inputs with vertical labels, as used in FreemiumKit’s API configuration:

struct APIConfigView: View {
    @State private var keyID = ""
    @State private var apiKey = ""

    var body: some View {
        Form {
            HStack {
                VStack {
                    LabeledContent("Key ID") {
                        TextField("e.g. 2X9R4HXF34", text: $keyID)
                            .textFieldStyle(.roundedBorder)
                    }
                    .labeledContentStyle(.vertical())

                    LabeledContent("API Key") {
                        TextEditor(text: $apiKey)
                            .frame(height: 80)
                            .textFieldStyle(.roundedBorder)
                    }
                    .labeledContentStyle(.vertical())
                }
            }
        }
    }
}

The .vertical style allows customizing alignment (defaults to leading) and spacing (defaults to 4). Pass muteLabel: false if you’re providing a custom label style, as by default labels are automatically styled smaller and grayed out.

For example, in FreemiumKit’s feature localization form, I want the vertical label to have a larger font:

LabeledContent {
   LimitedTextField(
      "English \(self.title)",
      text: self.$localizedString.fallback,
      characterLimit: self.characterLimit
   )
   .textFieldStyle(.roundedBorder)
} label: {
   Text("English \(self.title) (\(self.isRequired ? "Required" : "Optional"))")
      .font(.title3)
}
.labeledContentStyle(.vertical(muteLabel: false))

Multi-Platform Toggle Style

While SwiftUI provides a .checkbox toggle style, it’s only available on macOS. HandySwiftUI adds .checkboxUniversal that brings checkbox-style toggles to all platforms (rendering as .checkbox on macOS):

struct ProductRow: View {
    @State private var isEnabled: Bool = true

    var body: some View {
       HStack {
           Toggle("", isOn: $isEnabled)
              .toggleStyle(.checkboxUniversal)

           Text("Pro Monthly")

           Spacer()
       }
    }
}

The example is extracted from FreemiumKit’s products screen, which is optimized for macOS but also supports other platforms.

Get Started Today

I hope you find these styles as useful in your projects as I do in mine. If you have ideas for improvements or additional styles that could benefit the SwiftUI community, please feel free to contribute on GitHub:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

This is the final article in a series of four exploring HandySwiftUI’s features. Check out the previous articles about New Types, View Modifiers, and Extensions if you haven’t already!

In this article, I’ll share a selection of the extensions I’ve found most valuable in my daily development work across apps like TranslateKit, FreemiumKit, and CrossCraft. While HandySwiftUI contains many more utilities, these particular extensions have proven their worth time and time again in real-world applications and could be helpful for your SwiftUI projects as well.

Optional Binding Conveniences

The ?? and ! operators and the isPresent modifier simplify working with optional values in bindings:

struct EditableProfile: View {
   @State private var profile: Profile?
   @State private var showAdvanced = false

   var body: some View {
       Form {
           // Provide default value for optional binding using the `??` operator
           TextField("Name", text: $profile?.name ?? "Anonymous")

           // Negate binding value using `!` operator
           Toggle("Hide Details", isOn: !$showAdvanced)
       }
       // Use optional binding for sheet presentation
       .sheet(isPresented: $profile.isPresent(wrappedType: Profile.self)) {
           ProfileEditor(profile: $profile)
       }
   }
}

The operators are useful in all kinds of views, when working with optional data in models, for example.

Color Management

The comprehensive color extensions provide powerful tools for color manipulation and system color adoption:

struct ColorfulView: View {
   @State private var baseColor = Color.blue

   var body: some View {
       VStack {
           // Create variations of the base color
           Rectangle()
               .fill(baseColor.change(.luminance, by: -0.2))
           Rectangle()
               .fill(baseColor)
           Rectangle()
               .fill(baseColor.change(.luminance, by: 0.2))

           // Work with hex colors
           Circle()
               .fill(Color(hex: "#FF5733"))

           // Use color components
           Text("HSB: \(baseColor.hsbo.hue), \(baseColor.hsbo.saturation), \(baseColor.hsbo.brightness)")
           Text("RGB: \(baseColor.rgbo.red), \(baseColor.rgbo.green), \(baseColor.rgbo.blue)")
       }
       .padding()
       // Use semantic system colors for custom system-like components
       .background(Color.systemBackground)
   }
}

When adjusting color brightness, use .luminance instead of .brightness from the HSB color system. Luminance better represents how humans perceive light and dark, which is why HandySwiftUI includes support for the HLC color space.

Rich Text Formatting

The text formatting extensions provide a convenient way to create rich text with mixed styles inspired by XML-style tags:

struct FormattedText: View {
   var body: some View {
       Text(
           format: "A <b>bold</b> new way to <i>style</i> your text with <star.fill/> and <b>mixed</b> <red>formatting</red>.",
           partialStyling: Dictionary.htmlLike.merging([
               "red": { $0.foregroundColor(.red) },
               "star.fill": { $0.foregroundColor(.yellow) }
           ]) { $1 }  // returning $1 (instead of $0) means added keys override (potentially) existing keys
       )
   }
}

In the above example, the built-in .htmlLike styling that ships with HandySwiftUI is combined with custom tags. Note that .htmlLike simply returns this:

[
   "b": { $0.bold() },
   "sb": { $0.fontWeight(.semibold) },
   "i": { $0.italic() },
   "bi": { $0.bold().italic() },
   "sbi": { $0.fontWeight(.semibold).italic() },
   "del": { $0.strikethrough() },
   "ins": { $0.underline() },
   "sub": { $0.baselineOffset(-4) },
   "sup": { $0.baselineOffset(6) },
]

Any XML-like entries that end with a /> such as <star.fill/> from the example above get rendered as an SFSymbol. This way, you can easily use SFSymbols right within your text.

Image Handling

Unified extensions for image processing for UIImage and NSImage:

class ImageProcessor {
   func processImage(_ image: UIImage) {
       // Resize image while maintaining aspect ratio
       let resized = image.resized(maxWidth: 800, maxHeight: 600)

       // Convert to different formats
       let pngData = image.webpData()
       let jpegData = image.webpData(compressionQuality: 0.8)
       let heicData = image.heicData(compressionQuality: 0.8)
   }
}

Note that all these APIs return optional values for edge cases like when the system is extremely low on memory, but should succeed most of the time.

Convenient Model-to-View Conversions

HandySwiftUI provides initializer conveniences that make it easy to display your model types directly in SwiftUI views:

enum Tab: CustomLabelConvertible {
    case home, profile, settings

    var description: String {
        switch self {
        case .home: "Home"
        case .profile: "Profile"
        case .settings: "Settings"
        }
    }

    var symbolName: String {
        switch self {
        case .home: "house.fill"
        case .profile: "person.circle"
        case .settings: "gear"
        }
    }
}

struct ContentView: View {
    @State private var selectedTab: Tab = .home

    var body: some View {
        TabView(selection: $selectedTab) {
            HomeView()
                // Create tab item directly from enum case
                .tabItem { Label(convertible: Tab.home) }
                .tag(Tab.home)

            ProfileView()
                .tabItem { Label(convertible: Tab.profile) }
                .tag(Tab.profile)

            SettingsView()
                .tabItem { Label(convertible: Tab.settings) }
                .tag(Tab.settings)
        }

        // Works with Text and Image views too
        Text(convertible: selectedTab)  // Shows tab name
        Image(convertible: selectedTab) // Shows tab icon
    }
}

Instead of manually extracting strings and symbol names from your models, you can conform them to CustomStringConvertible for text, CustomSymbolConvertible for SF Symbols, or CustomLabelConvertible for both. Then use the convenient initializers to create SwiftUI views directly:

• Text(convertible:) - Creates text from any CustomStringConvertible

• Image(convertible:) - Creates SF Symbol images from any CustomSymbolConvertible

• Label(convertible:) - Creates text+icon labels from any CustomLabelConvertible

This pattern works especially well with enums representing UI states, menu options, or tabs, as shown in the example above.

Search Prefix Highlighting

HandySwiftUI provides an elegant way to highlight matching text in search results, making it easy to show users exactly what parts of the text matched their search query:

struct SearchResultsView: View {
    @State private var searchText = ""
    let translations = [
        "Good morning!",
        "Good evening!",
        "How are you?",
        "Thank you very much!"
    ]

    var body: some View {
        List {
            ForEach(translations.filtered(by: searchText), id: \.self) { translation in
                // When searching for "go mo", highlights "Go mo" in "Good morning!"
                Text(translation.highlightMatchingTokenizedPrefixes(in: searchText))
            }
        }
        .searchable(text: $searchText)
    }
}

extension [String] {
    func filtered(by searchText: String) -> [String] {
        guard !searchText.isEmpty else { return Array(self) }
        return filter { $0.localizedCaseInsensitiveContains(searchText) }
    }
}

This highlighting feature was originally developed for TranslateKit’s menu bar “Common Translations” feature, where it helps users quickly spot matching phrases in confirmed translations. The function breaks down the search text into tokens and highlights each matching prefix, making it perfect for:

• Search result highlighting in lists or menus

• Autocomplete suggestions with visual feedback

• Filtering through text collections while showing match context

• Making search matches more visible in document previews

The highlighting is case-insensitive and diacritic-insensitive by default, but you can customize the locale and font used for highlighting. This makes it a versatile tool for any search interface where you want to emphasize matching portions of text.

Get Started Today

I hope you find these extensions as useful in your projects as I do in mine. If you have ideas for improvements or additional extensions that could benefit the SwiftUI community, please feel free to contribute on GitHub:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

This is the third in a series of four articles exploring HandySwiftUI’s features. Check out the previous articles about New Types and View Modifiers if you haven’t already, and stay tuned for the final post about Styles!

In this article, I’ll share a selection of the view modifiers I’ve found most valuable in my daily development work across apps like TranslateKit, FreemiumKit, and CrossCraft. While HandySwiftUI contains many more utilities, these particular modifiers have proven their worth time and time again in real-world applications and could be helpful for your SwiftUI projects as well.

Smart Color Contrast

The foregroundStyle(_:minContrast:) modifier ensures text remains readable by automatically adjusting color contrast. This is useful for dynamic colors or system colors like .yellow that might have poor contrast in certain color schemes:

struct AdaptiveText: View {
    @State private var dynamicColor: Color = .yellow

    var body: some View {
        HStack {
            // Without contrast adjustment
            Text("Maybe hard to read")
                .foregroundStyle(dynamicColor)

            // With automatic contrast adjustment
            Text("Always readable")
                .foregroundStyle(dynamicColor, minContrast: 0.5)
        }
    }
}

This warning indicator in TranslateKit uses .yellow but ensures a good contrast even in light mode to be legible. It stays yellow in dark mode.

The minContrast parameter (ranging from 0 to 1) determines the minimum contrast ratio against either white (in light mode) or black (in dark mode) using the luminance value (perceived brightness). This ensures text stays readable regardless of the current color scheme.

Error-Handling Tasks

The throwingTask modifier streamlines async error handling in SwiftUI views. Unlike SwiftUI’s built-in .task modifier which requires manual do-catch blocks, throwingTask provides a dedicated error handler closure:

struct DataView: View {
    @State private var error: Error?

    var body: some View {
        ContentView()
            .throwingTask {
                try await loadData()
            } catchError: { error in
                self.error = error
            }
    }
}

The task behaves similarly to .task – starting when the view appears and canceling when it disappears. The catchError closure is optional, so you can omit it if you don’t need to handle errors, filling the gap the task modifier left open.

Platform-Specific Styling

A full set of platform modifiers enables precise control over multi-platform UI:

struct AdaptiveInterface: View {
    var body: some View {
        ContentView()
            // Add padding only on macOS
            .macOSOnlyPadding(.all, 20)
            // Platform-specific styles
            .macOSOnly { $0.frame(minWidth: 800) }
            .iOSOnly { $0.navigationViewStyle(.stack) }
    }
}

The example showcases modifiers for platform-specific styling:

• .macOSOnlyPadding adds padding only on macOS where containers like Form lack default padding

• .macOSOnlyFrame sets minimum window sizes needed on macOS

• Platform modifiers (.iOSOnly, .macOSOnly, .iOSExcluded, etc.) available for iOS, macOS, tvOS, visionOS, and watchOS allow selective application of view modifications on specific platforms

These modifiers help create platform-appropriate interfaces while keeping the code clean and maintainable.

Border with Corner Radius

SwiftUI doesn’t provide a straightforward way to add a border to a view with corner radius. The standard approach requires verbose overlay code that is hard to remember:

Text("Without HandySwiftUI")
    .padding()
    .overlay(
        RoundedRectangle(cornerRadius: 12)
            .strokeBorder(.blue, lineWidth: 2)
    )

HandySwiftUI simplifies this with a convenient border modifier:

Text("With HandySwiftUI")
    .padding()
    .roundedRectangleBorder(.blue, cornerRadius: 12, lineWidth: 2)

Badges in TranslateKit use this for rounded borders, for example.

Conditional Modifiers

A suite of modifiers for handling conditional view modifications cleanly:

struct DynamicContent: View {
    @State private var isEditMode = false
    @State private var accentColor: Color?

    var body: some View {
        ContentView()
            // Apply different modifiers based on condition
            .applyIf(isEditMode) {
                $0.overlay(EditingTools())
            } else: {
                $0.overlay(ViewingTools())
            }

            // Apply modifier only if optional exists
            .ifLet(accentColor) { view, color in
                view.tint(color)
            }
    }
}

The example demonstrates .applyIf which applies different view modifications based on a boolean condition, and .ifLet which works like Swift’s if let statement – providing non-optional access to optional values inside its closure. Both modifiers help reduce boilerplate code in SwiftUI views.

App Lifecycle Handling

Respond to app state changes elegantly:

struct MediaPlayerView: View {
    @StateObject private var player = VideoPlayer()

    var body: some View {
        PlayerContent(player: player)
            .onAppResignActive {
                // Pause playback when app goes to background
                player.pause()
            }
            .onAppBecomeActive {
                // Resume state when app becomes active
                player.checkPlaybackState()
            }
    }
}

These modifiers work together to create a more fluid and maintainable SwiftUI development experience, reducing boilerplate code while enhancing the quality and consistency of your user interface.

Delete Confirmation Dialogs

SwiftUI’s confirmation dialogs require repetitive boilerplate code for delete actions, especially when deleting items from a list:

struct TodoView: View {
    @State private var showDeleteConfirmation = false
    @State private var todos = ["Buy milk", "Walk dog"]
    @State private var todoToDelete: String?

    var body: some View {
        List {
            ForEach(todos, id: \.self) { todo in
                Text(todo)
                    .swipeActions {
                        Button("Delete", role: .destructive) {
                            todoToDelete = todo
                            showDeleteConfirmation = true
                        }
                    }
            }
        }
        .confirmationDialog("Are you sure?", isPresented: $showDeleteConfirmation) {
            Button("Delete", role: .destructive) {
                if let todo = todoToDelete {
                    todos.removeAll { $0 == todo }
                    todoToDelete = nil
                }
            }
            Button("Cancel", role: .cancel) {
                todoToDelete = nil
            }
        } message: {
            Text("This delete action cannot be undone. Continue?")
        }
    }
}

HandySwiftUI simplifies this with a dedicated modifier:

struct TodoView: View {
    @State private var todoToDelete: String?
    @State private var todos = ["Buy milk", "Walk dog"]

    var body: some View {
        List {
            ForEach(todos, id: \.self) { todo in
                Text(todo)
                    .swipeActions {
                        Button("Delete", role: .destructive) {
                            todoToDelete = todo
                        }
                    }
            }
        }
        .confirmDeleteDialog(item: $todoToDelete) { item in
            todos.removeAll { $0 == item }
        }
    }
}

Puzzle deletion in CrossCraft with a confirmation dialog to avoid accidental deletes.

The example shows how .confirmDeleteDialog handles the entire deletion flow – from confirmation to execution – with a single modifier. The dialog is automatically localized in ~40 languages and follows platform design guidelines. You can provide an optional message parameter in case you need to provide a different message. There’s also an overload that takes a boolean for situations where no list is involved.

Get Started Today

I hope you find these modifiers as useful in your projects as I do in mine. If you have ideas for improvements or additional modifiers that could benefit the SwiftUI community, please feel free to contribute on GitHub:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

This is the second in a series of four articles exploring HandySwiftUI’s features. Check out the previous article about New Types if you haven’t already, and stay tuned for upcoming posts about Extensions and Styles!

In this article, I’ll share a selection of the new types I’ve found most valuable in my daily development work across apps like TranslateKit, FreemiumKit, and CrossCraft. While HandySwiftUI contains many more utilities, these particular types have proven their worth time and time again in real-world applications and could be helpful for your SwiftUI projects as well.

Platform-Specific Values

HandySwiftUI provides an elegant way to handle platform-specific values:

struct AdaptiveView: View {
    enum TextStyle {
        case compact, regular, expanded
    }

    var body: some View {
        VStack {
            // Different number values per platform
            Text("Welcome")
                .padding(Platform.value(default: 20.0, phone: 12.0))

            // Different colors per platform
            Circle()
                .fill(Platform.value(default: .blue, mac: .indigo, pad: .purple, vision: .cyan))
        }
    }
}

Getting a similar look across platforms for a title in FreemiumKit via .font(Platform.value(default: .title2, phone: .headline)).

Platform.value works with any type - from simple numbers to colors, fonts, or your own custom types. Just provide a default and override specific platforms as needed. This can be enormously useful, especially given that it even has a specific case for iPad named pad, so you can even address phones and tablets separately.

This is by far my most-used HandySwiftUI helper saving me a ton of boilerplate #if checks. It’s simple but so powerful!

Readable Preview Detection

Provide fake data and simulate loading states during development:

Task {
   loadState = .inProgress

   if Xcode.isRunningForPreviews {
       // Simulate network delay in previews
       try await Task.sleep(for: .seconds(1))
       self.data = Data()
       loadState = .successful
   } else {
       do {
           self.data = try await loadFromAPI()
           loadState = .successful
       } catch {
           loadState = .failed(error: error.localizedDescription)
       }
   }
}

Xcode.isRunningForPreviews allows you to bypass actual network requests and instead provide instant or delayed fake responses in SwiftUI previews only, making it perfect for prototyping and UI development. It’s also useful to avoid consuming limited resources during development, such as API rate limits, analytics events that could distort statistics, or services that charge per request – just wrap these in a if !Xcode.isRunningForPreviews check.

Efficient Image Loading

CachedAsyncImage provides efficient image loading with built-in caching:

struct ProductView: View {
    let product: Product

    var body: some View {
        VStack {
            CachedAsyncImage(url: product.imageURL)
                .frame(width: 200, height: 200)
                .clipShape(RoundedRectangle(cornerRadius: 10))

            Text(product.name)
                .font(.headline)
        }
    }
}

Note that .resizable() and .aspectRatio(contentMode: .fill) are already applied to the Image view inside it.

Enhanced Selection Controls

Multiple sophisticated picker types for different use cases:

struct SettingsView: View {
    @State private var selectedMood: Mood?
    @State private var selectedColors: Set<Color> = []
    @State private var selectedEmoji: Emoji?

    var body: some View {
        Form {
            // Vertical option picker with icons
            VPicker("Select Mood", selection: $selectedMood)

            // Horizontal picker with custom styling
            HPicker("Rate your experience", selection: $selectedMood)

            // Multi-selection with platform-adaptive UI
            MultiSelector(
                label: { Text("Colors") },
                optionsTitle: "Select Colors",
                options: [.red, .blue, .green],
                selected: $selectedColors,
                optionToString: \.description
            )

            // Searchable grid picker for emoji or SF Symbol selection
            SearchableGridPicker(
                title: "Choose Emoji",
                options: Emoji.allCases,
                selection: $selectedEmoji
            )
        }
    }
}

HandySwiftUI includes Emoji and SFSymbol enums that contain common emoji and symbols. You can also create custom enums by conforming to SearchableOption and providing searchTerms for each case to power the search functionality.

Async State Management

Track async operations with type-safe state handling using ProgressState:

struct DocumentView: View {
    @State private var loadState: ProgressState<String> = .notStarted

    var body: some View {
        Group {
            switch loadState {
            case .notStarted:
                AsyncButton("Load Document") {
                    loadState = .inProgress
                    try await loadDocument()
                    loadState = .successful
                } catchError: { error in
                    loadState = .failed(error: error.localizedDescription)
                }

            case .inProgress:
                ProgressView("Loading document...")

            case .failed(let errorMessage):
                VStack {
                    Text("Failed to load document:")
                        .foregroundStyle(.secondary)
                    Text(errorMessage)
                        .foregroundStyle(.red)

                  AsyncButton("Try Again") {
                      loadState = .inProgress
                      try await loadDocument()
                      loadState = .successful
                  } catchError: { error in
                      loadState = .failed(error: error.localizedDescription)
                  }
                }

            case .successful:
                VStack {
                    DocumentContent()
                }
            }
        }
    }
}

The example demonstrates handling all states in a type-safe way:

• .notStarted shows the initial load button

• .inProgress displays a loading indicator

• .failed shows the error with a retry option

• .successful presents the loaded content

Bring NSOpenPanel to SwiftUI

Bridging native macOS file access into SwiftUI, particularly useful for handling security-scoped resources:

struct SecureFileLoader {
    @State private var apiKey = ""

    func loadKeyFile(at fileURL: URL) async {
        #if os(macOS)
        // On macOS, we need user consent to access the file
        let panel = OpenPanel(
            filesWithMessage: "Provide access to read key file",
            buttonTitle: "Allow Access",
            contentType: .data,
            initialDirectoryUrl: fileURL
        )
        guard let url = await panel.showAndAwaitSingleSelection() else { return }
        #else
        let url = fileURL
        #endif

        guard url.startAccessingSecurityScopedResource() else { return }
        defer { url.stopAccessingSecurityScopedResource() }

        do {
            apiKey = try String(contentsOf: url)
        } catch {
            print("Failed to load file: \(error.localizedDescription)")
        }
    }
}

The example taken right out of FreemiumKit demonstrates how OpenPanel simplifies handling security-scoped file access for dragged items on macOS while maintaining cross-platform compatibility.

Vertical Tab Navigation

An alternative to SwiftUI’s TabView that implements sidebar-style navigation commonly seen in macOS and iPadOS apps:

struct MainView: View {
    enum Tab: String, CaseIterable, Identifiable, CustomLabelConvertible {
        case documents, recents, settings

        var id: Self { self }
        var description: String {
            rawValue.capitalized
        }
        var symbolName: String {
            switch self {
            case .documents: "folder"
            case .recents: "clock"
            case .settings: "gear"
            }
        }
    }

    @State private var selectedTab: Tab = .documents

    var body: some View {
        SideTabView(
            selection: $selectedTab,
            bottomAlignedTabs: 1  // Places settings at the bottom
        ) { tab in
            switch tab {
            case .documents:
                DocumentList()
            case .recents:
                RecentsList()
            case .settings:
                SettingsView()
            }
        }
    }
}

SideTabView provides a vertical sidebar with icons and labels, optimized for larger screens with support for bottom-aligned tabs. The view automatically handles platform-specific styling and hover effects.

Get Started Today

I hope you find these types as useful in your projects as I do in mine. If you have ideas for improvements or additional types that could benefit the SwiftUI community, please feel free to contribute on GitHub:

github.comFlineDev / HandySwiftUIHandy SwiftUI features that didn’t make it into SwiftUI (yet)

This is the first in a series of four articles exploring HandySwiftUI’s features. Stay tuned for upcoming posts about View Modifiers, Extensions, and Styles!

In his article, Ole provides a straightforward approach to running Swift code in a Linux environment with a single command. All you need to do is to install the free Docker Desktop App on your Mac. But the command seemed quite lengthy and hard to remember, so I wanted to simplify things even further. I ended up with an approach where all I need to remember was swift-linux. Here’s how:

Simplifying the Docker Command

First, I decided to further simplify Ole’s command for brevity:

docker run --rm -it -v "$(pwd):/src" -w "/src" swift

Explanation of the Command (in case you’re interested):

• docker run: This command creates and starts a container.

• --rm: Automatically removes the container when it exits.

• -it: Runs the container in interactive mode with a terminal attached.

• -v "$(pwd):/src": Mounts the current directory ($(pwd)) to /src in the container, allowing you to access your Swift files.

• -w "/src": Sets the working directory in the container to /src.

• swift: Specifies the Swift Docker image to use.

Note that I also removed the --privileged option from Ole’s command for security reasons since it is rarely needed to test Swift packages.

Adding a Convenient Alias

To make running this command easier, I added an alias to my ~/.zshrc file (e.g. via touch ~/.zshrc). This is a configuration file for the Zsh shell, which is the default shell on macOS nowadays. Here’s how you can do it:

• Open the Terminal

• Edit the ~/.zshrc file You can use TextEdit, which is the pre-installed text editor on macOS. Simply run: open ~/.zshrc

• Add the alias Scroll to the bottom of the file and add the following line:

alias swift-linux='docker run --rm -it -v "$(pwd):/src" -w "/src" swift'

• Save and close the file

• Apply the changes Run the following command to reload your config file: source ~/.zshrc

Running Commands in a Linux Environment

Now that the alias is set up, you can easily test your Swift code in a Linux environment directly from your Mac. Simply navigate to your project directory in the terminal and run:

swift-linux

☕ On first run, the download of the Linux container will take some time.

This command will drop you into a Linux environment where you can execute swift build or swift test depending on your needs. Just type exit to return back to your Mac. This allows you to quickly see if everything works as expected and to catch any errors before deploying to your server.

And all you need to remember is swift-linux!

Why I Built LinksKit

After launching multiple apps across various Apple platforms, I noticed a pattern. Each app required similar link sections:

1. Legal links (privacy policy, terms of use)

2. Support links (FAQs, contact email)

3. App review deep link

4. Social media links

5. Cross-promotion for my other apps

Implementing these links became a time-consuming and repetitive process. And it was very different on the Mac, causing extra work for multi-platform apps. That’s when I realized the need for a reusable solution, and LinksKit was born.

Why Every New App Should Use LinksKit

1. Time-Saving: LinksKit provides a ready-to-use solution for common link requirements, allowing developers to focus on core app features.

2. Compliance: It ensures your app includes essential legal links, helping you meet App Store guidelines effortlessly.

3. Cross-Promotion: LinksKit makes it easy to showcase your other apps, potentially increasing your overall app portfolio’s visibility.

4. Networking Opportunities: The package allows you to promote apps from fellow developers, fostering a supportive community and potential cross-promotion partnerships.

5. Customization: While offering pre-built solutions, LinksKit also allows for full customization to fit your specific needs.

6. Platform Adaptability: It works seamlessly across iOS, macOS, and visionOS, adapting to each platform’s UI conventions.

How to Use LinksKit

Getting started with LinksKit is straightforward, but before we dive into the code, let’s discuss an important concept: the providerToken.

Understanding the providerToken

The providerToken is a crucial component in App Store marketing campaigns. It’s a unique identifier for your developer account that helps track the effectiveness of your marketing efforts. When users click on links with your providerToken, Apple can attribute those clicks to your campaigns, providing valuable insights into your app’s user acquisition. The word “campaign” makes it sound overly complicated, but it’s really just a parameter indicating where users are coming from.

How to Obtain Your providerToken

Finding your providerToken isn’t immediately obvious, but here’s how to do it:

1. Log in to App Store Connect

2. Navigate to Analytics > Acquisition > Campaigns

3. Click on “Create Campaign Link”

4. Enter any text in the form (you don’t need to actually create a campaign)

5. In the Campaign Link preview, look for the pt parameter - the value after pt= is your providerToken

Remember, this token is the same for all your apps, so you only need to look it up once.

Basic Configuration

Now that you understand the providerToken, let’s set up LinksKit in your app:

LinksKit.configure(
   providerToken: "123456",
   linkSections: [
      .helpLinks(appID: "123456789", supportEmail: "support@example.com"),
      .legalLinks(privacyURL: URL(string: "https://example.com/privacy")!)
   ]
)

This basic setup adds essential help and legal links to your app, including terms.

Comprehensive Example

Let’s explore a more comprehensive example that showcases all built-in features LinksKit offers with social links, and links to your apps and your friends apps:

// App Links
let ownApps = LinkSection(entries: [
   .link(.ownApp(id: "6502914189", name: "FreemiumKit", systemImage: "cart")),
   .link(.ownApp(id: "6480134993", name: "FreelanceKit", systemImage: "timer")),
   .link(.ownApp(id: "6472669260", name: "CrossCraft", systemImage: "puzzlepiece")),
   .link(.ownApp(id: "6477829138", name: "FocusBeats", systemImage: "music.note")),
])

let friendsApps = LinkSection(entries: [
   .link(.friendsApp(id: "1249686798", name: "NFC.cool Tools", systemImage: "tag", providerToken: "106913804")),
   .link(.friendsApp(id: "6503256642", name: "App Exhibit", systemImage: "square.grid.3x3.fill.square")),
])

// Configure LinksKit
LinksKit.configure(
   providerToken: "549314",
   linkSections: [
      .helpLinks(
         appID: "6476773066",
         faqURL: URL(string: "https://translatekit.app/#faq")!,
         supportEmail: "translatekit@fline.dev"
      ),
      .socialMenus(
         appLinks: .appSocialLinks(
            platforms: [.twitter, .mastodon(instance: "mastodon.social"), .threads],
            handle: "TranslateKit",
            handleOverrides: [.twitter: "TranslateKitApp"]
         ),
         developerLinks: .developerSocialLinks(
            platforms: [.twitter, .mastodon(instance: "iosdev.space"), .threads],
            handle: "Jeehut"
         )
      ),
      .appMenus(ownAppLinks: [ownApps], friendsAppLinks: [friendsApps]),
      .legalLinks(privacyURL: Constants.legalPrivacyPolicyURL)
   ]
)

The above configuration I took (and simplified) from my app TranslateKit:

1. Sets up help links with an FAQ and support email

2. Adds social media links for both the app and the developer

3. Creates a menu to promote my other apps

4. Includes a section to promote friends’ apps (great for networking!)

5. Ensures all necessary legal links are present

To use these configured links, simply add LinksView() to your settings screen:

Form {
   // Other settings...
   LinksView()
}

The result looks something like this on iOS:

On the Mac, it is more common to place links into the help menu. Do it like this:

WindowGroup {
   // your UI code
}
.commands {
   CommandGroup(replacing: .help) {
      LinksView()
         .labelStyle(.titleAndIcon)
   }
}

It will appear like this in the menu:

Custom Link Sections

While LinksKit provides pre-built sections, you can also create entirely custom sections using LinkSection. This flexibility allows you to add any type of link or nested menu structure you need.

Here’s an example of a custom section:

let customSection = LinkSection(
    title: "Custom Links",
    entries: [
        .link(Link(title: "Our Website", systemImage: "globe", url: URL(string: "https://www.example.com")!)),
        .menu(LinkMenu(
            title: "Social Media",
            systemImage: "network",
            linkSections: [
                LinkSection(entries: [
                    .link(Link.followUsOn(socialPlatform: .twitter, handle: "YourAppHandle")),
                    .link(Link.followUsOn(socialPlatform: .instagram, handle: "YourAppHandle"))
                ])
            ]
        ))
    ]
)

This example demonstrates how you can nest menus and create a hierarchy of links to suit your app’s needs.

Custom Label Styles

LinksKit offers flexibility not just in content, but also in presentation. You can easily customize the appearance of your links using SwiftUI’s labelStyle modifier. LinksKit provides three custom label styles to enhance the visual appeal of your links:

1. .titleAndTrailingIcon: Similar to the default .titleAndIcon style, but places the icon at the trailing end of the label.

2. .titleAndIconBadge(color:): Mimics Apple’s Settings app style by adding a colored background to the leading icons.

3. .titleAndTrailingIconBadge(color:): Combines the trailing icon placement with the colored background.

To apply these styles, simply add the labelStyle modifier to your LinksView:

LinksView()
    .labelStyle(.titleAndIconBadge(color: .blue))

This simple modification can significantly alter the look and feel of your links, allowing you to match your app’s design language or create a distinct visual hierarchy. Here’s a visual comparison of these styles:

By leveraging custom label styles, you can create a unique and polished look for your app’s link section, enhancing the overall user experience.

Conclusion

LinksKit is more than just a time-saving tool; it’s a comprehensive solution for managing app links, ensuring compliance, and fostering developer networking. By handling everything from legal requirements to cross-promotion, LinksKit allows you to focus on what truly matters – creating great apps.

Whether you’re a seasoned developer with multiple apps or just starting your first project, LinksKit can significantly streamline your development process. Give it a try in your next project and experience the benefits of simplified link management across all Apple platforms! I hope it helps.

github.comFlineDev / LinksKitSwiftUI convenience view to show common links in apps settings/help menu

I had several unique app ideas, but I found myself restricted by a lack of APIs that would make those concepts feasible. I would have released more apps if visionOS had delivered the tools necessary for creating the AR/VR experiences the device promised. This isn’t about wanting a more open platform like macOS; I understand the value of the security and simplicity in the iOS/iPadOS ecosystem. Yet, visionOS feels like just iPadOS with different input options. What’s missing are unique APIs designed to fully leverage the immersive experiences that the Vision Pro can offer.

Here are the five APIs that I believe could transform visionOS from a promising experiment into a platform truly worth developing for:

1. Magnetically Pinning Windows and Objects to Surfaces

Photo by Kristyna Squared.one / Unsplash

Imagine being able to pin windows or 3D objects to walls or furniture in a room—permanently. This feature would allow users to create persistent setups in their environment, enabling developers to toggle the pinning feature based on the context of their experience. For instance, my Posters app would finally make sense! More importantly, these pinned objects should remain in place even after restarting the system, similar to desktop environments or focus modes. This functionality should also extend across different users—when switching to guest mode, all pinned items should stay exactly where they were placed.

Currently, augmenting reality feels temporary on the Vision Pro due to the lack of this API, making it more of a VR-only device, which I don’t believe aligns with Apple’s vision for the platform. This limitation restricts the full potential of mixed-reality experiences, as users cannot rely on their digital objects staying put in their physical space. Therefore, the ability to magnetically pin windows and objects is the most crucial API needed to elevate the Vision Pro beyond a VR experience and realize its true mixed-reality potential.

2. Advanced Room Scanning with Editable 3D Models

Photo by Dynamic Wang / Unsplash

A hybrid API combining the power of RoomPlan and the 3D scanner available on iOS could revolutionize developers’ ability to create immersive content. While scanning a room is currently possible, it lacks the depth required for fully interactive spaces. The next step should allow developers to capture not only the dimensions but also the colors and textures, producing high-fidelity 3D models.

Why aren’t these scanning APIs available on the Apple Vision Pro? They require a LiDAR sensor, which the Vision Pro has. Creating them on the Vision Pro would be more comfortable, allowing users to see the results in 3D immediately. Ideally, Apple could also ship an app for developers to edit these environments directly within the Vision Pro using hand gestures. For instance, if I move a table and rescan the room, the system should recognize the change and treat the table as a movable object. Apple’s AI tools could fill in gaps with realistic textures and objects, making 3D environment creation more intuitive and reducing the need for complex CAD tools.

3. A Skeletal Recognition API for Fun AR Interactions

One of my favorite app ideas involved body part detection using Apple’s AR frameworks to bring a bit of The Sims into the real world. Imagine walking around and seeing a floating green diamond (like the Sims’ plumbob) above each person, allowing you to interact with them in unique and playful ways. To make this possible, a simple skeleton tracking API would be a game-changer, enabling developers to recognize body movements and gestures. Even a rough estimation of head position or arm movement could unlock features like interactive speech bubbles based on what someone is saying or feeling. Advanced APIs could detect facial expressions, creating opportunities for floating emotion icons or interaction suggestions akin to those in The Sims.

I understand that Apple doesn’t want to give full camera access—and honestly, I wouldn’t use the Vision Pro if they did. However, since the camera is already on, the system could share detected world information that respects user privacy while enabling these kinds of experiences. There’s still a lot of untapped potential that could enhance AR interactions significantly.

4. Interactive Spatial 360° and 180° Video Elements

Photo by Roger Ce / Unsplash

While the Vision Pro promises immersive video experiences, it’s currently impossible to integrate interactive buttons or objects into these spatial 180°/360° videos. Developers should be able to place clickable elements within space while inside a video—imagine offering interactive tours or guided experiences where users can click on objects to receive more information or switch between videos showing different times or perspectives.

This feature could also enable users to “time travel” within a location by seamlessly switching video recordings of the same place at different times. Right now, such interactions require painstakingly building 3D environments from scratch. A simple API for placing interactive elements within videos would vastly simplify the process and open up endless possibilities for interactive storytelling, educational tools, and more. Currently, a lot of effort is needed to come even close to such an experience, and includes building a custom video player inside RealityKit with different images for each eye. Hacks like this shouldn’t be needed.

5. Discovering the World: The Future of Apple Maps

Photo by Jezael Melgoza / Unsplash

One of the most surprising gaps in visionOS is the absence of a native Maps app optimized for the Vision Pro. While Look Around offers immersive street-level views on other devices, the Vision Pro could elevate this experience by placing users directly into 3D environments where they can interact with their surroundings in real-time. Apple’s AI technology, which turns photos into 3D scenes, could be used to convert Look Around’s existing imagery into interactive environments, unlocking new possibilities for immersive, location-based apps.

A proper Vision Pro Maps API could transform this experience entirely. Imagine walking (or rather beaming yourself) through a city, interacting with virtual objects tied to specific locations—whether for a game, educational purposes, or even an immersive travel planner. Developers could create experiences where users navigate through historical reconstructions, explore future city plans, or engage with dynamic content as they roam the streets.

The Key to Vision Pro’s Success

Photo by Razvan Chisu / Unsplash

These are the kinds of APIs that would not only keep developers like me invested in visionOS but also drive the creation of more immersive and compelling content. Right now, the Vision Pro lacks the killer apps that make users want to buy it, and without enough users, developers are hesitant to invest significant time in the platform. It’s a cycle that needs to be broken, and the solution is clear—Apple must make content creation as simple as possible for developers.

I’m not asking for an open system or far-fetched features—I’m asking for APIs that can unleash the real potential of the Vision Pro for developers and users alike. Without them, it’s hard to see how the platform will gain the momentum it needs. But if Apple introduces even just a few of these APIs, I’d be ready to jump back in and build apps that could push the boundaries of AR and VR, ultimately making the Vision Pro the breakthrough device it was meant to be.

I’ve been working on a Diabetes management app, which I’ve named Glu Sight, for about a year and half now. As the launch date approached, I found myself needing to cut down on features, tie up the loose ends, and finally prepare for release. Not everything has to be ready from Day One, I reminded myself. Some features can wait, but launching with a solid foundation was essential. This is where my decision-making process about handling in-app subscriptions and purchases came in.

RevenueCat: A Tough Start

As I approached the point of integrating in-app purchases, I started hearing tons of great things about RevenueCat. It seemed like the go-to solution for app developers, especially with its powerful features and reputation in the community. So, naturally, I considered using RevenueCat or the StoreKit 2 API directly. I reached out to others who had used RevenueCat, seeking tips on getting started.

However, what I soon discovered was that the initial setup process for RevenueCat was a lot more challenging than I expected. The procedures were complex, and to make matters worse, the documentation was lacking in areas where I needed guidance the most. Setting up the basics took time and felt like a struggle, especially when I was already under pressure to get my app ready for launch. Though I did manage to get through the setup, it wasn’t the most pleasant experience.

Discovering FreemiumKit: A Breath of Fresh Air

Then I stumbled upon FreemiumKit. After reading some positive reviews, I decided to give it a try. From the get-go, I noticed a stark difference. The setup with FreemiumKit was unbelievably simple. I was able to integrate it into my app much faster than any other solution I had tried. The SDK integration documentation was crystal clear—one read and I was good to go. It felt like everything just clicked.

FreemiumKit didn’t just make the setup process easy; it also came packed with smart automation and defaults that worked flawlessly out of the box with App Store Connect. And yet, it still provided the flexibility to tailor things to my specific needs. The pricing was also spot on, especially for an app developer like me who’s just starting out. The support from the developers? Stellar. I had a call with the developer, which turned out to be an amazing experience. He walked me through the process, and within 45 minutes, I had clarity on aspects of in-app purchases that even Apple’s documentation didn’t cover in detail.

The Impact on My Development Process

Switching to FreemiumKit had an incredible impact on my development process. I was able to clean up a significant amount of code, removing extra classes and unnecessary complexity that RevenueCat required. This cleanup wasn’t just about aesthetics—it made my app more efficient and easier to manage. All the RevenueCat stuff was gone, replaced with FreemiumKit, and I was loving it.

Built-in SDK components like PaidFeatureView and PaidStatusView were incredibly customizable, allowing me to focus on the user experience without worrying about the technical nitty-gritty. Instead of having to write an entire ViewModel for handling in-app purchases, I could use a one-liner from FreemiumKit. This freed me to concentrate on what mattered most: building a great app.

Moreover, FreemiumKit made the daunting aspects of StoreKit2 feel manageable. By playing around with FreemiumKit, I gained a better understanding of StoreKit2, which was a huge value add. It turned what seemed like an overwhelming task into something enjoyable and highly educational.

A Clear Path to Launch

Looking back, the major reason I hadn’t launched my app earlier was the overwhelming work required to integrate RevenueCat. I had started building the paywall and coding everything, but the complexity wore me down. I ended up procrastinating because it felt like too much work to revisit that part of the app.

FreemiumKit changed all of that. It allowed me to both focus on developing new features and integrate subscription management without anxiety. I even managed to make changes on App Store Connect to my trial periods, and FreemiumKit picked it all up seamlessly. The anxiety and “developer block” were gone, and I was back to feeling excited about hitting my launch day.

Final Thoughts

FreemiumKit has been a game-changer for me. Not only did it simplify my development process, but it also reinvigorated my passion for launching Glu Sight. The setup was smooth, the documentation was top-notch, and the support from the developers was incredible. For anyone facing similar challenges with in-app purchase management, I can’t recommend FreemiumKit enough. It’s helped me move past the obstacles that RevenueCat presented and focus on delivering a product I’m proud of.

As I inch closer to launching in September 2024, I’m excited and ready, thanks to FreemiumKit. I’ve made new friends along the way, learned a ton, and most importantly, I’m finally on the path to helping others manage their diabetes with ease.

Stay tuned for the launch!

👨‍💻 Don’t miss the launch post! Follow me on Threads and Mastodon.

💁 Enjoyed this article? Check out FreemiumKit! Simple in-app purchases with paywalls, A/B testing, and live push! Get it now or watch the video setup guide to see it in action.

Pleydia Organizer automatically matching Movies after drag & drop

Effortless Organization with Drag & Drop Simplicity

Organizing your media library has never been easier. With Pleydia Organizer, simply drag and drop your TV or movie files into the app, and it will automatically search The Movie Database (TMDb) to identify and match your files accurately. One more click, and all your files are renamed to tidy, standardized filenames without any weird characters or formatting issues.

Pleydia Organizer after renaming matched TV episode files

Why Choose Pleydia Organizer Over Other Tools?

Pleydia Organizer stands out from other renaming tools like FileBot:

• Super-Fast App Start: Pleydia Organizer launches almost instantly, while FileBot can take around 10 seconds on an M1 Pro Mac.

• Accurate Movie Matching: Pleydia Organizer excels in movie matching, especially when international release years differ from those in your country.

• Precise TV Episode Matching: The app handles edge cases in TV show season grouping better, such as with Animes like One Piece where episodes are released each week, which FileBot struggles with.

• Persistent TV Show Choices: Pleydia Organizer remembers your season grouping choices for TV shows, eliminating the need for repetitive selections every time you use the app.

• Free Renaming Options: You can rename one file at a time for free, making it accessible for light users. FileBot requires a purchase even for a single file.

• Affordable Multi-File Support: If you need multi-file support, it’s half the price of FileBot, making it an economical choice for managing larger libraries.

• Drag & Drop Simplicity: Rather than you having to learn the app and having to click a lot of buttons, Pleydia Organizer is super easy to use.

See how easy it is in in action with this GIF:

Just drag & drop your files into Pleydia Organizer, and it matches automatically.

If you have your own Plex, Kodi, Jellyfin, or Infuse media server, Pleydia Organizer is definitely worth a try. Download it safely from the Mac App Store:

Pleydia Organizer: File Rename

I appreciate any feedback, so please let me know if you run into any issues!

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

Embedding Videos

Adding a video to your documentation is a single directive:

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

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

Tabbed Content with TabNavigator

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

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

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

Practical Advice

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

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

A user expressing their feelings with a negative App Store review.

It’s really tough to withstand the temptation to just follow their request to lower the price. And I haven’t always been able to withstand it as you can see here:

A user on Reddit complaining about the price of an up-front paid app.

I’m a human after all and I want people to like what I do. But I also have to make money as an Indie developer or I can’t continue improving the app. So, it’s even in the interest of users that I put a fair price on it, not just mine. But what is fair?

“Fair” Pricing

One could look at this from many different perspectives.

From an economical point of view, my goal should be to maximize my earnings. If you’re looking for an article about different strategies to do that, you’re better off reading an article like this one. To me, profit is just a means to keep me motivated to continue building apps. It’s not the goal. The user experience is all that matters. And solving problems. A fair price is part of a good UX to me.

A pure developer point of view could be to price an app based on the effort it required to make it. Sounds fair, right? But it doesn’t work in a free market. And for good reason! What if you’ve built something super complex but totally irrelevant? Why should anyone pay a high price for that? Would you?

That brings me to how I always tend to choose my initial prices. What would I pay if this app was built by someone else and I just wanted to use it? Because I exclusively build apps that I need myself, I’m also a customer! So it’s like a one-person customer research my initial pricing is based on. But is this a good idea?

At least it’s not if I want to avoid bad ratings like the 2-star one above. Why? Because I’m not only a customer, but I also know exactly what my app offers. But users don’t. They will only know what I’ve presented to them on the App Store page and in my Onboarding. And probably not even all of what I present there.

The User’s Perspective

So, what feels fair to a user is very much dependent on how the user perceives the value of an app. For example, the above bad rating I received for TranslateKit. My preview video on the App Store page communicates the ease of use of the drag & drop workflow to translate apps. But the user complained because they had to register for a 3rd-party translation service to use the marketed features.

Of course, I mention that requirement in my App Store description. But who reads descriptions? Nobody! I could do what the user requested and provide built-in support for those translation services. But then I would have to pay for those services and add that price on top. And I would additionally have to host a proxy server to make sure my API keys don’t get exposed, adding even more costs.

That’s not good for most of my other customers though. After all, each translation service I support has a huge free tier that is more than enough to localize any size app to many languages! The only problem is the extra hurdle of registering a free account & getting the API keys. I try to help by linking to the right pages:

All 3rd-party services expanded linking to registration & API key docs.

That hurdle probably caused frustration on the users end who expected to simply “drag & drop” their String Catalog after downloading the app like shown in the preview. But they couldn’t do it right away. And as a consequence, they expressed their feelings by criticizing the only thing they have actually knowledge about: The pricing. Because you can see it by clicking on “Upgrade” on the main window.

The top section of the main window in TranslateKit.

Addressing the Complaint

The easiest thing I could do to prevent users complaining about the pricing would be to hide the information about the paid tier until the user exceeds the Free limit. But I consider this a dark pattern, so I wouldn’t ever do that. And even if I did, they would probably just complain about something else, it doesn’t solve the issue.

Much more useful to prevent bad ratings would be if I provided more guidance and help to create those accounts, including maybe step-by-step guides or videos. But that’s just a matter of lowering the effort, it could still be too much for some!

The analysis above leads me to think that it’s actually not the pricing of my app that lead to the bad rating, but my inability to communicate its value. Users can’t know that my app not just connects String Catalogs with translation services, but that it also does all kinds of smart stuff behind the scenes to ensure the resulting translations are accurate. A simple way to communicate this is with an example:

New window shown on first app start to communicate app’s value.

By showing the different stages a translation can walk through on app start, I’m explaining to my users what additional value my app brings on top of what’s already obvious from the Store page. Additionally, I should probably make these stages & adjustments clear in my apps translation UI, which I might do in a future update. But it wouldn’t have helped to address the bad rating anyway since you would only ever see the translation UI after setting up at least one API key.

Conclusion

Pricing is indeed hard and I’m still not 100% sure what I’m doing is right. And I probably never will. But at least I don’t feel bad about my price as my app saves many hours of time and costs much less than the average hourly rate. And I know people subscribe to the app from the numbers on App Store Connect. Each purchased subscription is someone telling me “the price is not too high”.

Just because a customer complained about the price, it doesn’t mean it’s wrong. The most depressing reviews can sometimes provide the most useful insights into the flaws in your apps Onboarding. Don’t ignore them outright. Try to understand where your users might be coming from first. And communicate your app’s value!

Own an Apple Vision Pro? Enhance your demo experience! Navigating friends through its features can be tricky & it’s easy to miss out on showing some of its best aspects. But no more!

Guided Guest Mode is designed to offer your friends & family a smooth introduction to the future of spatial computing. Use the built-in guides inspired by Apples own demos to showcase the best experiences or create your own guides. A huge time-saver!

A short Demo video of Guided Guest Mode.

Get it now:

Guided Guest Mode

Download Press Kit

FocusBeats: Pomodoro + Music

Also available on iPhone, iPad, and Mac

You like to work with background music? And you want to improve your productivity with the Pomodoro (25m / 5m) technique? Then this is the app you’ve been waiting for: It provides selected themes for music like movie soundtracks or classical music. And automatically plays & pauses the music during focus & break periods. Discover focus music for every mood!

To auto-play music, this app requires an Apple Music subscription. If you don’t have one, it’s serves as one of the best Pomodoro timers out there. It’s free to use for the default 25/5 Pomodoro system and select music themes.

A short Demo video of FocusBeats on Vision Pro.

Try it Free:

FocusBeats: Pomodoro + Music

Download Press Kit

FreelanceKit offers an affordable, easy-to-use time tracking solution that feels right at home on your Apple devices. Built with SwiftUI, this app is intuitively designed to ensure a smooth, native experience on all Apple platforms.

FreelanceKit on Mac.

Key Features:

• Seamless Synchronization: Start tracking on a Mac and stop on your iPhone. iCloud sync ensures your data is available across all devices.

• Mini Timer Mode: A distraction-free timer that makes pausing and resuming work effortless without taking too much of your screen.

• Multilingual Support: Available in over 30 languages, making it universally accessible.

• Live Earnings Tracking: Enter your hourly rate to see your earnings update in real-time to stay motivated!

• CSV Export: Export your tracked time to open in other tools with all the data you would expect. You can even customize the date format & separator!

FreelanceKit on Apple Vision.

Perfect for Everyone:

Whether you’re freelancing, studying, or managing projects, FreelanceKit is tailored to anyone looking to take control of their time. Its simplicity and cross-device compatibility mean you can focus on what matters most without losing track of time. Download FreelanceKit now to unlock your productivity potential. Start managing your projects and time more efficiently!

Get it now:

FreelanceKit: Time Tracking

Download FreelanceKit now to unlock your productivity potential. Start managing your projects and time more efficiently!

Some of these ideas I filed a radar long ago. But more often than not, taking the time to reflect on the things I’m missing most brings up new things that I don’t come across in day-to-day work. So you might find a few obvious things in this list, but I’m sure I also have things you never thought about. I’d love to hear what you think, make sure to comment on socials and mention my handle @Jeehut.

ℹ️ There are still 3 wishes from my last years’ article that were not shipped yet, and I still think we need them:

1. Easy App Modularization in Xcode without the hassle

2. Pie Charts are here, but Spider Charts are still missing!

3. Streamer Mode in Xcode to hide sensitive code in calls/recordings

#1 – A WeatherKit-like API for Apple Sports

I was surprised when Apple introduced WeatherKit in 2022. It was the first system framework (I know of) that was not free for developers to use – but it still came with 500,000 calls per month for free. This was generous enough for Indie developers to write interesting new apps based on it. Apple had basically extracted the data portion of a system app and made it available to developers. And not just that, they also made it affordable enough for bootstrapped Indies!

The new Apple Sports app.

The introduction of the Apple Sports app in the US made me think: What if Apple did the same with the data of that app? I had multiple app ideas over the years that I prototyped but couldn’t release because of the lack of an affordable Live Sports Data API. Their pricing is targeted toward large corporations (like many APIs are). But given that the best way to experience a sports event nowadays is by using the Vision Pro, I think it would make a lot of sense for Apple to make it as easy as possible for Indies to explore new experiences in sports events.

I wish for a new “SportsKit” API with a generous free tier like WeatherKit!

#2 – Add .zoom modifier to ScrollView in SwiftUI

One of the first features requested for the playing screen of my crossword puzzle app CrossCraft was to zoom in and out to get a better overview of the related characters. But when I typed .zoom to add the related modifier to my ScrollView in SwiftUI, I was shocked to see that it’s not available! 😱

While there are workarounds using a custom MagnifyGesture, a GeometryReader based on the .scaleEffect modifier with custom @State modifiers, it only works for limited use cases such as zooming into images. But my view is a ScrollView which behaves very different compared to a regular view. I’ve tried multiple approaches, but couldn’t get it to work the way one would expect. And even if I did, zooming the contents of a scroll view is such a common use case that it should really be built-in to ScrollView and easy to use without all the hassle.

I wish for a .zoom(scale:offset:) modifier for ScrollView in SwiftUI!

#3 – Fix SwiftData limitations on CloudKit

Paul Hudson has put it perfectly in his great SwiftData + CloudKit article:

SwiftData with iCloud has a requirement that local SwiftData does not: all properties must be optional or have default values, and all relationships must be optional. The first of those is a small annoyance, but the second is a much bigger annoyance – it can be quite disruptive for your code.

There’s really not much to add to this other than that I had to write a lot of computed properties in all of my models to map Optionals to non-Optionals. It’s safe, my apps aren’t crashing. So why isn’t it built-in to some SwiftData macro?

I wish for non-Optional types in SwiftData models to work with CloudKit.

#4 – Persistent Windows & Volumes in VisionOS

I have so many app ideas for VisionOS that only make sense when the position of windows or volumes could be persisted across app restarts and even system restarts or updates. For example, I released an app called Posters where you can decorate your walls with auto-updating interactive film posters – but when you restart the device they’re gone. Augmenting reality is only temporary.

Decorating walls with Posters in VisionOS.

I understand that Apple doesn’t want to give us full ARKit access in Shared Space. It’s not possible to have good performance with all apps using ARKit at the same time. I’m not wishing for that. But the system already tracks window positions.

I wish for a (user-approved) option to persists window/volume positions.

#5 – Modal Text Input on tvOS (like Playstation)

On iOS, iPadOS, and visionOS we get QWERTY keyboards because they are known, fast, and easy to type. On tvOS of all platforms, they decided to put the keys into a line. As a consequence, getting to a specific key takes much longer than it would if there was just a QWERTY-like grid system. Also, the text input needs the full width of the TV screen and is placed at the top, making it the main focus. Why all this? Just look at this much better modal keyboard UI from 2013 by Sony:

Virtual Keyboard on PS4.

The lack of something like this makes experiences impossible where the keyboard is just an accessory to an otherwise more interesting view. Because it’s missing, I ditched my initial plans to bring CrossCraft to tvOS as well. I would have loved to generate & solve crossword puzzles on the TV. It could make for a fun family experience. But with the current keyboard, it’s a UX nightmare!

I wish for a narrower, QWERTY-like accessory keyboard input on tvOS.

#6 – Make String Catalog editor more useful

Yes, String Catalogs are new. So it is to be expected that they’re not fully evolved yet. But even some of the most basic things are broken right now. Right-clicking an entry and choosing something like “Mark as Reviewed” is possible. But multi-selecting to mark multiple at once? Isn’t. Adding a new language with a plus button at the bottom is possible. But removing one with the minus button? Isn’t.

Apart from the broken basics, I have one more feature request that makes so much sense: The UI marks parameters in blue already, so there is detection. But when one is missing in another language, there’s no warning. There should be!

I wish for the String Catalog editor UI in Xcode to become more useful.

💁‍♂️ UPDATE: I implemented these improvements myself! 😍 I basically rebuilt Xcode’s String Catalog Editor and added it as a completely free feature to my app TranslateKit. Check it out! 🌐 👍

#7 – New “Create LLM” app like “Create ML”

Have you ever tried Create ML? It’s a developer tool Apple introduced far back in 2019 which I feel gets overlooked by many developers. It’s an AI tool that solves the problem of classification quite well. Just look at all the available options:

Create ML Project Templates

But we all know that generative AI based on LLMs is the new trend. And there’s even proof that Apple is actively working on something they will ship in the near future. Assuming that they will be able to publish something this year to consumers, what I want as a developer is a tool akin to Create ML but for LLMs. Imagine you could customize Apple’s Core LLM model with your specific domain data and maybe even with personal user data all stored on-device. This would allow for amazing new app experiences and as developers, we would get it for free!

I wish for an easy way to create domain-specific & personalized LLMs.

#8 – Improved Source Control UX in Xcode

Year over year the integration of Git into Xcode is getting better and better. Last year, it reached a point that I decided to switch to Xcode as my default Git UI. Previously I was using Git-Fork, but full integration into Xcode is unbeatable!

I am missing a few things though. Firstly, although Xcode has a code diffing view, there’s no way to see the diffs of past commits, only for “Uncommited changes”. Secondly, the diffing view itself has really weird color choices that make it hard to understand what code was removed and what was added. It’s common that tools use red and green for clear meanings which I would prefer a lot over the current. Thirdly, to commit and push in one step, you have to press the arrow-down icon to the right of the “Commit” button and choose “Commit and Push…”. I would prefer a checkbox that keeps its state so I don’t have to do multiple clicks each time. And lastly, sometimes I type a commit message and while reviewing the changes I find something that’s off. Then I switch to the file, make some adjustments and when I return to the diffing view, my commit message is gone! It should still be there.

I wish for improved source control UX & proper Git functionality in Xcode.

#9 – Make SwiftUI Previews work Reliably

This has been an annoyance from the very first days of SwiftUI. Designing in SwiftUI could be so useful and fast. If only the previews worked. But 90% of the time the previews are not working for me. And I’ve tried the common solutions already. Sometimes they helped, sometimes they didn’t. But it’s annoying to have to do workarounds just to get SwiftUI previews working.

I wish that SwiftUI previews work every time an app builds for Simulator.

#10 – Screenshots for SwiftUI Previews

Creating App Store screenshots is hard. You can do them manually on 2-3 devices in one language. But as soon as you want to localize them, the effort becomes unbearable. If I had to guess, I would say that 99% of the screenshots you can see on the App Store are outdated. But it doesn’t have to be this way.

We need some help on Apple’s end to fix it. And I’m not talking about UI Tests. They are slow. They are extra effort. They are unreliable. I don’t write UI Tests nowadays anymore, because we have SwiftUI previews. Well, I wrote above that they are not reliable, that’s true. But what if they improved that? The #Preview macro makes it really easy to create multiple previews in a single view. And it’s relatively easy to pass in some state upon initialization to your views.

I wish for an API to create localized screenshots using SwiftUI previews.

Conclusion

These are my top 10 wishes for WWDC24. Do you agree? What did I miss?

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

Using AppTransaction to Check Purchase History

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

import StoreKit

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

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

Important Details

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

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

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

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

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

How It Works

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

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

Why It Beats Cmd-Click

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

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

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

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

But it’s been more than 2 years since I made a new release. Of course, I was adding some functionality over time to the main branch so I could easily reuse them across my apps. But undocumented features that aren’t part of a new release can be considered “internal” even if the APIs themselves are marked public.

So I took the time in the last few days to clean up all the code, making sure everything is consistent with the latest additions to Swift, removing unused code, adding @available attributes for renames (so Xcode can provide fix-its), and documenting a bunch of new APIs. I even designed an entirely new logo!

Additionally, I decided to embrace Swift-DocC which means that I could shrink my README file to the bare minimum and instead host my documentation on the Swift Package Index site. With some help of ChatGPT I could elaborate even on my existing documentation, leading to the best documented library I ever released!

I’ll be writing a dedicated post about the details of the migration later. But because I’ve never written about HandySwift before, let me explain some of the conveniences you get when using it. I recommend adding it to every project. It has no dependencies, is lightweight itself, supports all platforms (including Linux & visionOS) and the platform support goes back to iOS 12. A no-brainer IMO. 💯

Extensions

Some highlights of the >100 functions & properties added to existing types, each with a practical use case directly from one of my apps:

Safe Index Access

In FocusBeats I’m accessing an array of music tracks using an index. With subscript(safe:) I avoid out of bounds crashes:

var nextEntry: ApplicationMusicPlayer.Queue.Entry? {
   guard let nextEntry = playerQueue.entries[safe: currentEntryIndex + 1] else { return nil }
   return nextEntry
}

You can use it on every type that conforms to Collection including Array, Dictionary, and String. Instead of calling the subscript array[index] which returns a non-Optional but crashes when the index is out of bounds, use the safer array[safe: index] which returns nil instead of crashing in those cases.

Blank Strings vs Empty Strings

A common issue with text fields that are required to be non-empty is that users accidentally type a whitespace or newline character and don’t recognize it. If the validation code just checks for .isEmpty the problem will go unnoticed. That’s why in TranslateKit when users enter an API key I make sure to first strip away any newlines and whitespaces from the beginning & end of the String before doing the .isEmpty check. And because this is something I do very often in many places, I wrote a helper:

Image(systemName: self.deepLAuthKey.isBlank ? "xmark.circle" : "checkmark.circle")
   .foregroundStyle(self.deepLAuthKey.isBlank ? .red : .green)

Just use isBlank instead of isEmpty to get the same behavior!

Readable Time Intervals

Whenever I used an API that expects a TimeInterval (which is just a typealias for Double), I missed the unit which lead to less readable code because you have to actively remember that the unit is “seconds”. Also, when I needed a different unit like minutes or hours, I had to do the calculation manually. Not with HandySwift!

Intead of passing a plain Double value like 60 * 5, you can just pass .minutes(5). For example in TranslateKit to preview the view when a user unsubscribed I use this:

#Preview("Expiring") {
   ContentView(
      hasPremiumAccess: true, 
      premiumExpiresAt: Date.now.addingTimeInterval(.days(3))
   )
}

You can even chain multiple units with a + sign to create a day in time like “09:41 AM”:

let startOfDay = Calendar.current.startOfDay(for: Date.now)
let iPhoneRevealedAt = startOfDay.addingTimeInterval(.hours(9) + .minutes(41))

Note that this API design is in line with Duration and DispatchTimeInterval which both already support things like .milliseconds(250). But they stop at the seconds level, they don’t go higher. HandySwift adds minutes, hours, days, and even weeks for those types, too. So you can write something like this:

try await Task.sleep(for: .minutes(5))

⚠️ Advancing time by intervals does not take into account complexities like daylight saving time. Use a Calendar for that.

Calculate Averages

In the crossword generation algorithm within CrossCraft I have a health function on every iteration that calculates the overall quality of the puzzle. Two different aspects are taken into consideration:

/// A value between 0 and 1.
func calculateQuality() -> Double {
   let fieldCoverage = Double(solutionBoard.fields) / Double(maxFillableFields)
   let intersectionsCoverage = Double(solutionBoard.intersections) / Double(maxIntersections)
   return [fieldCoverage, intersectionsCoverage].average()
}

In previous versions I played around with different weights, for example giving intersections double the weight compared to field coverage. I could still achieve this using average() like this in the last line:

return [fieldCoverage, intersectionsCoverage, intersectionsCoverage].average()

Round Floating-Point Numbers

When solving a puzzle in CrossCraft you can see your current progress at the top of the screen. I use the built-in percent formatter (.formatted(.percent)) for numerics, but it requires a Double with a value between 0 and 1 (1 = 100%). Passing an Int like 12 unexpectedly renders as 0%, so I can’t simply do this:

Int(fractionCompleted * 100).formatted(.percent)  // => "0%" until "100%"

And just doing fractionCompleted.formatted(.percent) results in sometimes very long text such as "0.1428571429".

Instead, I make use of rounded(fractionDigits:rule:) to round the Double to 2 significant digits like so:

Text(fractionCompleted.rounded(fractionDigits: 2).formatted(.percent))

ℹ️ There’s also a mutating round(fractionDigits:rule:) function if you want to change a variable in-place.

Symmetric Data Cryptography

Before uploading a crossword puzzle in CrossCraft I make sure to encrypt it so tech-savvy people can’t easily sniff the answers from the JSON like so:

func upload(puzzle: Puzzle) async throws {
   let key = SymmetricKey(base64Encoded: "<base-64 encoded secret>")!
   let plainData = try JSONEncoder().encode(puzzle)
   let encryptedData = try plainData.encrypted(key: key)
   
   // upload logic
}

Note that the above code makes use of two extensions, first init(base64Encoded:) is used to initialize the key, then encrypted(key:) encrypts the data using safe CryptoKit APIs internally you don’t need to deal with.

When another user downloads the same puzzle, I decrypt it with decrypted(key:) like so:

func downloadPuzzle(from url: URL) async throws -> Puzzle {
   let encryptedData = // download logic
   
   let key = SymmetricKey(base64Encoded: "<base-64 encoded secret>")!
   let plainData = try encryptedPuzzleData.decrypted(key: symmetricKey)
   return try JSONDecoder().decode(Puzzle.self, from: plainData)
}

ℹ️ HandySwift also conveniently ships with encrypted(key:) and decrypted(key:) functions for String which return a base-64 encoded String representation of the encrypted data. Use it when you’re dealing with String APIs.

New Types

Besides extending existing types, HandySwift also introduces 7 new types and 2 global functions. Here are the ones I use in nearly every single app:

Gregorian Day & Time

You want to construct a Date from year, month, and day? Easy:

GregorianDay(year: 1960, month: 11, day: 01).startOfDay() // => Date 

You have a Date and want to store just the day part of the date, not the time? Just use GregorianDay in your model:

struct User {
   let birthday: GregorianDay
}


let selectedDate = // coming from DatePicker
let timCook = User(birthday: GregorianDay(date: selectedDate))
print(timCook.birthday.iso8601Formatted)  // => "1960-11-01"

You just want today’s date without time?

GregorianDay.today

Works also with .yesterday and .tomorrow. For more, just call:

let todayNextWeek = GregorianDay.today.advanced(by: 7)

ℹ️ GregorianDay conforms to all the protocols you would expect, such as Codable, Hashable, and Comparable. For encoding/decoding, it uses the ISO format as in “2014-07-13”.

GregorianTimeOfDay is the counterpart:

let iPhoneAnnounceTime = GregorianTimeOfDay(hour: 09, minute: 41)
let anHourFromNow = GregorianTimeOfDay.now.advanced(by: .hours(1))


let date = iPhoneAnnounceTime.date(day: GregorianDay.today)  // => Date

Delay & Debounce

Have you ever wanted to delay some code and found this API annoying to remember & type out?

DispatchQueue.main.asyncAfter(deadline: DispatchTime.now() + .milliseconds(250)) {
   // your code
}

HandySwift introduces a shorter version that’s easier to remember:

delay(by: .milliseconds(250)) {
   // your code
}

It also supports different Quality of Service classes like DispatchQueue (default is main queue):

delay(by: .milliseconds(250), qosClass: .background) {
   // your code
}

While delaying is great for one-off tasks, sometimes there’s fast input that causes performance or scalability issues. For example, a user might type fast in a search field. It’s common practice to delay updating the search results and additionally cancelling any older inputs once the user makes a new one. This practice is called “Debouncing”. And it’s easy with HandySwift:

@State private var searchText = ""
let debouncer = Debouncer()


var body: some View {
    List(filteredItems) { item in
        Text(item.title)
    }
    .searchable(text: self.$searchText)
    .onChange(of: self.searchText) { newValue in
        self.debouncer.delay(for: .milliseconds(500)) {
            // Perform search operation with the updated search text after 500 milliseconds of user inactivity
            self.performSearch(with: newValue)
        }
    }
    .onDisappear {
        debouncer.cancelAll()
    }
}

Note that the Debouncer was stored in a property so cancelAll() could be called on disappear for cleanup. But the delay(for:id:operation:) is where the magic happens – and you don’t have to deal with the details!

So the question was if I would be able to pull it off in this short amount of time. But luckily it turned out to be easy enough, so my app was ready on Day 1! 👇

The official email from Apple, thanking Day 1 app developers.

The following are all of my learnings that could help you migrate your apps, too!

3rd-Party Frameworks

After adding the “Apple Vision” destination to my project, the first thing I did was selecting the “Apple Vision Pro” simulator and starting a build.

As I was expecting, the build failed. Because not all frameworks support the visionOS platform yet. But adding basic support was easy. Here are the 4 steps:

Step 2: Adjusting the Package.swift file is the most important step.

1. Fork the dependency, remove it from your project & add your fork with the main branch instead.

2. Open the Package.swift file in the fork, bump the Swift tools version at the top of the file to 5.9 and add .visionOS(.v1) to the supported platforms array.

3. Search for any mentions of #if os(iOS) and change them to #if os(iOS) || os(visionOS) to avoid building the macOS path, preferring the iOS path.

4. Select the “Apple Vision Pro” simulator and build the project to confirm.

If you get an error due to missing APIs, make sure to add #if !os(visionOS) checks at the right places. Most APIs should be available though, as visionOS is a fork of iPadOS as Apple officially confirmed. If a feature is not there, it will either come soon or it doesn’t make sense on the platform anyway.

In my case, only for my own ReviewKit library I had to disable some code around SKReviewController which isn’t available on visionOS yet. So my library effectively does nothing when building for visionOS, but my iOS & Mac apps will continue asking users to the rate the app. I could have fixed that with a custom UI, but I decided to wait for this years WWDC first, hoping we’ll get it there already.

Don’t forget to post a Pull Request to the original repo if you forked it, so others in the community can profit from your fix as well. The more people do this, the less dependencies you have to add platform support yourself. 💪

Testing my App in the Simulator

After fixing all the dependencies, I built my app and it succeeded! 🥳

Unfortunately, I was not done yet. First off, while the app was launching, I saw that there was no App Icon shown although I have one in my project. Also, after it launched, I immediately discovered a bunch of other issues. Here’s an overview:

• The App Icon was missing

• When moving the cursor (= gaze), the Hover Shape was off in some places

• The Layout & Sizes of many windows, modals, and my UI elements were off

• My Accent Color did not have a legible contrast to the glassy background

All of these points will affect every single app migrating to visionOS. For me, small adjustments helped fix them though. Let me share my learnings one by one.

App Icon

It turns out, visionOS has its own App Icon style. They are circular like on watchOS, but they consist of multiple layers to create a sense of depth, like on tvOS. You add a visionOS app icon by pressing the + button and choosing “visionOS App Icon”. Then, you need to provide at least a “Front” and “Back” layer image of size 1024 x 1024. The “Middle” layer is optional.

In my case, my app icon already consisted of a background layer and an icon in the foreground, so it was not a big deal to export them separately. I just had to remove the “Middle” layer in the right pane. But because I had a shadow applied to my foreground icon, and the Human Interface Guidelines state that we should “avoid using soft or feathered edges” for the non-background layers, I had to remove the shadow. The system will add a slight shadow on hover automatically.

Speaking of hover, Xcode provides a preview of how your app icon will look like at the top, and when you hover your mouse over it, it simulates the 3D hover effect when users will look at your app icon on the Vision Pro, which is really handy!

Xcodes preview of your app icon.

Hover Effects

In visionOS, one of the things that are easy to miss in the Simulator but extremely important when actually using the device are proper hover effects. As you select elements on the device with your eyes, it is important your app gives feedback about which element is currently selected. This works great out of the box with Stringly-based control APIs in SwiftUI, such as Button("Click me") { ... }.

But as soon as you provide a custom label parameter to a button, or even have your entirely custom controls, you will need to provide the exact shape of your control to the system. For example, I’m using a custom control I call HPicker which I use instead of the default drop-down Picker when I have only 2-4 options to choose from. It ended up looking like this when hovering over an option:

My custom HPicker view without any Hover Effect adjustments.

Adjusting it to follow the shape of the options was easy enough:

Button {
   // ...
} label: {
   Label(option.description, systemImage: option.symbolSystemName)
      // ...
      .clipShape(.rect(cornerRadius: 12.5))
      #if !os(macOS)
      .contentShape(.hoverEffect, .rect(cornerRadius: 12.5))
      .hoverEffect()
      #endif
}

Simplified version of the buttons inside my HPicker component.

The .contentShape and .hoverEffect modifiers are what I added for a proper hover effect. Replace .rect(cornerRadius: 12.5) with whatever the shape of your custom control is. Note that I wrapped them in a #if !os(macOS) check as my app supports macOS, but .hoverEffect is not available on it. Also, note that placing these modifiers outside the Button did not work for me, they have to be placed inside the label definition to work properly.

In some situations, you might notice that you have a hover effect where you don’t expect one. For me, this was the case when I provided a Button inside another view that already is recognized as a control, like this DisclosureGroup:

The entire “Show Clues” row is a button, but the button inside is another button.

You can turn off the hover effect by just adding the .hoverEffectDisabled() modifier. In my case above, the inner button was only added for macOS (because a DisclosureGroup doesn’t toggle when pressing the label on that platform). So my fix was to only use a Button inside on macOS and to use a simple Label else.

Making all controls have a proper hover effect was actually the most time-consuming task of the migration and took ~40 minutes. It would probably have been much faster if SwiftUI previews worked in my project, but for some reason they wouldn’t build for me, and when I tried, my Mac would start hanging. 🤷‍♂️

Layout System

While visionOS is based on iPadOS and therefore renders things like Form views similar to the iPad, it’s important to understand that there’s actually a key difference when it comes to the layout system compared to iOS/iPadOS:

A person’s field of view inside the Apple Vision Pro. Source: HIG

On Apple Vision apps are opened in an infinite canvas, there’s no fixed screen width or height your views can derive their size from. This is a key difference you need to understand. If you have developed apps for macOS, you will already be familiar with this difference. In many ways, the layout system is much closer to that of macOS where monitors can also have differing sizes and windows are very rarely opened using the full-screen space like they do on iOS & iPadOS.

So, if your app already supports macOS, you can simply opt for the #if os(macOS) branches that you will most probably have many of already when it comes to sizing or window management. Just replace with #if os(macOS) || os(visionOS).

The main difference even to macOS is that windows have rounded corners with a large corner radius. So I found I had to add extra padding to the top & bottom of my window root views, e.g. using .padding(.vertical, 10).

If you don’t have your app optimized for macOS yet, here are some key learnings:

• You need to provide .frame(minWidth: 400, minHeight: 300) for your views all over the place, otherwise your windows or modals might have sizes that don’t work for your UI. Make sure to check them all and provide proper values.

• While you should specify minWidth and minHeight for your views so users can’t resize them to become too small for your content, you might additionally want to provide a larger .defaultSize(width: 800, height: 600) on your WindowGroup scene to default to a larger size than the minimum.

• If you have modal views that cover your entire screen and also need that space, you will want to consider moving these modals to their own windows instead. Utilize the @Environment(\.openWindow) var openWindow property to open new windows on visionOS (and macOS) and specify additional WindowGroup views. See my article about window management in SwiftUI 4 to learn more.

• You can decide to keep the modals for your initial migration instead of using external windows, which would be the proper solution. But note that unlike on macOS, modal sheets in visionOS are not resizable. So at least make sure to provide a size that works well for your sheet for all kinds of potentially dynamic data shown in the modal. That’s what I did for “playing a puzzle” in CrossCraft.

Colors

Note that any controls with a white background will not play well with the hover effect, because the effect uses a white overlay. White on top of white isn’t visible. I ran into this for my crossword puzzle game mode, where users press on tiles to enter characters. Note how the cursor is on a tile but the hover isn’t visible:

Hovers are not visible on white background buttons.

My quick fix was to add the modifier .opacity(0.85) making my white backgrounds 15% transparent, which helped already. More would be better, but white is an expected “crossword” color, so I tried to keep it as white as possible.

Colors that are legible on iOS might not work on visionOS.

I also noticed that many mid-contrast colors, including the system default “blue” accent color, have a really bad contrast on the default window glass background. Make sure to make these colors brighter for visionOS. You can add a specific variant for “Apple Vision” using the Attributes inspector with a color selected.

💡 To make a color brighter using the HSB system, you need to decrease the saturation slightly and increase the brightness significantly. You can additionally move the hue a little bit towards the closest bright RGB value. Refer to this article to learn more about how to make colors brighter/darker properly utilizing HSB.

Conclusion

If you have an app that’s already on iPadOS & macOS, you’re in a very good spot to add support for visionOS. You will be able to reuse all your SwiftUI code. When it comes to window management, you should opt for the macOS version. For everything else, opt for the iPadOS version. Then, ensure all your custom controls have a proper hover effect. Make some layout & UI adjustments like adding padding, making colors brighter, or splitting your app icon to a front & back part.

The entire process took effectively 2 hours for me. I live-streamed the entire process, you can find my recordings with the “wait for build” & “chat” removed in the following two YouTube videos, each roughly an hour long. Note that I added time codes for the different steps outlined above so you can dive into specifics:

When I showed a prototype of this idea to my wife, she immediately asked if she can click the posters to watch a trailer. And born was the idea to make them interactive! In the just published app, besides Trailers, you can also find Showtimes, and Direct Links to Streaming services. Here’s a demo video:

To make sure everything worked as expected, I visited Apples Developers labs in Munich earlier this week since I can’t buy the device myself here in Germany to test it. Unfortunately, Apple engineers confirmed that visionOS does not yet support persisting the positions of windows across app restarts. So for now, one has to keep the device connected to battery to retain the poster positions for multiple days. But it’s easy to place them, so I decided to publish the app anyways. And I made sure to report this shortcoming to Apple in all the official ways I could, including directly to the engineers in the lab. I have more ideas than just this that need that feature. I believe it is the #1 thing missing right now that we developers desperately need in visionOS 2.0.

Long story short, I just released the “Posters” app and would love you to try it:

‎Posters: Discover Movies @Home

Please let me know if you run into any issues. I’m really excited about publishing more apps on this new platform. Multiple apps are in the works, 2 of which might get ready for release as soon as next week. 🤞 This is due to my decision to go Spatial-first (rather than Mobile-first) with my future apps. After all, more than 70% of my last months revenue was made on Apple Vision. And that even though the device isn’t even out for a full month yet! Exciting times for Indies. 🤩

If you don’t want to miss my future apps, make sure to follow me! 👇

In the 6 weeks since the app’s initial release, I worked tirelessly to get the most requested features out, and I’m happy to introduce you to 7 major improvements:

#1: Save & Sync Crosswords

You can now save crosswords to solve them later! And your progress will also sync across devices through iCloud. This was the most requested feature!

#2: 5 New Categories & 30 New Topics

Before this update, 22 topics in 5 categories were supported. This update doubles the number of categories and more than doubles the number of topics! And all of them are available in all 7 languages (EN, FR, DE, IT, PT, ES, TR).

Here’s a full list of all the new topics:

• General Knowledge:
  Anime, Bollywood, Culture & Religion

• TV Shows (new):
  Friends, Game of Thrones, SpongeBob, The Simpsons

• Video games (new):
  Grand Theft Auto, Minecraft, Pokémon, The Sims

• Sports:
  Karate, Taekwondo

• Language Learning:
  Italian, Portuguese (Brazil), Turkish

• Culture & Religion (new):
  Ancient Egypt, Christianity, Greek Mythology, Islam, Judaism

• Science (new):
  Astronomy, Biology, Computer Science, Economy, Medicine

• Technology (new):
  Apple, Cars & Engines, Google, Microsoft

More topics are already in the works and will be added in future updates.

#3: Get (Limited) Tips

Every puzzle has those few words that you just don’t know or don’t remember. You can now uncover a limited amount of fields so you don’t get stuck at a 90% completed puzzle just because of a weird hint, which can be really annoying!

#4: Game Center Support

Earn Achievements for using various features of the app and compete with friends & others in global Leaderboards. Each category has its own leaderboard, so it’s your time to shine and show off your skills in your favorite topic!

My account is assigned to the German App Store, so my screenshots are in German.

#5: Native app for the Mac

While the iPad version of CrossCraft was available on Apple Silicon Macs from day one, I took the extra effort to prepare a native Mac app with a more fitting look & feel. This means, CrossCraft is available on Intel Macs for the first time now!

#6: Native app for the new Apple Vision Pro

Additionally, I migrated CrossCraft to visionOS for a native experience and even live-streamed the entire process. Spatial Crossword Puzzling is here! ✨

#7: Share & Play the Same Puzzle

Share your puzzle with a simple link or a printed QR code. This way you can create a puzzle & challenge a friend to solve the same puzzle – who’s faster?

If you have an audience of readers, share an image of a custom-prepared puzzle to challenge them and add a QR Code that opens the puzzle right within CrossCraft for a smoother solving experience right within the app.

I created puzzles in 7 languages for you to experience the new sharing feature:

• Anime Puzzle: EN | FR | DE | IT | PT | ES | TR

• *Apple Puzzle: *EN | FR | DE | IT | PT | ES | TR

• *Computer Science Puzzle: *EN | FR | DE | IT | PT | ES | TR

• *Economy Puzzle: *EN | FR | DE | IT | PT | ES | TR

These features were requested most, I hope you like how they turned out!

Get the update now: 👇👇👇

‎CrossCraft: Custom Crosswords

If there are any more features you’re missing, please drop an email.

Feed ChatGPT with the following prompt, but don’t forget to replace TOPIC with the topic you want to create a crossword puzzle about, and LANGUAGE with the language the questions and answers should be provided in:

💬 Create 50 clue-answer pairs for a crossword puzzle about the topic “TOPIC” for an audience of fans of the topic. Provide a good mix of easier and harder questions. Provide a good mix of historical and more recent examples. Provide clues and answers in LANGUAGE. Avoid pairs where the answer contains a number. Avoid clues that contain (parts of) the answer. Keep both clues and answers short, e.g. avoid unnecessary articles. Replace special characters like “+” in the answer with its written-out word, like “plus”. Format the clue-answer pairs as a single code block of comma-separated CSV like so:

"This is the first clue","Answer"
"This is the second clue","Answer"

The TOPIC can be replaced with anything. A specific kind of technology, the name of a franchise, a sport you like, or a media website’s URL you visit every day. I’m an iOS developer and I like to know the latest news about Apple products. So I can simply replace TOPIC with Apple News and LANGUAGE with English. ChatGPT should then respond with something like this:

ChatGPT saves a lot of time in coming up with related clues & answers.

ℹ️ If you don’t get an answer like this right away, just try again by pressing the 🔄 retry button below the answer.

Step 2: Copy the CSV Text into a File

Press “Copy code” on the top right of the code block, create a new file with your plain text editor of choice (e.g. SublimeText) and paste the contents into your new file. Make sure to save your file in plain text format with the ending .csv.

ℹ️ Document editors like Word or TextEdit save their files in special markup formats like .docx or .rtf. These are not plain-text files.

Step 3: Check the Validity of the Produced Pairs

While the prompt already specifies not to use numeric values in the answers and not to spoil the answers in the questions, ChatGPT makes mistakes. So double-check that everything looks right. You can also add new entries with your own questions to spice it up a bit more if you like.

Step 4: Select a related Fallback Topic in CrossCraft

A selection of topics you can find in the CrossCraft app.

Make sure you have installed CrossCraft for free on your iPhone, iPad, or Mac:

‎CrossCraft: Custom Crosswords

Open the app and select one of the many topics the app ships with by default, choosing the one that is most related to your topic. If a related topic isn’t there yet, make sure to press “Suggest Topic” inside the app and make your wish. You can also choose “Without topic, just your own questions” at the top if you don’t want to fill the gaps with questions of a fallback topic. For fuller puzzles, you can always select general knowledge topics like “Famous People” or “Pop Culture” as these are widely known. I’ve selected “Technology”.

Step 5: Import the CSV file to CrossCraft

Importing CSV files is a Premium feature.

Make sure you have access to the .csv file from the device you run CrossCraft in, e.g. by saving the file to your iCloud Drive to access it on your iPhone or iPad. Then, in the wizard where you can choose the size & difficulty of the crossword, press the button “Import from file…” in the last step and select CSV in the dialog.

Step 6: (Re-)Generate a Crossword Until You’re Happy

Press the “Create Crossword” button in the bottom right to start generating your first custom crossword. The generation will stop automatically when it can no longer improve the current state of the puzzle. Below the crossword preview, you can see values that indicate the quality of the generated crossword, as in how “filled” it is and how many intersections it has. The quality percentage combines these aspects into one single value. Any percentage higher than 50% can be considered a “well-filled” crossword.

On the same screen, you can find a “Regenerate” button to restart the random generation algorithm if you are unhappy with the quality of the crossword or the selection of clues, which you can preview by pressing “Show Clues”.

Step 7: Export your Crossword as an Image

On iPhone or iPad, I recommend pressing “Share…” and then selecting “Save Image” to store the crossword puzzle in the Photos app, from where you can share it with other devices if needed. This ensures the image does not get downgraded to a JPEG without transparency for compatibility. Alternatively, use “Save to File”.

You will be asked what part you want to share. Choose “Crossword + Clues” for a combined single image. Alternatively, you can export the puzzle & clues separately in case you want to print them out on 2 separate pages, for example.

Step 8: (Optional) Add a Background Image of your Liking

The resulting exported personalized crossword for MacRumors.com

For some extra nice looks, search for a nice background image that fits your topic and place the exported PNG image on top of it with your design tool of choice (e.g. Figma). You could even use AI image generators and ask them to create a “scenery” that fits your topic, which I did using DALL·E in ChatGPT Plus. My exact prompt for the above background image was:

💬 Create a scenery that fits the topic “Apple News” in portrait format. The bottom half should be a plain color/shade. Keep it simple overall.

The exported image conveniently has 5% transparency in its white backgrounds of the fields and clues built-in, letting some of your background image shine through. You see the final result above. With more time and creativity, I’m sure you can create something even better!

Try it for yourself and surprise someone you love. It’s the perfect gift! 🎁

‎CrossCraft: Custom Crosswords

Created with CrossCraft. Topic: Pop Culture. The last question is personalized.

Full Personalization possible

CrossCraft isn’t just another crossword puzzle app. It’s a tool that allows you to create an infinite number of varied crosswords on a selected topic. On top of that, you can add your own clue-answer pairs to personalize the crossword or to ask more specific questions targeted to your audience. The app will always place your custom questions into the puzzle first before filling the gaps with the selected topic. That means, if you provide enough custom questions, you can even create entirely custom crosswords with nearly no fill-words from the selected topic. Perfect for teachers preparing a fun challenge for their students.

To prevent inconvenient typing on a phone or tablet, the app can import lists of clue-answer pairs from CSV or JSON files. This way, you can easily create your custom content on your computer using tools like Google Sheets, which even allows collaboration with others to get more content faster. When you’re ready, save the sheet as a CSV file and create your entirely custom crossword.

Lots of Topics to Choose from

Creating a large enough set of clue-answer pairs can be a tedious and time-consuming task. For a well-filled medium-sized crossword, hundreds of pairs could be needed, depending on the length of the answers and their characters. That’s why CrossCraft ships with a wide variety of topics that you can use as a fallback to fill in the gaps. Or to simply create a crossword that is themed without any custom questions. The personalization step is entirely optional!

In the first release, 20 different topics from 5 different categories are supported:

• General Knowledge: Famous People, Geography, History, Pop Culture

• Movie Franchise: Harry Potter, Lord of the Rings, Marvel (MCU), Star Wars

• Sports: American Football, Basketball, Formula 1, Soccer

• Language Learning: English, French, Japanese, Spanish

• Programming: Android Dev., Apple Platf. Dev., Flutter, Ruby on Rails

More topics in more categories will be added with each update. Some of the next topics I have on my roadmap are Movie Quotes, Game of Thrones, Anime, more languages like German or Italian, and many more in new categories like music, art, literature, science, and technology.

Which topics I include next entirely depends on what users want most: Inside the app, there’s a “Suggest Topic” button – make sure to use it for your favorite topic!

Other features like the ability to define a solution word are already planned.

In all Shapes and Sizes

When creating a crossword puzzle, you can choose from 5 different sizes, 3 different shapes, and 3 different difficulty levels. For example, the topic “Spanish” contains the 600 most frequent words in Spanish. If the easiest difficulty level is selected, only the 200 most frequent words are used, 400 in the mid-level, and all 600 in the hardest level. This way you can start easy and make it harder when you tend to know all the easy answers.

For educators, it can be important to print a full-page crossword. The shapes “landscape” and “portrait” are sized to perfectly fill a full page. When sharing or printing a created crossword, CrossCraft provides the option to export the puzzle and the clue parts separately. This way, the puzzle can be printed on one page, and the clues on a second, improving readability, especially for larger crosswords.

For Everyone and Everywhere

Both the app and all topic contents are available in 7 languages: English, French, German, Italian, Portuguese (Brazil), Spanish, and Turkish. The language for the clues can be selected independently from the app’s interface language, allowing it to easily create crosswords for different language audiences. Where appropriate, the topic contents were adjusted for the audience of the language. For example, when asking for famous TV hosts, in English these could be “Oprah Winfrey” or “David Letterman”, whereas in German other names like “Günther Jauch” and “Anne Will” are more appropriate. These adjustments were made for all languages.

Also, note that no server-side is involved when creating the crosswords or playing them. Everything happens on-device, which means that the app also fully works offline. This is great for playing on the train or an airplane with no internet.

What are you waiting for? Get it now!

Creating an infinite amount of personalized crosswords, plus playing and sharing them is completely free. No ads. No tracking. No traps. Only some options and the file import are considered “pro features” and can be enabled for a small fee.

In Summary

• Customize with Ease
  Choose from diverse topics. Add your own questions. Import them to save time.

• Educational and Fun
  Ideal for teachers and learners. With print-friendly sized exports.

• Multilingual and Offline
  Enjoy in 7 languages and create & play even with no internet connection.

Download and Explore

CrossCraft is available on iPhone, iPad, and Apple Silicon Macs. A native Mac app for all Macs is nearing completion and will follow soon.

Get the app now: 👇👇👇

‎CrossCraft: Custom Crosswords

For journalists and bloggers, a PressKit is available here.

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

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

A Simplified Implementation

Here is the core idea:

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

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

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

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

Usage

Using it feels natural:

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

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

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

• List (wraps UITableView / NSTableView)

• ScrollView (wraps UIScrollView / NSScrollView)

• TextEditor (wraps UITextView / NSTextView)

• Map (wraps MKMapView)

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

The Workaround

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

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

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

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

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

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

Practical Advice

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

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

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

Setting Up the Wrapper Module

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

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

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

import AppFoundation

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

Trade-Offs to Consider

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

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

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

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

1. A clear step-by-step guide on how to get started – including App Store Connect.

2. A simple but flexible permissions system based on the current user’s purchases.

3. A unified paywall design framework for reusable shared paywall UI code.

The first two, I plan to cover in the libraries’ README. This article focuses on the third aspect: How does FreemiumKit help you build a successful paywall quickly? And how can it help you with A/B testing?

FreemiumKit makes StoreKit 2 integration easy as pie. With built-in paywalls & permissions.

Basic Idea

One of the things I had expected from RevenueCat, simply because people were soo positive about it all the time, was that they provide ready-to-use UI components in their Swift SDK. But they don’t. (UPDATE: After my complaints, they started working on it!) All they do is integrate with another service that specializes in providing paywalls and helping users optimize their paywalls by trying out different designs: Superwall. By the way, if you don’t know what A/B testing is – trying out different designs and assessing the data to see what works best is pretty much the definition. A paywall is probably the most important screen to A/B test. So while I really like the idea of the service, its pricing doesn’t scale down very well: They require $0.20 for each purchase, which for a monthly subscription of $1 is 20% of your income – that’s even higher than the 15% Apple keeps for Small Businesses!

Also, I’m personally not a fan of using many 3rd party services, I like to keep my app’s privacy policies short and simple, which becomes harder to do with every new service added. So I rather prefer to select a more “general purpose” analytics service that comes with A/B testing support (among other things) and choose that wisely than integrating with many microservices. But of course, that’s just my personal taste and you might choose differently. There’s certainly one thing I really love about Superwall though: They run the PaywallScreens website, where you can find a nice overview of thousands of real-world paywalls sorted by the estimated income that each app generates, currently led by YouTube, TikTok, and Disney+.

In the first release of FreemiumKit, I wanted to ship everything needed to build a successful paywall UI quickly, so I scrolled through all 312 paywall screens of apps with a higher estimate than $500,000 income per month, picked the 20 screens I found most inviting & clean and analyzed them to find what they have in common. Then, based on my learnings, I developed 2 different and highly customizable UI components that allow you to create most of the variants I analyzed!

Here are the 20 screens I selected in falling grossing order:

Source: paywallscreens.com

Source: paywallscreens.com

Source: paywallscreens.com

Source: paywallscreens.com

Common Design Choices

Everything I recognized which at least 50% (of a kind) have in common:

1. 100% offer either a Monthly or a Weekly “short-term” plan.

2. 100% offer either a Yearly or Lifetime “long-term” plan.

3. 100% use plain white or black text for the plans or unlocked features list.

4. 95% cover the entire screen without any unrelated navigational elements.

5. 95% fit all important information into one screen without the need to scroll.

6. 90% use a background color to highlight their main call-to-action button.

7. 85% have the pricing plans listed on the bottom half of the screen.

8. 80% use a rounded border outline to highlight the currently selected option.

9. 80% have either a back arrow or an “X” button at the top to leave.

10. 61% of the “X” buttons are put on the left corner (harder to reach for most).

11. 80% have a clearly highlighted call-to-action button at the very bottom.

12. 75% of the call-to-action buttons are capsule-shaped (ends 100% rounded).

13. 56% of the call-to-action buttons use the exact same title: “Continue”

14. 70% use a vertical list of buttons for the different plan options.

15. 70% of those with a preselection opt for the long-term recurring option.

16. 60% use a white background behind the list of plans to select from.

17. 55% mention the name of the app somewhere in the top half.

18. 65% offer either a list, grid, or page view with 2-6 (avg. 4) features unlocked.

19. 77% of those offering a list use a checkmark icon in front of each feature.

20. 55% use a background image stretching all to the top edge of the screen.

21. 50% offer a free trial for at least one paid plan.

22. 50% mention a discount percentage compared to other options.

Less Common Design Choices

Things that I noticed some paywalls do, but the majority of them do not:

1. 45% use a different background color for the currently selected plan.

2. 35% have a “Popular” / “Recommended” tag on one of the purchase options.

3. 30% have a radio button like a dot or checkbox to highlight the selection.

4. 30% use a horizontal list of buttons for the different plan options.

5. 30% provide a (less highlighted) “Restore” button within the paywall.

6. 30% provide a (less highlighted) link to their terms and privacy policy.

7. 15% use a page view to show off the features unlocked by the purchase.

8. 10% provide a segmented control to switch between Monthly/Yearly etc.

9. 5% have an animation on their call-to-action button (or anywhere else).

The Paywall Blueprint

With the learnings from above, I built a “blueprint” that incorporates them all:

I’m not a professional designer, but I think it’s good enough for the first public release of FreemiumKit. Better designers than me in the community are invited to contribute (fancy) improvements or entirely different designs. The README has a dedicated section describing how to build your own designs. From what this screen looks like overall and looking at the 20 paywall designs I checked, I think it’s wise for the framework to focus on the part that involves more logic. The entire top half of the screen is very simple to do in SwiftUI (just an Image with an .overlay, a Button and a List of Text views). And the same is true for the less highlighted “Terms of Use”, “Restore”, and “Privacy Policy” buttons at the very bottom.

This is the only part in the paywall blueprint with complex logic.

So let’s focus on the part that loads and lists the available products, highlights the current selection, shows potentially available trial periods, long-term plan discounts, the price tag, a second monthly price tag for better comparison, a “Best Value” or “Most Popular” badge, handles the current plan selection & the logic to show & disable the “Continue” button when needed. As you can see, this part is quite complex to get right, and because (nearly) all that information is actually provided to the app by StoreKit, it’s a great opportunity to simplify things. By leaving the rest of the screen to the developer/designer with all the learnings and the blueprint shared above, users of the library should have full freedom & flexibility to create a unique look for their app’s paywall.

To make things more fun and to make A/B testing possible even in the initial release of FreemiumKit, let’s also create a horizontal list variant like this:

Putting them both side-by-side in their full-screen extent, they compare like this:

The vertical (left) and horizontal (right) paywall blueprints, side-by-side.

Vertical & Horizontal Products Style

FreemiumKit ships with a SwiftUI view named AsyncProducts, which works quite like AsyncImage: You provide it with the product identifiers you want to show in your paywall (like you provide AsyncImage with a URL of your image), and AsyncProducts takes care of fetching the products from the App Store (like AsyncImage fetches the images from the web), shows a placeholder while loading the data, and even presents an error message with a reload button if there are network issues. In other words: It does all the hard work, you just need to decide where on your paywall you want to place it and what size works best for you:

AsyncProducts(
   style: PlainProductsStyle(), 
   productIDs: ProductID.allCases, 
   inAppPurchase: AppDelegate.inAppPurchase
)

Sample usage of AsyncProducts.

The productIDs & inAppPurchase parameters are explained in the step-by-step Getting Started guide within the README. What we care about in this article is the style parameter that allows you to pass in different designs for the UI component. The PlainProductsStyle is just a demo style that shows the minimal implementation of a style for those who want to create their own styles. It’s not intended for direct use. The two real styles FreemiumKit ships with in 1.0 are:

• VerticalPickerProductsStyle for the left design from above

• HorizontalPickerProductsStyle for the right design from above (WIP)

Also, I plan on adding at least one more style named something like HorizontalButtonsProductStyle which implements a UI without a “Continue” button like used in the paywall of Apple’s newest app Final Cut Pro for iPad:

Paywall in Apple’s new Final Cut Pro app for iPad.

But let’s focus on the styles available today and use the vertical picker instead:

AsyncProducts(
   style: VerticalPickerProductsStyle(
      preselectedProductID: ProductID.proYearly,
      tintColor: .blue
   ), 
   ...
)

It takes two arguments, one which lets you specify the product which you want to highlight as a pre-selection. Learning #15 from the above analysis tells us that 70% preselect the long-term recurring option. The other argument lets you choose the tint color, which is used for both the “Continue” button background and to highlight the user’s current selection. Just make sure to select a color that contrasts nicely with white because that’s the continue button text color.

If you want to test out different paywall designs, it’s very easy to switch out the style for A/B testing: Just replace VerticalPickerProductsStyle with HorizontalPickerProductsStyle and all should just work. These two styles even take the same arguments, so it’s really easy. Other styles like the planned HorizontalButtonsProductsStyle will have other arguments, cause there’s no notion of “selection” for a direct button-only style like that, but it should still be easy enough to change that up. All styles conform to the AsyncProductsStyle protocol, so if you want to create a variable to which you can assign different styles based on your A/B test group, you can use any AsyncProductsStyle as its type.

Conclusion

And these are my learnings from analyzing 20 successful paywalls. I put all my learnings into the VerticalPickerProductsStyle which ships in FreemiumKit, so you can easily use AsyncProducts view in SwiftUI instead of dealing with complex logic. You just need to remember to apply the less complex learnings like placing AsyncProducts in the bottom half of your screen, providing both a short-term and long-term subscription, or providing a list of features to unlock in the top half.

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

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

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

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

Data-Driven Navigation in Practice

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

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

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

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

Why This Matters

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

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

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

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

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

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

The Solution

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

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

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

When to Load Manually

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

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

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

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

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

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

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

When to Use It

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

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

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

But most people I talked to since Dub Dub are still unaware of the implications String Catalogs have on their projects. So I figured I should answer the most frequent questions to make it more clear how amazing String Catalogs really are.

What are String Catalogs? What about Strings(dict) files?

String Catalogs are files with the ending .xcstrings and store their content in a custom JSON format. The exact format is not documented (filed feedback to change that: FB12264877) and as a developer, you won’t ever need to fiddle with any JSON code because Xcode 15 ships with a visual editor:

String Catalogs replace both .strings and .stringsdict files and therefore support pluralization out-of-the-box. Unlike .strings(dict) files that are placed under locale-specific folders like en.lproj, String Catalogs encapsulate the translations of all supported languages in one file. This allows for safety checks like showing the progress of specific translations right in Xcode so you are aware of any translations missing (replacing the RemafoX Linter). Likewise, it will also add new keys to all languages automatically for you, saving you a lot of time (replacing the RemafoX Normalizer). And more features could come in future updates, like a check if your localizations have the same parameters (e.g. %@) as your source language (a feature I had planned for RemafoX, filed feedback: FB12264614).

I have a project with Strings(dict) files. Is migration easy?

Yes, totally! Migrating to String Catalogs is easy as pie: Simply right-click one of your .strings(dict) files and press “Migrate to String Catalog…”. This will open a modal with a list of all your .strings(dict) files in the project so you can choose which ones should be combined into one String Catalog file. If you have separate Strings files for different parts of your project, you can keep separate String Catalogs for them, there’s no need to put everything into one String Catalog.

But my project supports older OS versions. Can I still migrate?

Yes, totally! Apple engineers have done something very smart here: While we as developers can make full use of all String Catalog’s features, our apps won’t see any new file format like .xcstrings. Instead, during the build process Xcode will convert the String Catalog back to plain old .strings and .stringsdict files, thus ensuring support for all OS versions you can potentially target. This means, once you can switch to Xcode 15 for your project, you can make full use of String Catalogs without ever looking back!

💁‍♂️ If you have been wishing for an SF Symbols-like app but for Localized Strings in code with official translations for all languages iOS is available in: I built exactly that and the feature is completely free! Just download TranslateKit and check your menu bar. 🌐 👍

I’m using SwiftGen/RemafoX for safe Localization key references with compiler checks. Will I lose this safety?

No, not at all. Xcode not only introduces a new file format for your localizations, but it also comes with tools to automatically extract new localization keys from your project. If you use any of SwiftUI’s localization APIs with LocalizedStringKey or LocalizedStringResource, they automatically get detected and added to your String Catalog. But this doesn’t end with SwiftUI, it also works with plain Swift String APIs like String(localized:), plain Obj-C-style APIs like NSLocalizedString() (even custom names supported), and even Interface Builder files like .storyboard and .xib files. For Info.plist files you need to create a dedicated String Catalog named InfoPlist.xcstrings and extraction will even work there automatically.

Note that you won’t get auto-completion for your keys in code like you now get for images and colors in your Asset Catalogs with Xcode 15. That’s because in Asset Catalogs the source of truth lies in the catalog itself, where your assets are placed. But because Xcode automatically extracts any added localizations from your source code, the source of truth for your localizations is reversed here and lies in your code. Therefore it’s impossible that you add a text to your code that lacks a counterpart in a Strings file (like it was possible before, leading to broken translations). Instead, whenever you add a localized String in your project, Xcode automatically creates a new translation key for all supported languages and you’ll see in the Strings Catalog that your translations are incomplete.

The lack of a green checkmark for the German language indicates that the translation is incomplete.

What about typos? Can I change the key in development?

Xcode not only extracts new keys and adds them automatically to your Strings Catalog, but it will also make sure that any keys in your catalog that are no longer referenced in your project get deleted. It does this safely: If you have a key that you have not provided any translations for in any languages yet, then it will automatically delete the key if it no longer finds it in your project. This is what will typically happen when you have a typo in your key or simply want to improve the key during development and change it up. But if you do have some translations already, Xcode will instead mark the key in the String Catalog as “stale” with a yellow warning symbol. This makes it easy to spot keys no longer referenced, copy over their translations to the new key if needed and delete them afterward.

What if I don’t want to localize a specific text in Code/IB file?

Currently, there seems to be no direct way to control the extraction from the source of truth. I filed a feedback for IB files in particular (FB12264777) because my tools RemafoX (and its predecessor BartyCrouch) support excluding there, therefore switching to String Catalogs might only be possible for people using those if there was some solution provided by Apple. While I also couldn’t find an explicit way to mark a String in code as “non-translatable”, in most SwiftUI views you will find an overload of the same API which takes a Text view instead of a String. For views where this applies, you can use Text(verbatim: "Your Text") to create a Text view whose text won’t get extracted because the keyword verbatim marks it as non-translatable. But because an overload with a Text does not always exist, I filed a feedback for a more direct way to control extraction (FB12469163). For now, I found a workaround by simply using a String initializer in SwiftUI APIs that prefer the LocalizedStringKey overload, just pass something like String("Your Text").

Conclusion

The introduction of String Catalogs in Xcode 15 brings significant improvements to the localization workflow by simplifying the management of translation files. Developers can easily migrate their projects to String Catalogs and maintain the safety of localization key references, while still supporting older OS versions and having control over key changes and typos. Although there are some limitations and areas for improvement, String Catalogs are a huge step forward and have no real downsides compared to the old Strings file system. Migrate now!

The Problem and Solution

Traditionally, app developers have relied on simple prompts to ask users for reviews, often presented immediately after opening the app or at random intervals. This approach can be intrusive and irritating, resulting in users leaving negative reviews or even uninstalling the app.

I developed a fairly complex logic to determine when to ask for reviews in my first app, RemafoX. But for my most recent app (Twoot it!) I broke down what’s really important and further simplified the logic. ReviewKit is the result of this process.

ReviewKit solves this problem by intelligently determining when to request app reviews based on the user’s recent positive activity. It ensures that only users who have had a satisfactory experience with your app and have engaged in certain activities are prompted to leave a review. By doing so, ReviewKit increases the likelihood of receiving positive reviews while minimizing user annoyance.

Of course, each app is different, so you need to specify what a “positive activity” is for your app. But ReviewKit takes care of the rest and is customizable, too!

Setting Up ReviewKit

Getting started with ReviewKit is easy. Follow the instructions below to integrate it into your iOS or macOS app – your deployment target can be as old as iOS 11 or macOS 10.14, which should cover even most corporate apps:

Step 1: Add ReviewKit to Your App

To add ReviewKit to your project, use Swift Package Manager (SPM). In Xcode, navigate to your project and go to the “Swift Packages” tab. Click the “+” button and enter the ReviewKit repository URL:

https://github.com/FlineDev/ReviewKit.git

Lastly, make sure to select your app target to link ReviewKit to.

Step 2: Adjust Review Criteria (Optional)

ReviewKit provides default criteria for requesting app reviews: It requires a minimum of 3 positive events within the last 14 days. If you want to customize these, you can adjust the criteria using ReviewCriteria like so:

ReviewKit.criteria = ReviewCriteria(
   minPositiveEventsWeight: 5, 
   eventsExpireAfterDays: 30
)

In the example above, the criteria have been modified to request reviews only when users have a minimum of 5 positive events, and the events expire after 30 days. That’s when you use the default weight of 1 for the calls down below.

Step 3: Record Positive Events & Request a Review

To trigger the app review request when users complete specific workflows or activities, you need to record positive events using ReviewKit. Call the following method whenever a user completes one of these activities:

ReviewKit.recordPositiveEventAndRequestReviewIfCriteriaMet()

This method will automatically determine if the user meets the criteria for requesting an app review based on their recent positive activity. If the criteria are met, the review prompt will be displayed.

Step 4: Record Other Positive Activities (Optional)

Apart from the primary workflows, it is essential to take into account additional activities that signify positive user experiences. However, requesting reviews during these moments could interrupt users who are already engaged in a workflow, potentially leading to annoyance and decreased likelihood of leaving a review or even impacting their rating negatively. To monitor and capture these events, you can utilize the recordPositiveEvent() function:

// Optionally, you can pass a custom `weight` parameter (defaults to 1)
ReviewKit.recordPositiveEvent()

Note that both of the above methods optionally accept a weight: Int parameter, which you can use to fine-tune the criteria for requesting app reviews. For example, if your app had different levels of engagement, you could specify a weight of 3 for your highest-level activity and set the minPositiveEventsWeight to something like 10. The default weight for positive events is 1.

Example Usage in an iOS Application

To provide a better understanding, let’s consider a sample iOS application and demonstrate how ReviewKit can be used effectively. Suppose you have a social media app where users can post and like others’ posts. Here’s an example:

import ReviewKit

func sendPost() {
  // ...
    
  // Record a positive event after sending a post
  ReviewKit.recordPositiveEventAndRequestReviewIfCriteriaMet(weight: 3)
}

func handlePostLike() {
  // ...
    
  // Record a positive event for liking a post unintrusively
  ReviewKit.recordPositiveEvent()
}

In the example above, the sendPost() and handlePostLike() methods demonstrate how to record positive events for different activities. We call recordPositiveEventAndRequestReviewIfCriteriaMet() after a post was sent as this signifies the end of a workflow the user did in our app, which is a good time to request a review.

When users like a post, they’re still in the middle of the use case of consuming content, which is still a positive activity that we should record, but it could be intrusive to ask for a review at this time, so we just call recordPositiveEvent().

Sample usage of ReviewKit in the Twoot it! app.

Conclusion

ReviewKit offers a simple yet effective solution for asking users to review your app. By intelligently determining when to request app reviews based on recent positive activity, ReviewKit increases the chances of receiving positive reviews and helps your app grow. With easy integration and customizable criteria, ReviewKit is a valuable tool for any iOS developer or team.

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

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

Why This Matters

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

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

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

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

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

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

What Changed

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

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

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

Apple Sherlocked SwiftGen

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

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

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

What String Catalogs Bring

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

The key improvements are substantial:

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

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

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

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

Practical Impact

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

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

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

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

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

The New Action in Xcode 15

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

The result is cleanly formatted with one parameter per line:

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

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

When to Use It

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

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

Massive Sale: 50% off on all Subscription Plans!

To add to the excitement of WWDC, I decided to offer a limited-time sale on all RemafoX subscription plans. Starting now and until the end of WWDC week, you can enjoy a staggering 50% discount on all subscription prices. This is a rare opportunity to access the full potential of RemafoX at an unbeatable price. But here’s the best part: if you subscribe during this week, you will keep the lower price forever, even after the sale ends. Don’t miss out on this incredible deal to supercharge your development journey.

New features are added to RemafoX every month – at no additional cost! Next up is version 2.0 with an easy way to invite your users to help translate your app by reviewing a few machine-translated texts without leaving your app. And giving you full control over how you want to approach your users – or maybe you just want to ask a few friends to help translate? All possible soon with an active subscription. ✨

Update 1.6: Exciting New Features for WWDC!

In addition to the very special sale, I have packed RemafoX 1.6 with three brand-new features designed to enhance your coding experience. These features are completely free for everyone and are my way of celebrating WWDC with you.

Let’s take a closer look:

Feature 1: “Sort Selection” – Organize Your Code with Ease

I’ve added a sorely missed feature to Xcode: A “Sort Selection” button. Now you can easily sort any selected code alphabetically, saving you valuable time and effort. Experience the convenience of organized code and streamline your development process.

Feature 2: “Multi-Line Code” – Simplify Complex Collections

Tackling complex collections in your code is now a breeze. With the “Multi-Line Code” button in RemafoX, Xcode detects collections like parameter lists and automatically multi-lines them. Enjoy improved visibility and efficiency while handling intricate code structures.

Feature 3: “One-Line Code” – Condense Code Instantly

When you need to condense multi-line code into a single line, the “One-Line Code” button comes to the rescue. Reduce clutter and enhance code readability with a single click. Perfect for sharing snippets or creating concise representations of lengthy code. Or for making simple enums more readable.

How to Get Started with RemafoX for Free

1. Download and Start RemafoX: Download RemafoX here from the Mac App Store to enjoy the benefits of the sale and the new features of RemafoX 1.6. Once downloaded, launch the app once for the Xcode extension to propagate itself to the system. You can close the app right away if you don’t want to use any of its translation workflow enhancements.

2. Enable the Xcode Source Editor Extension: To integrate RemafoX seamlessly with Xcode, go to your device’s Settings app and search for “Extensions”. Enable the entry for RemafoX inside the Xcode Source Editor Extension modal to activate the RemafoX buttons within Xcode.

3. Set Up Shortcuts in Xcode Settings: Open Xcode and navigate to the Preferences menu. In the Key Bindings section, set up custom shortcuts for the “Sort Selection,” “Multi-Line Code,” and “One-Line Code” buttons you can easily find by typing “remafox” into the search bar. This will allow you to harness the power of RemafoX quickly and effortlessly within Xcode.
   If you’re not sure which shortcuts to use, here are the ones I use:
   ⌥⌘S  for “Sort Selection”
   ⌥⌘⬇  for “Multi-Line Code”
   ⌥⌘⬆  for “One-Line Code”

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Conclusion

Get RemafoX, either for its awesome Free features or to secure a subscription at a reduced price and profit from all future updates. Boost your productivity now! 🚀

‎RemafoX: Easy App Localization

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

A Preview-Only Delay Helper

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

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

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

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

You use it in a preview like this:

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

Why This Matters

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

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

But the good news is that Federico automated the site in pretty much all aspects, so it “just works” for the most part. Kudos to him for designing things in a way that makes keeping the project healthy as easy as possible. 💯👏 Also, thankfully he used Swift for basically everything, including publishing the website, or even for helper tools like sending automated tweets for new summaries on Twitter. For a Swift enthusiast like me, who even runs a newsletter about Swift Evolution, this was a huge relief. It looks like that for this year, all I need to do is 2 things:

First: Dump the basic information about each session (like the links to the video or Apple’s session description) into the project after the Platforms State of the Union (also known as the “Developer Keynote”) has taken place. Because that’s when Apple announces the session details for the rest of the week.

Second: Merge PRs that members of the community created for the sessions listed here which don’t have a summary yet. In fact, you could actually visit the list now and will find ~120 sessions for just the year 2022 nobody contributed notes for yet, compared to ~60 sessions that do have session notes for 2022.

While it’s my main job for this year to do these 2 things due to the restricted time to prepare anything else, I have more things planned for the future of the project. And because this is a community project, I want to share my plans with you.

80% Session Coverage by End of WWDC Week

Photo by Tuyen Vo / Unsplash

If I have learned one lesson in life, it’s this: It doesn’t matter what you do – as long as you stay active, you will always learn something! Why I’m bringing it up? Well, during my call with Federico I had an idea for this project that was rooted in an experience I’ve had because I’m a big fan of the Harry Potter books. (Don’t worry, it has nothing to do with Rowlings writing directly.) You see, for a fan like me, it was unbearable to know that a new book has been published, but having to wait another 2.5 months for the German translation to be available. I had just turned 14 when The Half-Blood Prince was released, so while I could understand English to some extent, it was not enough to work through an entire book.

Thankfully, in one of the fan forums (probably this one) I heard of a project where people organized to translate the entire book in just 48 hours. I was skeptical at first. But the plan was simple: Half of the participants would translate roughly one page of the book within the first 24 hours. Then the other half would each receive one participant’s translation and review it, like an editor, to improve the quality. In the end, the organizers would stitch everything together and send the end result out as a PDF file to all participants. It sounded too good to be true. But it totally worked: I participated as an initial translator and had the fully translated book by Sunday evening. It felt like magic back then. And I learned my lesson about the power of crowds and collective effort.

This transformative experience resonated with me and led me to believe that we can achieve something equally incredible with the WWDC Notes project. Just as the Harry Potter translation project harnessed the power of community collaboration, I am confident that, with your help, we can strive for an ambitious goal: achieving 100% coverage of all WWDC sessions with at least some basic notes within the first week! By leveraging the collective expertise and enthusiasm of the community, we can ensure that valuable insights and summaries are available promptly, empowering developers worldwide.

Okay, you’ve read the section title, so why do I aim for just 80% then? First off, there are some sessions that are about niche topics and might not be of interest to a broader developer audience, like “What’s new in AVQT”. I don’t think there’s a need for those to be available within the first few days, so let’s reduce to 90%.

Secondly, one of the key learnings for code coverage best practices is that “we should not be obsessing on how to get from 90% code coverage to 95%. The gains of increasing code coverage beyond a certain point are logarithmic.” I think, something similar is true for WWDC sessions: Once 80% of sessions are covered, it’s likely that the missing 10% of relevant topics are ones nobody wants to watch because they sound too boring or complicated (even if they are not). It can feel like “the pains of increasing session coverage beyond a certain point are logarithmic.” Hence, I aim for 80% coverage by Sunday. Fits also the Pareto principle.

But this all can only work with your help. Yes, yours. You never write session notes? Or you do, but only scarce, and therefore you never share them publicly? Then this is your chance to be more active and learn something new along the way! There are no requirements for the length or format of notes, anything helps. You can even choose to only contribute as an editor if you like, it also helps!

In order for me to organize, please contact @WWDCNotes on Twitter or Mastodon with the message: “I volunteer to contribute & review notes. I’m most interested in the topics” and then mention some topics from this official list. If you want to only contribute or only review, adjust the text accordingly.

I will then get back to you on day 2 of WWDC week with suggestions on which sessions you could help with, so you only need to take notes for those. Thank you in advance for your help! 🙏 If everyone helps out a bit, we all profit together.

Bite-Sized Takeaways for Twitter & Mastodon

Photo by Khamkhor / Unsplash

While it’s great to have summaries for every WWDC session, there still are well over 100 sessions each year, and it can be really hard to decide which session is worth your time, let alone for the video but even for reading or skimming through the notes, which can also be time-consuming. This is exactly the reason why I’ve tried to strip down my key takeaways from each of the 21 sessions I watched & summarized last year during WWDC week and put them all into a single Twitter thread, summarizing each session in a single tweet in less than 250 characters each (280 minus “More: ”).

The community seemed to have loved this, the thread was retweeted 48 times (this is by far my most retweets so far) and got mentioned in several newsletters. I think that’s evidence that these kind of byte-sized summaries are something the community needs, and therefore I’m planning to up the game this year:

Of course, like every year, I will be watching all the sessions I’m personally interested in and I will be writing notes so I can skim through my learnings later on. Obviously, I will contribute my notes to the project. But I will probably only be able to cover ~20 sessions in the first week again, which is just about 10% of them all. With the help of the community, I’d like to grow the usefulness of the #SessionSummary thread for #WWDC23 by increasing the coverage!

So, I will try to break down every note contributed to WWDC Notes to a list of key takeaways and I’m inviting the community contributors to help me with that. How this help can look exactly, I will figure out before WWDC and announce on the @WWDCNotes Twitter and the new Mastodon accounts. Make sure to follow them to not miss the announcement!

Open-Sourcing the Website

Currently, the WWDC Notes project consists of 4 GitHub repositories: Content, Website, TwitterBot, and SocialImages. Only Content is currently open-source:

Screenshot of the WWDCNotes organization’s repositories.

Federico told me, for the future of the project he wanted to open-source everything, similar to how the Swift Package Index project operates in the open. While he won’t be able to help with this goal, I 100% agree with it so I will try to restructure the repositories in a way that I can open-source everything, and maybe even keep everything in a single repository, if that makes sense. I plan on tackling this topic later this year once the WWDC buzz has settled down. I’ll keep you posted about any changes on Twitter & Mastodon when the time comes.

Conclusion

And those are my initial goals for this project. To summarize:

1. Get 80% of all WWDC sessions covered with notes by Sunday

2. Twitter/Mastodon thread with bite-sized key takeaways for all sessions

3. Open-Source the full project, including website & social bots (long-term)

What do you think? Do you like the direction this is taking?
Or do you have ideas you would like to share with me? Let me know!

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

Where to Find the Setting

The setting lives in your scheme configuration:

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

2. Select the Run action on the left

3. Switch to the Info tab

4. Uncheck Debug executable

What This Does

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

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

The Trade-Off

Without the debugger attached, you lose:

• Breakpoints (they will not trigger)

• po and expression commands in the console

• Memory graph and view hierarchy debugging tools

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

Coming from iOS development, I was hoping not to have to learn all details of AppKit. But I had to write all sorts of hacky code to do the simplest things, like closing a window. Or disabling the full-screen button on a window. But there’s good news: By increasing my app target to macOS 13.0, I could finally do window management through SwiftUI and eliminate all the hacks I’ve had in my app.

Finally, my app feels really 100% SwiftUI-driven. And here are all the new APIs I could make use of grouped and titled by the task I wanted to achieve. As window management is probably the biggest difference between iOS and macOS development in SwiftUI times, this article could also help anyone switching from iOS to macOS to understand how window management is done on the Mac.

Opening a Window

If you are using a WindowGroup (which was the only type of window available on SwiftUI 3), with SwiftUI 4 you have two options here: The first, which was already supported before, is to use the handlesExternalEvents method like so:

enum Window: String, Identifiable {
   case paywall
   // ...
   var id: String { self.rawValue }
}

@main
struct AppView: App {
   var body: some Scene {
      // ...
      WindowGroup("Plan Chooser") { ... }
         .handlesExternalEvents(matching: [Window.paywall.id])
      // ...
   }
}

Then, when you want to open this window, you would need to open a URL like you can open any external URL but with a custom URL scheme. For example:

@main
struct AppView: App {
   @Environment(\.openURL)
   var openURL

   var body: some Scene {
      // ...
      WindowGroup(...) { ... }
         .commands {
            CommandGroup(after: .windowArrangement) {
               Button("Show Plan Chooser") {
                  self.openURL(URL(string: "remafox://\(Window.paywall.id)")!)
               }
               .keyboardShortcut("1")
            }
         }
   }
}

This method doesn’t work on the new Window type though, although it’s fully available there, too. The documentation is clear about it:

This modifier is only supported for WindowGroup Scene types.

But the second method works for both WindowGroup & Window: The new \.openWindow environment value! First, we define an id in the initializer:

enum Window: String, Identifiable {
   case paywall
   // ...
   var id: String { self.rawValue }
}

@main
struct AppView: App {
   var body: some Scene {
      // ...
      WindowGroup("Plan Chooser", id: Window.paywall.id) { ... }
      // ...
   }
}

Then, we simply pass that id to openWindow to trigger presentation manually:

@main
struct AppView: App {
   @Environment(\.openWindow)
   var openWindow

   var body: some Scene {
      // ...
      WindowGroup(...) { ... }
         .commands {
            CommandGroup(after: .windowArrangement) {
               Button("Show Plan Chooser") {
                  self.openWindow(id: Window.paywall.id)
               }
               .keyboardShortcut("1")
            }
         }
      // ...
   }
}

This is much nicer! Note that there’s also \.openDocument for DocumentGroup.

Prevent Duplicate Windows

Using id for a window does not prevent multiples of it from appearing:

At least not for WindowGroup, but you can simply use Window to ensure multiples of a window with the same id are never created! But that’s not always an option.

A Window is much more restricted than a WindowGroup in various ways. For example, you can’t call .commands on it like I’ve done above to set some buttons in the app’s main menu. Also, Window is a macOS-only API, therefore you can’t reuse the code on iPadOS. The reason I couldn’t use it for RemafoX is the restriction I already mentioned before: Window does not support handlesExternalEvents. But I need that API because RemafoX is deeply integrated with Xcode through both an extension and a CLI tool, and those can’t make use of \.openWindow because they simply are not part of the same target. But they can still open “external” URLs!

Whatever reason you might have to prevent duplicates of WindowGroup, do this:

WindowGroup("Plan Chooser", id: Window.paywall.id, for: String.self) { _ in
   // ...
} defaultValue: {
   Window.paywall.id
}

It’s using an overloaded version of the WindowGroup initializer which takes additional for type and defaultValue arguments. It can be used to open a specific window related to any data type you want (like a Profile type), but I’m simply reusing the id of type String here to make the window unique.

In my case, I had to do this in several places, so I created this extension:

extension WindowGroup {
   init<W: Identifiable, C: View>(_ titleKey: LocalizedStringKey, uniqueWindow: W, @ViewBuilder content: @escaping () -> C)
   where W.ID == String, Content == PresentedWindowContent<String, C> {
      self.init(titleKey, id: uniqueWindow.id, for: String.self) { _ in
         content()
      } defaultValue: {
         uniqueWindow.id
      }
   }
}

With that, the above call with two Window.paywall.id calls became just this:

WindowGroup("Plan Chooser", uniqueWindow: Window.paywall) {
   // ...
}

For opening a window, we additionally pass the value param to openWindow:

Button("Show Plan Chooser") {
   self.openWindow(id: Window.paywall.id, value: Window.paywall.id)
}

Again, the multiple calls to Window.paywall.id bugged me, so I created a helper:

extension OpenWindowAction {
   func callAsFunction<W: Identifiable>(_ window: W) where W.ID == String {
      self.callAsFunction(id: window.id, value: window.id)
   }
}

Now I can simply call, even getting rid of the .id suffix:

self.openWindow(Window.paywall)

Closing a Window

Now that we can (uniquely) open a window, let’s also close it. And here, the situation before was much worse than with WindowGroup, where we had some workaround within SwiftUI. There simply was no way of closing a window in SwiftUI directly. I had to implement this hack using AppKit:

struct WindowAccessor: NSViewRepresentable {
   @Binding
   var window: NSWindow?

   func makeNSView(context: Context) -> NSView {
      let view = NSView()
      DispatchQueue.main.async {
         self.window = view.window
      }
      return view
   }

   func updateNSView(_ nsView: NSView, context: Context) {}
}

@main
struct AppView: App {
   @State
   private var window: NSWindow?

   var body: some Scene {
      WindowGroup(...) {
         SomeView(...)
            .background(WindowAccessor(window: self.$window))
      }
   }
}

Then, when I wanted to close the window, I would call self.window.close().

In 2021, the \.dismiss environment value was added that allowed to dismiss presented views like sheet, popover or fullScreenCover right from within them. I’m not sure if this behavior was already available back then or added in 2022, but today the docs additionally state that the dismiss action can be used to:

Close a window that you create with WindowGroup or Window.

This certainly only works if there’s currently no modal view presented within the window in question. But then it works like a charm, we can just write this:

@main
struct AppView: App {
   @Environment(\.dismiss)
   var dismiss

   var body: some Scene {
      WindowGroup(...) {
         // ...
         Button("Close") {
            self.dismiss()  // <= this closes the window if no modal
         }
      }
   }
}

Disabling Full-Screen Button

Previously, I used the same hack mentioned above which gave me access to an NSWindow to do more configuration like disabling the full-screen button for views with a fixed size, like my welcome window or my about window. But now we have the new modifier windowResizability which allows us to disable the full-screen button indirectly. By default, it’s set to contentMinSize for all windows except Settings (which is a Scene type like WindowGroup). But we can do this now:

@main
struct AppView: App {
   var body: some Scene {
      WindowGroup(...) {
         SomeView(...)
            .frame(maxWidth: 400, maxHeight: 400)
         }
         .windowResizability(.contentSize)
      }
   }
}

By setting the windowResizability to .contentSize, we tell SwiftUI to more strictly follow the sizes we provide in the frame modifier. As a logical consequence, if the maximum size specified by the view is smaller than the users current screen size, then SwiftUI will automatically disable the full-screen button for us! 🪄 It’s not a very obvious or direct API, but it makes sense. Effectively, if we provide any values below 1366 by 768, which is the native size of an 11-inch MacBook Air (from 2015), we should have disabled the button for most users.

TCA Extras

If you are using The Composable Architecture (TCA) for your apps like me, you might ask yourself how you can best forward these new environment values to your reducers, as logic such as opening/closing windows should happen in those. The great community around TCA helped me solve this elegantly, in particular, Thomas Grapperon provided a type that I renamed to OnChange which you can simply copy & paste into your projects from here. Then, in your view, attach the .onChange modifier passing it any value to forward to the reducer like this:

@Environment(\.openWindow)
var openWindow

var body: some View {
   WithViewStore(...) { viewStore in
      SomeView(...)
         .onChange(of: \.$openWindow, store: self.store) { window in
            self.openWindow(window)
         }
   }  
}

Note that the \.$openWindow refers to a field in the State, so we need to define it:

struct SomeState {
   @OnChange
   var openWindow: Window?
}

Now, in our reducers, we can simply set the state value to a Window enum case and the view will automatically forward the change to the @Environment value. This also works with any other SwiftUI attribute, I also used it for @FocusState!

By the way, while TCA ships with a \.dismiss dependency, calling await self.dismiss() in the reducer will (currently) not behave like the SwiftUI \.dismiss environment value and close the window. Instead, it will do nothing and even produce a warning. As a workaround, I implemented a dependency that makes use of AppKit APIs by traversing the open windows, finding the match, and closing that. You can copy & paste the Gist from here, usage looks like this:

// add the dependency to your reducer
@Dependency(\.closeWindow)
var closeWindow

// close a window in a `run` effect
return .run { _ in await self.closeWindow(Window.paywall) }

And that’s all I had to share about window management in SwiftUI 4 today!

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

Two Snippets I Use Daily

I have two Xcode code snippets configured for this purpose.

“nyi” – Not Yet Implemented:

#warning("Not yet implemented!")

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

“dw” – Developer Warning:

#warning("<#message#>")

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

How to Create Xcode Snippets

Setting these up takes about 30 seconds each:

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

2. Select the code

3. Right-click and choose Create Code Snippet

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

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

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

7. Click Done

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

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

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

The URL Trick

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

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

Replace apple with FlineDev:

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

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

When This Helps

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

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

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

Simplify an app icon with a single 1024x1024 image that is automatically resized for its target. Choose the Single Size option in the app icon’s Attributes inspector in the asset catalog. You can still override individual sizes with the All Sizes option. (18475136) (FB5503050)

My other two wishes still stand true and remain at the top of my wishlist:

#1: A new Swift-only database framework to replace CoreData in the future. I outlined how I imagine such a framework could work here, read that for details.

#2: App **modularization support **within Xcode. Currently, I have to maintain a long Package.swift file manually to modularize my app, read this for more.

With these out of the way, here are 3 new wishes I have for this year’s WWDC.

#3: Circular charts in the Swift Charts library

At the end of my last year’s article, I stated:

In the past, I was always surprised by at least one or two frameworks entirely, like SwiftUI in 2019, WidgetKit in 2020, and DocC in 2021. What will it be this year? I can’t wait to find out!

Well, it was Swift Charts, for sure! It’s the new shiny library that maybe not every app needs immediately, but I’m sure will inspire many developers to visualize some of their app’s data to give users a better overview of their contributed data. It’s SwiftUI-only, so not all teams have had the opportunity to make use of it yet.

The first version of the Charts library shipped with a good amount of chart types that all have in common that they need only one or two straight axes. For example, you can already draw (and customize!) line charts, bar charts, and even heat maps. Jordi Bruin has put together a GitHub repo with screenshots & source code that can give you a good overview of what’s already possible today.

But when I tried using the Swift Charts library myself for my open-source app Open Focus Timer that I develop during my live streams on Twitch, I wanted to show users a pie chart of how their work time is split across different projects. But pie charts are currently not supported by the Charts library, nor are spider charts, doughnut charts or sunburst charts. But I think they’re so common, that they really should all be added to a second version of the Charts library this year.

And next year, maybe tree-like charts (or diagrams) could be added as well, which could help create professional tools, e.g. for drawing a UML diagram of an apps model layer, for visualizing data structures like B-trees, or for building interactive state machines that could help understand features on a more abstract level. I have enough ideas that could make great use of such charts or diagrams!

#4: Streamer Mode in Xcode to redact code

Sharing content is a great thing. It not only helps others who consume your shared content to learn something new or to get inspired by it. Their feedback can also help the content creator to discover new aspects they haven’t thought about yet, such as subtle bugs, UX issues, or lack of accessibility support. But if the content to be shared is related to a coding project, security & secrecy concerns come into play.

For example, when sharing an open-source framework with the community that integrates with 3rd party services, we have to ensure no testing credentials are ever committed to the repository or else they might leak and get abused. In fact, that example is exactly the situation I ran into with SwiftPM for my open-source tool BartyCrouch, I explained how I solved it in this article.

And secrets aren’t the only part we want to hide from others: No company would want the core value of their products that took a lot of effort to figure out to leak to a potential competitor. Copycats are a serious problem that can destroy businesses. The solution for Git repositories is simple enough: Valuable code that shouldn’t leak needs to be kept closed-source and never shared with outsiders.

But hiding secrets from a Git repository or keeping parts of the codebase private is only part of the story. What about video calls with friends or strangers that want to help us? What about Indie developers (like me) who want to live stream their work as much as possible? There are so many situations where I would love to simply share my screen and show a particular problem or solution right within the context of my real-world application, but I don’t. The risk of accidentally leaking sensitive code is just too high for me. This leads to many missed potentials:

• As an Indie developer, I would love to even live-stream the development of updates to my closed-source apps, but there are parts I don’t want to leak. So, all I do is to live-stream my open-source work. That’s a big bummer.

• As a framework user, I would love to report bugs or feature requests by quickly recording my screen and sharing a video of the in-context usage. Currently, I often times skip reporting anything because I find it too cumbersome to prepare a demo. Or I copy parts of code from the context and then have to answer several questions to explain why I’m doing it exactly the way I do.

• As a participant in a weekly developer exchange call, I prefer to just talk about code on an abstract level if I run into problems rather than sharing my screen and showing it in detail. And even if I do share my screen, I would never allow my counterpart to control my screen (e.g. to quickly show me something). I know, part of the problem is that I’m having trust issues, but I’m not alone.

So, what I wish for is a feature within Xcode to mark specific parts of my codebase as “confidential” and when I share my screen, all confidential parts would be hidden from the shared screen. Such a feature is commonly referred to as “Streamer mode” in apps like Discord. And it could be implemented in a variety of ways, here’s how I imagine it to work:

• The confidential content could stay visible for the streamer but be highlighted by Xcode so the streamer is aware that it won’t appear in any shared content.

• The marking of content as “confidential” could happen on different levels, such as on a file level (all contents of a file are redacted), on a type level, on a function level, or on a variable level. In the latter, the entire lines would be redacted.

• The names of redacted content could be still shown (file name / type name / function declaration / variable name) and only their bodies/values redacted.

• The names of all contents marked as “confidential” could be locked from editing to ensure that renaming them doesn’t temporarily make their contents leak.

• The confidential markings could be stored in a file that can be committed to Git so other developers in a team could profit from them in their outside calls, too.

• Streamer mode could be automatically enabled when any app is currently making use of the screen-capturing APIs so the developer wouldn’t have to remember to turn on “Streamer mode” manually. This should make it work for both video calls (in FaceTime/Zoom etc.) and screen recordings (in OBS/QuickTime etc.).

I’m not very optimistic about such a feature making its way into Xcode as I feel like this is not a problem commonly stated by many developers. It feels like a niche issue. But in my opinion, it’s one of those features you don’t know you were missing until you got used to them and then you’d never want to miss them again.

#5: AR/VR OS development with an iPhone

Tim Cook has been publicly talking about the potential of AR since as early as 2016. Assuming he wouldn’t talk about something Apple hasn’t researched at least for a whole year already, we can safely say that Apple is working on AR products for at least 8 years. The first iPhone took two and a half years to develop. The first Apple Watch took three years of development. So while one could ask, why we still haven’t gotten Apple’s first AR device then, I’m going to simply assume we will get one this year. And I will also assume that this new device will ship with its own operating system, let’s call it “AR/VR OS”.

I can already foresee a problem for developers when such a device gets announced: Not every developer will be able to purchase a new device right away. Some due to financial restrictions, some because first gen products tend to not be available in all countries all at once. In the past, this was not a big issue. There are simulators for the iPhone, the iPad, the Apple Watch, and even the Apple TV that ship with Xcode. While there are some restrictions (like no camera support), most apps can be fully developed and for the most part, even tested on these without any issues. That’s because all these devices have one thing in common with our development device, the Mac: They all render a virtual interface on a flat screen.

But an AR device is different: By its very definition, it “augments reality”, which means that in order to develop and test any useful app properly, we need to have access to a camera feed so we have something to “augment”. While Apple could provide some sample virtual environments for testing stuff in an AR/VR simulator, as they did with the location simulation, this would be very limiting for many use cases of apps Apple didn’t cover and can also be annoying to work with.

What I wish for instead is for Apple to provide developers with a way of testing AR/VR OS development using the camera feed of a connected iPhone or iPad. This could be restricted to devices with a LiDAR scanner if that’s a technical requirement. But it should also work wirelessly as we will want to walk around with it to test our features in different areas of the world. The basic technology for that was already shipped in the form of Continuity Camera which allows using an iPhone as a webcam. Maybe that feature was just a by-product of said testing functionalities originally built for the internal team that was working on the AR product in the first place. Who knows? This could be a sign that it will come.

But more importantly, why I’m optimistic that we will get some way of testing for AR/VR OS without the real device is that Apple has an interest in as many apps as possible to support the device. And that means it has to be as easy as possible to develop applications for it. After all, the availability of (unique) apps is an important selling point of any new software platform.

What about the AI hype?

While I do wish for better auto-completion support in Xcode or even a virtual coding assistant of some sort that I can tell what I want and it writes the code to meet my criteria so I don’t have to type out all the code myself, I don’t think we’re there yet. I did play around with ChatGPT, but it got things wrong 80% of the time when I asked for code. It not only used deprecated APIs all the time, but it also produced code that didn’t build. It often didn’t even understand what I wanted.

While a dedicated model for coding from Apple might lead to better results, I don’t think it will come close to what I would consider “reliable” yet. And I’m sure Apple knows this. They might explore such a feature in the future, but I hope they won’t jump on the current hype train and try to build something half-baked into Xcode. I prefer tools that I can rely on, and that are predictable. I think that Apple does that, too. But the technology isn’t there yet. I expect something big in this direction next year at the earliest, but only something tiny if anything at all this year.

Conclusion

So, these are my top 5 wishes for WWDC 2023. Do you agree with me? And what are yours? Let me know by commenting on Twitter here or on Mastodon there.

Swift 6 won’t be released in 2023 anymore, that has been made clear by Doug Gregor from the Swift Language Workgroup. But did you know that Apple has already shipped parts of Swift 6 in 5.8? Yes, it’s true. Some parts of Swift that shipped with Xcode 14.3 a few weeks ago are turned off by default. They will be turned on once Swift 6 comes out, which might take another year, or even longer.

These features introduce some breaking changes to Swift, for example by renaming known APIs, adjusting their behavior, or adding new safety checks to the compiler. But they will all get turned on at some point to help improve our code bases. And we will have to update our projects to play nicely with those changes.

I figured it’s a good idea to turn on all features in my projects to see if there’s any breaking change for my codebase that I should know of. And of course, I could also make use of some new features, such as BareSlashRegexLiterals, which makes the /.../ regex literal syntax available for concise Regex initialization.

Thankfully, with Swift 5.8 there’s now a unified way of enabling these options: We just need to pass -enable-upcoming-feature to Swift by providing it in the OTHER_SWIFT_FLAGS in our projects build settings in Xcode. But we need to know also what features are available, and I couldn’t find any place with a good overview (yet). The proposal that introduced this unified option does contain such a list, but it doesn’t get updated with newer options added later on, such as the one from SE-0384. So, where can we currently reliably get a list of all supported options?

✨ UPDATE: You can now filter by upcoming flags directly on Swift.org.

Swift is open source, so the most reliable place seems the Swift GitHub repository! It includes a Features.def file which contains entries (link to release/5.8 branch) named UPCOMING_FEATURE including both the related Swift Evolution proposal number and the Swift version they will be turned on:

UPCOMING_FEATURE(ConciseMagicFile, 274, 6)
UPCOMING_FEATURE(ForwardTrailingClosures, 286, 6)
UPCOMING_FEATURE(BareSlashRegexLiterals, 354, 6)
UPCOMING_FEATURE(ExistentialAny, 335, 6)

Here are the options with a short description of what they do:

• ConciseMagicFile:
  Changes #file to mean #fileID rather than #filePath.

• ForwardTrailingClosures:
  Removes the backward-scan matching rule.

• ExistentialAny:
  Requires any for existential types.

• BareSlashRegexLiterals:
  Makes the /.../ regex literal syntax available.

For some reason, two options seem not to be listed there (I’m investigating):

• StrictConcurrency:
  Performing complete concurrency checking.

• ImplicitOpenExistentials:
  Performs implicit opening in additional cases.

More options will ship with later versions, e.g. ImportObjcForwardDeclarations.

To additionally check my code for proper concurrency support, I chose to also pass -warn-concurrency (this should actually be the same as StrictConcurrency if that actually works) and -enable-actor-data-race-checks.

Migrating my project

If you also want to enable all 5.8 options in your project, like me, copy (⌘C) the following text block, then head to your Xcode projects “Build Settings” tab, search for “Other Swift Flags”, select that option in the editor and paste (⌘V) it in:

//:configuration = Debug
OTHER_SWIFT_FLAGS = -enable-upcoming-feature BareSlashRegexLiterals -enable-upcoming-feature ConciseMagicFile -enable-upcoming-feature ExistentialAny -enable-upcoming-feature ForwardTrailingClosures -enable-upcoming-feature ImplicitOpenExistentials -enable-upcoming-feature StrictConcurrency -warn-concurrency -enable-actor-data-race-checks

//:configuration = Release
OTHER_SWIFT_FLAGS = -enable-upcoming-feature BareSlashRegexLiterals -enable-upcoming-feature ConciseMagicFile -enable-upcoming-feature ExistentialAny -enable-upcoming-feature ForwardTrailingClosures -enable-upcoming-feature ImplicitOpenExistentials -enable-upcoming-feature StrictConcurrency -warn-concurrency -enable-actor-data-race-checks

//:completeSettings = some
OTHER_SWIFT_FLAGS

If you are using a SwiftPM-modularized app like me, or if you’re working on a Swift package, you will need to additionally pass an array of .enableUpcomingFeature’s to each target via swiftSettings:

let swiftSettings: [SwiftSetting] = [
   .enableUpcomingFeature("BareSlashRegexLiterals"),
   .enableUpcomingFeature("ConciseMagicFile"),
   .enableUpcomingFeature("ExistentialAny"),
   .enableUpcomingFeature("ForwardTrailingClosures"),
   .enableUpcomingFeature("ImplicitOpenExistentials"),
   .enableUpcomingFeature("StrictConcurrency"),
   .unsafeFlags(["-warn-concurrency", "-enable-actor-data-race-checks"]),
]

let package = Package(
   // ...
   targets: [
      // ...
      .target(
         name: "MyTarget",
         dependencies: [/* ... */],
         swiftSettings: swiftSettings
      ),
      // ...
   ]

Don’t forget to upgrade your tools version at the top of the file to 5.8:

// swift-tools-version:5.8

.enableUpcomingFeature is only available from Swift 5.8

That’s because Swift doesn’t pass along the options you specified for your project target automatically to any modules you import into your project. And that’s good news, because that way Swift packages you might be including into your project don’t need any adjustments and you can still use these features for your own app code. And vice versa: Package authors can turn these features on for their projects without affecting the code in projects they get consumed in.

After turning these on and building, I ran into four kinds of issues:

1. I had to add the any keyword in several places – Xcode helped with a Fix-It:

1. For some reason I received a lot of errors for views with a .sheet modifier. The error pairs stated: “Generic parameter ‘Content’ could not be inferred” and “Missing argument for parameter ‘content’ in call”. These messages weren’t very helpful though, so I first tried to replace the .sheet content with just a Text view, but it didn’t help. So I’ve tried turning off the options one by one and the errors disappeared when I turned off ForwardTrailingClosures, so I kept it turned off. I’m hoping that a better error message will be produced by future versions of Swift to fix them later. There’s no hurry, after all. I can retry on Swift 5.9. I didn’t have time to investigate now.

1. I had to mark some of my functions returning a TCA WithViewStore with the @MainActor attribute, but again, Xcode helped with Fix-Its.

1. In many places, warnings were shown stating: “Non-sendable type ‘…’ passed in call to main actor-isolated function cannot cross actor boundary”. So I made these types conform to the Sendable protocol (learn about Sendable here).

All else seemed to build fine for my app RemafoX with ~35k lines of Swift code. The whole process took less than 3 hours of my time.

My project is now ready for the future of Swift 🎉 and I can use the new Regex literal feature (let regex = /.*@.*/). Also, I can’t introduce new code that I have to migrate to Swift 6 later, cause I will receive errors right away. 💯

How about your project? Which upcoming features do you want to migrate to?

extension Binding: Equatable where Value: Equatable {
   static func == (left: Binding<Value>, right: Binding<Value>) -> Bool {
      left.wrappedValue == right.wrappedValue
   }
}

While I wasn’t 100% happy with this solution, it worked fine when I first developed it so I shipped it. But then, with some macOS update a bug started to creep into all Picker views in my app. The pickers still worked most of the time, but sometimes they would behave strangely. The only behavior I could always reproduce was that when I set a selected value to the binding programmatically, and then later the user changed it to another value, it would show both values with a checkmark in the Picker dropdown, which is probably a bug somewhere in SwiftUI:

It took me hours of commenting out code to figure out the root cause, and it turned out to be the Binding extension I mentioned above. Somehow, defining it in my app seems to have influenced the internal implementation of the Picker view in SwiftUI. And knowing that, who knows what other side effects it might have caused or potentially cause in future system updates? So I clearly needed to find a better solution that shouldn’t affect behavior in SwiftUI views.

The reason I wanted to make Binding conform to Equatable was that I had requirements on my data layer, namely some State types in the TCA architecture, that required all data I stored in it to also conform to Equatable. Something like:

struct AppState: Equatable {
   // other properties

   var configFile: Binding<ConfigFile>
}

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

The solution I found is quite simple, although I had to “learn” how to write a property wrapper as it was the first time I needed my own. But it was straight-forward, I believe you’ll understand it even if you haven’t ever written one:

@propertyWrapper
public struct EquatableBinding<Wrapped: Equatable>: Equatable {
   public var wrappedValue: Binding<Wrapped>

   public init(wrappedValue: Binding<Wrapped>) {
      self.wrappedValue = wrappedValue
   }

   public static func == (left: EquatableBinding<Wrapped>, right: EquatableBinding<Wrapped>) -> Bool {
      left.wrappedValue.wrappedValue == right.wrappedValue.wrappedValue
   }
}

The only requirement of the @propertyWrapper is the wrappedValue property, and because I wanted to share this wrapper in my whole modularized application, I also had to write a public initializer, but it’s all straightforward. The == function is the only requirement of the Equatable protocol and it’s also straightforward.

With this, I can now mark all my Binding properties with @EquatableBinding:

struct AppState: Equatable {
   // other properties
   
   @EquatableBinding<ConfigFile>
   var configFile: Binding<ConfigFile>
}

And that’s it, the type AppState now is fully Equatable, the weird dropdown issue is solved, and there’s no risk for any side effects because I’m not conforming any existing types from other frameworks to new protocols. Instead, I just introduced a new type that other frameworks don’t even know about, so they can’t be affected. 🚀

The lesson to learn is to never extend types that you don’t own with protocols that you don’t own. There’s even a Swift proposal to make this a compiler warning. Note that the solution isn’t always a property wrapper. There are many ways to include your own types when conforming to protocols, just don’t forget to do it.

💁🏻‍♂️ What is RemafoX? A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

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

Here is the core approach:

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

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

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

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

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

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

I just migrated my app RemafoX which was built upon The Composable Architecture (TCA) version 0.35.0 to the new 1.0 style of APIs. While the time between the release of 0.35.0 and the current beta of 1.0 spans less than a year, it is important to note that no less than 27 feature releases with sometimes significant changes were made in that short period of time. The Point-Free team really is working in full swing on improving app development for Swift developers, and TCA is the culmination of most of their work. And nearly every topic they discuss in their great advanced Swift video series has some effect on TCA. While they managed to keep all changes pretty much source-compatible up until the current version 0.52.0, the 1.0 release is going to get rid of a lot of older style APIs that were marked as deprecated for some time already.

Because I find it very inefficient to constantly question every decision I made regarding the architecture or conventions of my apps code, I didn’t invest much time in catching up with all the improvements they made to TCA in recent months, although I did keep one eye open to ensure I’m aware of the general direction. But the nearing release of the milestone version 1.0 of the library and the fact that I’m planning to work on some bigger features for RemafoX next make it a good time to reconsider and learn about how to best structure my apps going forward.

Thankfully, the general concept of TCA has not changed at all. But the APIs to describe how features are connected, how navigation should work, how asynchronous work is declared, and even how dependencies are passed along have received significant changes since, all for the better, using the latest Swift features. So there was a lot to figure out and migrate for me and I tackled all of these areas of change at once, but to keep things manageable, I applied the changes module for module to all of the 33 UI features of my app modularized using SwiftPM.

Here are the main takeaways of the migration process up-front:

1. It took me a full work week (~5 days) to complete the migration.

2. My code base has shrunk by 2,500 lines of code, which is a ~7% reduction.

3. A few navigation bugs, threading issues, and SwiftUI glitches are fixed now.

4. My code is much easier to understand, navigate, and reason about.

As for the testing story of my app, all of my tests are actually still passing and I did not have to make any changes to the test code. The reason for that is that I currently only have tests for non-UI features like parsing data, searching for files, or making changes to Strings files – and quite extensive tests in some parts here. But when I considered also writing tests for my UI, I was already months behind my initial timeline of releasing the app and additionally, TCA was still a few weeks away from supporting non-exhaustive testing. So I decided against adding UI tests as I wasn’t really happy with how often one had to make changes to tests just because of some refactoring on the UI layer that didn’t really change the general behavior but required what felt like a rewrite of the related tests because of their exhaustive nature. But with non-exhaustive testing available now, I’m planning on writing UI tests for my app step by step, beginning with the most important ones: My most business-logic-heavy feature, and all my Onboarding features. I might write about this in a future article.

But for now, let’s focus on how I tackled the migration of my app’s code base.

Before the Migration (Case Example)

I think the best way to explain what changes were necessary and also what other changes I did to further streamline things is to show some real-world code. So in the following I will show you how the actual code of my app’s simplest feature looked before the migration and how I evolved it to the new TCA 1.0 style.

The feature is named AppInfo in my code base and looks like this in the app:

The “About RemafoX” screen (Cmd+I).

Before the migration, the features code was split up to 7 different files:

Feature parts: Action, ActionHandler, Error, Event, Reducer, State, and View.

The AppInfoState and AppInfoAction define the data and interactions possible:

import AppFoundation
import AppUI

public struct AppInfoState: Equatable {
   public typealias Action = AppInfoAction
   public typealias Error = AppInfoError

   @BindingState
   var showEnvInfoCopiedToClipboard: Bool = false
   var selectedAppIcon: AppIcon

   var errorHandlingState: ErrorHandlingState?

   public init() {
      self.selectedAppIcon = Defaults[.selectedAppIcon]
   }
}

AppInfoState.swift

import AppFoundation
import AppUI

public enum AppInfoAction: Equatable, BindableAction {
   public typealias State = AppInfoState
   public typealias Error = AppInfoError

   case onAppear
   case onDisappear
   case selectedAppIconChanged
   case copyEnvironmentInfoPressed

   case binding(BindingAction<State>)

   case errorOccurred(error: Error)
   case setErrorHandling(isPresented: Bool)
   case errorHandling(action: ErrorHandlingAction)
}

AppInfoAction.swift

Note that I had always defined typealiases for related parts of the feature I might reference somewhere within the types for convenience, even if I had not actually used them. Also, I had an extra action set<name of child>(isPresented:) whenever I had a child view that I wanted to present via a sheet sometime later. If you’re wondering what those imports of AppFoundation and AppUI are, I’ve explained them in this article. They help reduce the number of imports in my app.

Next, here’s what AppInfoView file looks like:

import AppFoundation
import AppUI

public struct AppInfoView: View {
   public typealias State = AppInfoState
   public typealias Action = AppInfoAction

   let store: Store<State, Action>

   public init(store: Store<State, Action>) {
      self.store = store
   }

   public var body: some View {
      WithViewStore(self.store) { viewStore in
         VStack(alignment: .leading, spacing: 20) {
            VStack(alignment: .center, spacing: 10) {
               viewStore.selectedAppIcon.image
                  .resizable()
                  .aspectRatio(contentMode: .fit)
                  .frame(width: 128, height: 128)
                  .onChange(of: Defaults[.selectedAppIcon]) { newValue in
                     viewStore.send(.selectedAppIconChanged)
                  }

               Text(Constants.appDisplayName)
                  .font(.system(size: 33, weight: .light, design: .rounded))

               Text("Copyright © 2022 Cihat Gündüz")
                  .font(.footnote)
                  .foregroundColor(.secondary)
            }
            .frame(maxWidth: .infinity)

            Divider()

            VStack(alignment: .center, spacing: 10) {
               Text("Environment Info")
                  .font(.headline)

               Text("Provide these info when reporting bugs or use Help menu.")
                  .frame(maxWidth: .infinity, alignment: .leading)
                  .font(.subheadline)
                  .padding(.bottom, 5)

               HStack {
                  Text("App Version:").foregroundColor(.secondary)
                  Spacer()
                  Text(Bundle.main.versionInfo)
               }

               HStack {
                  Text("System Version:").foregroundColor(.secondary)
                  Spacer()
                  Text(ProcessInfo.processInfo.operatingSystemVersionString.replacingOccurrences(of: "Version ", with: ""))
               }

               HStack {
                  Text("System CPU:").foregroundColor(.secondary)
                  Spacer()
                  Text(KernelState.getStringValue(for: .cpuBrandString))
               }

               HStack {
                  Text("Tier:").foregroundColor(.secondary)
                  Spacer()
                  Text(Plan.loadCurrent().tier.displayName)
               }

               Button {
                  viewStore.send(.copyEnvironmentInfoPressed)
               } label: {
                  Label("Copy", systemSymbol: .docOnClipboard)
               }
               .padding(.top, 10)
               .popover(isPresented: viewStore.binding(\.$showEnvInfoCopiedToClipboard), arrowEdge: Edge.top) {
                  Text("Copied!").padding(10)
               }
            }
         }
         .frame(width: 320)
         .padding()
         .onAppear { viewStore.send(.onAppear) }
         .onDisappear { viewStore.send(.onDisappear) }
         .sheet(
            isPresented: viewStore.binding(
               get: { $0.errorHandlingState != nil },
               send: Action.setErrorHandling(isPresented:)
            )
         ) {
            IfLetStore(
               self.store.scope(state: \State.errorHandlingState, action: Action.errorHandling(action:)),
               then: ErrorHandlingView.init(store:)
            )
         }
      }
   }
}

#if DEBUG
   struct AppInfoView_Previews: PreviewProvider {
      static let store = Store(
         initialState: .init(),
         reducer: appInfoReducer,
         environment: .mocked
      )

      static var previews: some View {
         AppInfoView(store: self.store)
      }
   }
#endif

AppInfoView.swift

Note that for presenting a sheet I have to write no less than 11 lines of code and send the action setErrorHandling(isPresented:) back into the system manually. Also, experienced developers might notice that I’m actually using global dependencies in my view code, such as with Plan.loadCurrent(), which doesn’t make my UI code very testable. But I will introduce them as proper dependencies once I start writing tests for UI, so let’s ignore these for now.

The last missing piece of the puzzle for a feature in TCA is the AppInfoReducer:

import AppFoundation
import AppUI

public let appInfoReducer = AnyReducer.combine(
   errorHandlingReducer
      .optional()
      .pullback(
         state: \AppInfoState.errorHandlingState,
         action: /AppInfoAction.errorHandling(action:),
         environment: { $0 }
      ),
   AnyReducer<AppInfoState, AppInfoAction, AppEnv> { state, action, env in
      let actionHandler = AppInfoActionHandler(env: env)

      switch action {
      case .onAppear, .onDisappear:
         return .none  // for analytics only

      case .selectedAppIconChanged:
         return actionHandler.selectedAppIconChanged(state: &state)

      case .copyEnvironmentInfoPressed:
         return actionHandler.copyEnvironmentInfoPressed(state: &state)

      case .binding:
         return .none  // assignment handled by `.binding()` below

      case .errorOccurred, .setErrorHandling, .errorHandling:
         return actionHandler.handleErrorAction(state: &state, action: action)
      }
   }
   .binding()
   .recordAnalyticsEvents(eventType: AppInfoEvent.self) { state, action, env in
      switch action {
      case .onAppear:
         return .init(event: .onAppear)

      case .onDisappear:
         return .init(event: .onDisappear)

      case .copyEnvironmentInfoPressed:
         return .init(event: .copyEnvironmentInfoPressed)

      case .errorOccurred(let error):
         return .init(event: .errorOccurred, attributes: ["errorCode": error.errorCode])

      case .binding, .setErrorHandling, .errorHandling, .selectedAppIconChanged:
         return nil
      }
   }
)

First, note how the appInfoReducer is defined on a global level, which feels wrong already. Next, 7 lines are required to connect the child feature ErrorHandling to this feature. And you’ll notice that I have introduced yet another type named AppInfoActionHandler which seems to hold the actual logic of the reducer. The reason for that is that some of my reducer logic is quite long and if I kept all logic inside the switch-case, I’d have a lot of cases with a lot of code inside. But Xcode doesn’t provide any features to help find and navigate between switch cases. So I’ve extracted that logic to functions in another type. Lastly, you will notice that I have defined an extension to the AnyReducer type itself for analytics purposes:

import ComposableArchitecture

extension AnyReducer {
   /// Returns a `Result` where each action coming to the store first attempts to record an analytics event.
   /// In the implementation, switch over `action` and return an ``Analytics.AttributedEvent`` if the action should be recorded, or else return `nil`.
   public func recordAnalyticsEvents<Event: AnalyticsEvent>(
      eventType: Event.Type,
      event toAttributedEvent: @escaping (State, Action, Environment) -> Analytics.AttributedEvent<Event>?
   ) -> Self {
      .init { state, action, env in
         guard let attributedEvent = toAttributedEvent(state, action, env) else { return self.run(&state, action, env) }

         return .concatenate(
            .fireAndForget { Analytics.shared.record(attributedEvent: attributedEvent) },
            self.run(&state, action, env)
         )
      }
   }
}

AnyReducerExt.swift

All this does is record an event in my Analytics engine powered by TelemetryDeck for the actions that I want to record. I find this very useful as a reminder to always consider for each new action I add to the AppInfoAction enum if I may want to analyze the new event in a fully anonymized way. To make this work properly, I also have to define another type for each feature, here AppInfoEvent:

import AppFoundation

enum AppInfoEvent: String {
   case onAppear
   case onDisappear
   case copyEnvironmentInfoPressed
   case errorOccurred
}

extension AppInfoEvent: AnalyticsEvent {
   var idComponents: [String] {
      ["AppInfo", self.rawValue]
   }
}

AppInfoEvent.swift

This enum defines all events I want to collect, and the idComponents property helps auto-create a String when passing an event name to my Analytics provider. The AnalyticsEvent protocol is a bit off-topic, but if you’re interested it’s just this:

import Foundation

public protocol AnalyticsEvent: Identifiable where ID == String {
   var idComponents: [String] { get }
}

extension AnalyticsEvent {
   public var id: String {
      self.idComponents.joined(separator: ".")
   }
}

AnalyticsEvent.swift (part of a helper module named Analytics)

You might have also spotted an AppEnv type that I use for the environment. This is actually a shared type which I reuse wherever I just need a basic environment type with a mainQueue and which is passed around all over my application:

import CombineSchedulers
import Defaults
import Foundation

public struct AppEnv {
   public let mainQueue: AnySchedulerOf<DispatchQueue>

   public init(mainQueue: AnySchedulerOf<DispatchQueue>) {
      self.mainQueue = mainQueue
   }
}

#if DEBUG
   extension AppEnv {
      public static var mocked: AppEnv {
         .init(mainQueue: DispatchQueue.main.eraseToAnyScheduler())
      }
   }
#endif

Now, the last of the 7 files is AppInfoError and that type is actually empty for this very simple feature. But I will explain its purpose in a later article where I will cover my error-handling approach in great detail. All you need to know for this article is that when something unexpected happens, I want to show a sheet with some helpful information right in the context of a feature.

Point-Free tends to keep all their types in a single file, which might work for a small feature like AppInfo. But a typical feature of mine takes about 500 to 1,500 lines of code with all types combined. I typically tend to keep my files small with a soft cap of 400 lines and a hard cap of 1,000 lines (see SwiftLint rule defaults). With 314 lines even this very simple feature already would come close to the soft cap and some of my features might even get above the hard cap. So keeping it all in one file is a no-go for me. Thus I decided to put each type in its own file instead. But I also never was 100% happy with that, as things seem very all over the place. In the best case, related code would still be together but the feature would still be evenly distributed to fewer files than 7. So, let’s see how things look after the migration.

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

After the Migration (Case Example)

In the TCA 1.0 beta, Point-Free introduced the concept of creating a special struct that serves as the scope or namespace for a feature and they put helping types like State and Action as subtypes into that namespace type. They gave this namespace the name Feature and made it conform to Reducer, which looks something like this:

struct Feature: Reducer {
  struct State: Equatable { … }
  enum Action: Equatable { … }
  
  func reduce(into state: inout State, action: Action) -> Effect<Action> { … }
}

To me, this structure is confusing though for two reasons:

1. Naming the namespace with the suffix Feature while making it conform to Reducer seems off to me. Anywhere a reducer parameter need to be passed, we’d pass a Feature which seems confusing. The namespace then should be named Reducer in the first place, but then, we’d have subtypes accessed through Reducer.State and Reducer.Action, which also isn’t correct.

2. Fully embracing the idea of a feature namespace, I’d expect a type Reducer inside the Feature type for consistency.

Instead, I opted for actually using the Feature as a namespace and also putting a Reducer subtype in it that conforms to Reducer. Well, that would result in struct Reducer: Reducer which is a name clash, let’s solve that with a typealias:

import ComposableArchitecture

public typealias FeatureReducer: Reducer

Now we could define a Reducer: FeatureReducer subtype in our Feature namespace. And while we’re at it, I actually tend to forget to write a public initializer for my reducers (which is required since the app is modularized), so let’s define a new public protocol instead which requires a public initializer:

import ComposableArchitecture

public protocol FeatureReducer: Reducer {
   init()
}

Actually, there are more things I tend to forget about other TCA feature types. Let’s make it all a clear requirement by implementing protocols like FeatureReducer for all kinds of subtypes within a Feature:

import Analytics
import ComposableArchitecture
import ErrorHandling
import SwiftUI

public protocol FeatureState: Equatable {
   var childErrorHandling: ErrorHandlingFeature.State? { get set }
}

public protocol FeatureAction: Equatable {
   associatedtype ErrorType: FeatureError

   static func errorOccurred(_ error: ErrorType) -> Self
   static func childErrorHandling(_ action: PresentationAction<ErrorHandlingFeature.Action>) -> Self
}

public protocol FeatureEvent: AnalyticsEvent {}

public protocol FeatureError: HelpfulError {}

public protocol FeatureReducer: Reducer {
   init()
}

public protocol FeatureView: View {
   associatedtype Action: FeatureAction
}

Excerpt of Feature.swift (part of a helper module)

Note that I require FeatureState and FeatureAction to be Equatable, which is always a good idea in TCA to make them testable and all my state & action types already conform to it anyways. Additionally, I defined a FeatureView accordingly, plus the two extra types I need for my Analytics and Error Handling needs. Note that I also decided to instead of adding the State suffix to all child features as I did with errorHandlingState in the feature previously, I decided to go for the child prefix instead as in childErrorHandling which makes finding child features easier while scanning the attributes from top to bottom.

With these protocols in place, we can now even teach the compiler what a “feature” actually is by defining another protocol that requires all the subtypes:

/// A namespace for a TCA feature with extra requirements for Analytics and Error Handling.
public protocol Feature {
   associatedtype State: FeatureState
   associatedtype Action: FeatureAction
   associatedtype Event: FeatureEvent
   associatedtype Error: FeatureError
   associatedtype Reducer: FeatureReducer
   associatedtype View: FeatureView
}

/// A helper to declare a `Store` of a `Feature` type.
public typealias FeatureStore<F: Feature> = Store<F.State, F.Action>

Excerpt of Feature.swift (part of a helper module)

I also defined a typealias for defining the store in our views similar to the new StoreOf typealias created by Point-Free, but specific to a Feature.

Alright, with this up-front work, let’s see what the migrated Feature looks like:

import AppFoundation
import AppUI

public enum AppInfoFeature: Feature {
   public struct State: FeatureState {
      // see below
   }

   public enum Action: FeatureAction, BindableAction {
      // see below
   }

   public enum Event: String, FeatureEvent {
      // see below
   }

   public enum Error: FeatureError {
      // ...
   }

   public struct Reducer: FeatureReducer {
      // see below
   }

   public struct View: FeatureView {
      // see below
   }
}

extension AppInfoFeature.Event: AnalyticsEvent {
   public var idComponents: [String] {
      ["AppInfo", self.rawValue]
   }
}

Overview of AppInfoFeature.swift

Note that I defined an enum instead of a struct for the Feature to signify that this merely represents a namespace. Next, all of the subtypes conform to exactly what their name is with Feature added as a prefix, e.g. State: FeatureState. This makes it really easy to remember what to conform to and the code more consistent.

Here’s the State body I left out from the code sample above for a better overview:

   public struct State: FeatureState {
      @BindingState
      var showEnvInfoCopiedToClipboard: Bool = false
      var selectedAppIcon: AppIcon

      @PresentationState
      public var childErrorHandling: ErrorHandlingFeature.State?

      public init() {
         self.selectedAppIcon = Defaults[.selectedAppIcon]
      }
   }

This looks pretty similar to the original AppInfoState, but this time the child is renamed from errorHandlingFeature to childErrorHandling. Also because I also migrated the child feature itself, the type changed from ErrorHandlingState? to ErorHandlingFeature.State?. Also, I added the @PresentationState attribute for the new navigation style in TCA 1.0 that supports dismissal from within the child using @Dependency(\.dismiss) and calling self.dismiss() in the Reducer.

Next, let’s take a look at our Action subtype:

   public enum Action: FeatureAction, BindableAction {
      case onAppear
      case onDisappear
      case selectedAppIconChanged
      case copyEnvironmentInfoPressed

      case binding(BindingAction<State>)

      case errorOccurred(Error)
      case childErrorHandling(PresentationAction<ErrorHandlingFeature.Action>)
   }

This is also pretty much a copy of the original AppInfoAction, but note that the child action has now a different type. It changed from HelpfulErrorAction to PresentationAction<HelpfulErrorFeature.Action>, which is a wrapper that puts all child actions into a case named .presented – the other case .dismiss reports back that the child was dismissed in case the parent needs to react to that. Thanks to PresentationAction, I could completely get rid of the action setErrorHandling(isPresented:) as this is now encapsulated in TCA-provided types.

Let’s now take a look at what our View looks like:

   public struct View: FeatureView {
      let store: FeatureStore<AppInfoFeature>

      public init(store: FeatureStore<AppInfoFeature>) {
         self.store = store
      }
   }

As you can see, I’m using the FeatureStore typealias instead of the old style Store<State, Action> or the TCA 1.0 style StoreOf<Feature>. But where’s everything else that defines a SwiftUI View like the body property? Well, the implementation of a view typically is one of the longest parts of a feature, so while I opted to keep the structural parts of all subtypes in one place, conformances to protocols that require a lot of code I extracted to extension files.

The implementation of the View is in a separate file as an extension:

import AppFoundation
import AppUI

extension AppInfoFeature.View: View {
   public typealias Action = AppInfoFeature.Action

   public var body: some View {
      WithViewStore(self.store, observe: { $0 }) { viewStore in
         VStack(alignment: .leading, spacing: 20) {
            // same code as before
         }
         .frame(width: 320)
         .padding()
         .onAppear { viewStore.send(.onAppear) }
         .onDisappear { viewStore.send(.onDisappear) }
         .sheet(store: self.store.scope(state: \.$childErrorHandling, action: Action.childErrorHandling)) { childStore in
            HelpfulErrorFeature.View(store: childStore)
         }
      }
   }
}

#if DEBUG
   struct AppInfoView_Previews: PreviewProvider {
      static let store = Store(initialState: AppInfoFeature.State(), reducer: AppInfoFeature.Reducer())

      static var previews: some View {
         AppInfoFeature.View(store: self.store).previewVariants()
      }
   }
#endif

AppInfoFeatureView.swift*

The implementation of the body property is pretty much the same as before. But note that the 11 lines .sheet modifier has shrunk to just 3 lines. This is thanks to the new navigation tools using @PresentationState and PresentationAction. Another change happened to the static let store inside the PreviewProvider: There’s no environment parameter to pass to the Store anymore!

Let’s take a look at the Reducer subtype to learn why this is:

   public struct Reducer: FeatureReducer {
      @Dependency(\.mainQueue)
      var mainQueue

      @Dependency(\.continuousClock)
      var clock

      public init() {}
   }

Note the usage of the @Dependency attribute. It might remind you of the @Environment attribute in SwiftUI, and it actually works exactly the same. This new attribute is why there’s no Environment type needed anymore in TCA 1.0. Instead, all dependencies are declared using the @Dependency attribute. This allows me to entirely get rid of the AppEnv type I had passed around before.

Yet again, you might be missing the actual implementation of the Reducer protocol. Well, the implementation of the protocol is the second portion of code in a feature that can get pretty long, so I also opted to extract that to its own file:

import AppFoundation
import AppUI

extension AppInfoFeature.Reducer: Reducer {
   public typealias State = AppInfoFeature.State
   public typealias Action = AppInfoFeature.Action

   enum ShowEnvInfoCopiedId {}

   public var body: some ReducerOf<Self> {
      AnalyticsEventRecorderOf<AppInfoFeature> { state, action in
         switch action {
         case .onAppear:
            return .init(event: .onAppear)

         case .onDisappear:
            return .init(event: .onDisappear)

         case .copyEnvironmentInfoPressed:
            return .init(event: .copyEnvironmentInfoPressed)

         case .errorOccurred(let error):
            return .init(event: .errorOccurred, attributes: ["errorCode": error.errorCode])

         case .binding, .childErrorHandling, .selectedAppIconChanged:
            return nil
         }
      }

      BindingReducer()

      Reduce<State, Action> { state, action in
         switch action {
         case .onAppear, .onDisappear:
         return .none  // for analytics only

      case .selectedAppIconChanged:
         return self.selectedAppIconChanged(state: &state)

      case .copyEnvironmentInfoPressed:
         return self.copyEnvironmentInfoPressed(state: &state)

      case .binding:
         return .none  // assignment handled by `BindingReducer()` above

      case .errorOccurred, .childErrorHandling:
         return self.handleHelpfulErrorAction(state: &state, action: action)
         }
      }
      .ifLet(\.$childErrorHandling, action: /Action.childErrorHandling) {
         HelpfulErrorFeature.Reducer()
      }
   }
   
   private func selectedAppIconChanged(...)
   
   private func copyEnvironmentInfoPressed(state: inout State) -> Effect<Action> {
      Pasteboard.string = Constants.GitHub.environmentInfo
      state.showEnvInfoCopiedToClipboard = true

      return .run { send in
         try await self.clock.sleep(for: Constants.toastMessageDuration)
         try Task.checkCancellation()
         await send(.set(\.$showEnvInfoCopiedToClipboard, false))
      }
      .cancellable(id: ShowEnvInfoCopiedId.self, cancelInFlight: true)
   }
   
   private func handleHelpfulErrorAction(...)
}

AppInfoFeatureReducer.swift*

Note first the entirely different structure. No global reducer variables are needed anymore. Instead, a body property is implemented, very much like with the View protocol in SwiftUI. And the analogy doesn’t end there, the structure is also very SwiftUI-like with a mere list of different reducers that together build the AppInfoFeature.Reducer, including one called BindingReducer() which replaces .binding(). Also note that the 7 lines of code connecting the child feature have shrunk down to just 3 lines using the new .ifLet API. Additionally, instead of having to define a custom ActionHandler type where I put the implementation of the logic to react upon actions, because we are now in a type and not a global level, I could easily move those functions into the Reducer type itself. Also, the implementation of copyEnvironmentInfoPressed is using the new async style APIs. Previously, it was implemented using the less readable Combine style:

      Pasteboard.string = Constants.GitHub.environmentInfo
      state.showEnvInfoCopiedToClipboard = true

      return .init(value: .set(\.$showEnvInfoCopiedToClipboard, false))
         .delay(for: Constants.toastMessageDuration, scheduler: env.mainQueue)
         .eraseToEffect()
         .cancellable(id: ShowEnvInfoCopiedId.self, cancelInFlight: true)

Excerpt from the old AppInfoActionHandler.swift

Lastly, due to the new SwiftUI-like function builder style, I had to change my AnyReducer extension function recordAnalyticsEvents to simply being a Reducer that stores the execution logic as a property like so:

import ComposableArchitecture
import Foundation

/// Returns a `Reducer` where each action coming to the store attempts to record an analytics event.
public struct AnalyticsEventRecorder<State, Action, Event: AnalyticsEvent>: Reducer {
   let toAttributedEvent: (State, Action) -> Analytics.AttributedEvent<Event>?

   /// In the event closure, switch over `action` and return an ``Analytics.AttributedEvent`` if the action should be recorded, or else return `nil`.
   public init(event toAttributedEvent: @escaping (State, Action) -> Analytics.AttributedEvent<Event>?) {
      self.toAttributedEvent = toAttributedEvent
   }

   public func reduce(into state: inout State, action: Action) -> Effect<Action> {
      if let attributedEvent = self.toAttributedEvent(state, action) {
         Analytics.shared.record(attributedEvent: attributedEvent)
      }

      return .none
   }
}

/// Convenient way to declare an `AnalyticsEventRecorder`, but requires `Reducer` to conform to `Feature`.
public typealias AnalyticsEventRecorderOf<F: Feature> = AnalyticsEventRecorder<F.State, F.Action, F.Event>

AnalyticsEventRecorder.swift (from a helper module)

The body of the analytics helper in the Reducer above didn’t change at all, I just copied it over from the previous helper function into this new reducers initializer.

And that’s all, the entire AppInfo feature is migrated over to TCA 1.0. The overall file structure now looks like this, with just 3 files instead of 7:

Note that I’m using * as a separator for signaling that the file contains the main portion of a subtype. Naturally, we could use . as a separator making the name read like AppInfoFeature.Reducer.swift. But because .R from .Reducer is sorted above .s from .swift, this would result in the subtypes files appearing above the main feature file AppInfoFeature.swift, so I opted for a separator that looks similar to a dot but has lower precedence than . which lead to *.

The SwiftLint rule file_name which I opted in to showed me a warning with this naming style. But I could easily adjust that by adding this to the config file:

file_name:
   nested_type_separator: '*'

Conclusion

Migrating my medium-sized app to the new TCA 1.0 style of APIs was a lot of work, but most of it was setting up file structures, doing search & replace, and moving existing code to other places. And I invested quite some of my time into figuring out a good structure that I liked. I think if I had to do it again for another app with my learnings, I’d probably be done in 2-3 days rather than 5.

Only in a few places I had to actually adjust code, mostly when migrating Combine-style effect code in my reducers to async-await style code. But thanks to great documentation and warnings, it was always pretty clear what to do. For everyone doing a similar migration, here are the 3 links I found most useful:

1. Concurrency Beta

2. Migrating to the Reducer protocol

3. Composable Navigation Beta

Also, if there’s one episode that gives a good overview of the advancements in TCA 1.0, it’s the first ~35 minutes of episode #222 which kicks off Composable Navigation. Watch it to quickly get an idea of how things changed in the past year.

I recently decided to work on the biggest feature for RemafoX to date and while I was thinking about where to start, I found myself drowning in over 70 targets for my less-than-one-year-old project. Note that I’m modularizing my app for clear code segregation and faster build times (= faster SwiftUI previews, tests & more) using the vanilla SwiftPM-based method presented by Point-Free in this free episode. Because I plan on working on this app for years to come (the 27 features online are just the tip of the iceberg, I have many more ideas), I’ve decided to first clean up this mess. After all, a round of refactoring between features keeps the code base clean and makes the developer happy! 😇

I remembered that I had discovered the @_exported attribute while reading through Swift Evolution threads when preparing one of the issues of my related newsletter. While it’s not recommended to use underscored APIs as their behavior might change or they might even potentially get entirely removed, I found myself lacking alternatives with my goal of cleaning up the many unorganized targets. For exactly this reason, I convinced myself that the chances of this attribute getting entirely removed were relatively low. If anything, I believe that the related pitch might get picked up some time and finds its way into official Swift, so we can replace @_exported with whatever it could be named then. Also, I found out that Point-Free is depending on this attribute as well in The Composable Architecture framework, which my app heavily depends on already. So why not go all-in on it?

In short, what the attribute helps with is this: Imagine you have 10 feature modules and 5 helper modules. In each file of the 10 features, I tend to import all (or most) of these 5 helper modules, which results in something like this:

import Assets
import Analytics
import ComposableArchitecture
import Constants
import Defaults
import HandySwift
import HelpfulErrorUI
import ReusableUI
import SFSafeSymbols
import SwiftUI
import Utility

And this gets repeated over and over again. Ok, it’s true that not all of them are needed in every single file of a target, but the truth is also that Xcode is linking the entire module anyway when only a single file in the module imports it, so importing them all in all files wouldn’t hurt build times (AFAIK). Using @_exported import we can combine all these imports by creating a new target, call it something like CoreDependencies and create a Swift file in it with this content:

@_exported import Assets
@_exported import Analytics
@_exported import ComposableArchitecture
@_exported import Constants
@_exported import Defaults
@_exported import HandySwift
@_exported import HelpfulErrorUI
@_exported import ReusableUI
@_exported import SFSafeSymbols
@_exported import SwiftUI
@_exported import Utility

Now, whenever we import CoreDependencies, it will import all other modules, too!

But is putting everything into one group called CoreDependencies really the right solution? Another problem apart from having to repeat the imports too often is that I’m currently sorting all these 70 modules alphabetically due to the lack of another kind of grouping or structure. This lack of grouping doesn’t only make it harder to find the right module when I roughly know what I’m looking for but don’t remember the exact name of the module. It can also lead to circular dependencies while working on features and trying to reuse as much code as possible. It requires strategic planning of what belongs where to allow reusing code while preventing cyclic dependencies which lead to compiler errors.

The Solution

✨ UPDATE: For new/smaller apps, I use a simplified solution of what I describe in detail below. See my FlineDevKit repository for more.

The best way to find a practical solution to a problem is to look at a real-world example. So, here’s a selection of modules I actually use in RemafoX:

Analytics
Assets
BetterCodable
CommandLineSetup
ComposableArchitecture
Constants
FilesSearch
Foundation
HandySwift
HelpfulErrorUI
MachineTranslation
Paywall
ProjectsBrowser
ReusableUI
SFSafeSymbols
Settings
SwiftUI
Utility

Yes, I’ve also listed Foundation and SwiftUI in the list above. Why? Because at the end of the day, they are dependencies that need to be imported as well, just like any other dependency we import, be it an external or internal dependency. I view them as built-in external dependencies. You might be used to at least import Foundation in any Swift file, but actually, you can write Swift code without Foundation, you’ll just have the barebones Swift features then including everything contained in the Swift Standard Library. It totally works!

And actually, these two imports that we all made so often represent an Apple-internal grouping of features/helpers: Apple groups a whole bunch of functionality behind Foundation, and they do the same with SwiftUI or UIKit/AppKit. The deciding factor seems to be that everything that represents some kind of UI or is directly related to UI belongs to one group, and everything that doesn’t represent a UI or isn’t directly related to UI into another group. So, the most natural thing we could do is to follow their lead, we could even copy their naming by using Foundation for the non-UI group and UI (which appears in both SwiftUI and UIKit) for the UI group. Because our groups are specific to an apps domain, the resulting names for our groups would be: AppFoundation and AppUI.

Let’s apply this to the list of modules above:

// AppFoundation
Analytics
BetterCodable
CommandLineSetup
Constants
FilesSearch
Foundation
HandySwift
MachineTranslation
Utility

// AppUI
Assets
ComposableArchitecture
HelpfulErrorUI
Paywall
ProjectsBrowser
SFSafeSymbols
ReusableUI
Settings
SwiftUI

This already starts to look better. But there’s one more thing we can learn from how Apple structures its frameworks: Apple doesn’t link each and every non-UI feature as part of Foundation, nor do they ship all SwiftUI-related code as part of SwiftUI. Combine and Charts are two frameworks we need to import separately. Why not ship them as part of Foundation and SwiftUI? Because they are useful only in some specific domains and might not be needed in a more global scope.

If you remember the initial problem, it was that I had a set of modules that I imported over and over again in many places because they were useful helpers in a global manner, rather than being useful only in some specific domains. So it makes sense to import them as part of a unified group name. But what actually is a helper? What differentiates it from a more domain-specific feature?

I personally call a feature a “helper” or a “utility” feature, when its global availability is much more useful than it hurts the development process. Of course, this is somewhat subjective but as a rule of thumb I do this: If I already use the feature in multiple different parts of my app, plus when thinking about 2 or 3 potential new features I might add to my app sometime in the future and at least one of them could also make use of it, then it’s probably very useful globally.

In more practical terms, I would separate the above list of modules like this:

// (globally useful) Helpers
Analytics
Assets
BetterCodable
ComposableArchitecture
Constants
Foundation
HandySwift
HelpfulErrorUI
ReusableUI
SFSafeSymbols
SwiftUI
Utility

// (domain-specific) Features
CommandLineSetup
FilesSearch
MachineTranslation
Paywall
ProjectsBrowser
Settings

If we now combine the two dimensions of separation, we end up with something like the following graph with 4 quarters & dependencies in between:

Here are a few important things to note:

1. The ⬆️ top “Feature” half is built on top of the bottom “Helpers” half, thus:

2. The ↖️ green “Non-UI Features” modules can import AppFoundation.

3. The ↗️ red “UI Features” modules can import both, AppFoundation & AppUI.

4. Within a group (quarter), modules can depend on each other (prevent cycles!).

5. ➡️ “UI” modules can depend on ⬅️ “Non-UI” modules or on AppFoundation.

6. The ⬇️ bottom “Helpers” are never allowed to import from “Features” above!

7. External modules can also be “Features” (see ↖️, currently I have none in ↗️)

To apply this structure, I just created a new module named AppFoundation, plus a new Swift file in it named AppFoundation.swift with the following contents:

// System
@_exported import Foundation

// Internal
@_exported import Analytics
@_exported import Constants
@_exported import Utility

// External
@_exported import BetterCodable
@_exported import HandySwift

I also created a module AppUI with the following contents for AppUI.swift in it:

// System
@_exported import SwiftUI

// Internal
@_exported import Assets
@_exported import HelpfulErrorUI
@_exported import ReusableUI

// External
@_exported import ComposableArchitecture
@_exported import SFSafeSymbols

Now I can replace the 11 imports from the initial example at the beginning of this article, that I took from a file inside a UI Feature module, with just these 2 lines:

import AppFoundation
import AppUI

11 imports were reduced to just 2 thanks to the @_exported attribute.

Note that I didn’t even have to import Foundation or SwiftUI. And for any Non-UI Feature I even just need a single line stating import AppFoundation!

Of course, this doesn’t mean I won’t ever import anything else anymore. I’ll still be having imports on the vertical axis, where a specific module imports another specific module inside a group, e.g. a ConfigFile UI feature importing child components like ConfigFileLinter and ConfigFileNormalizer. But these are domain-specific imports and don’t lead to many repetitive imports.

The last thing I did was group my products, my dependencies, and targets in my Package.swift file by these 4 quarters. For this, I added pragma marks like // MARK: - Non-UI Features in all sections and put the related statements into them in alphabetic order. My resulting manifest now looks something like this:

import PackageDescription

let package = Package(
   name: "RemafoX",
   platforms: [.macOS(.v12)],

   // MARK: - Products
   products: [
      // MARK: - Grouping Products
      .library(name: "AppFoundation", targets: ["AppFoundation"]),
      .library(name: "AppUI", targets: ["AppUI"]),
      .library(name: "AppTest", targets: ["AppTest"]),

      // MARK: - Non-UI Helper Products (AppFoundation)
      .library(name: "Analytics", targets: ["Analytics"]),
      .library(name: "Constants", targets: ["Constants"]),
      .library(name: "Utility", targets: ["Utility"]),

      // MARK: - UI Helper Products (AppUI)
      .library(name: "Assets", targets: ["Assets"]),
      .library(name: "HelpfulErrorUI", targets: ["HelpfulErrorUI"]),
      .library(name: "ReusableUI", targets: ["ReusableUI"]),

      // MARK: - Test Helper Products (AppTest)
      .library(name: "TestResources", targets: ["TestResources"]),

      // MARK: - Non-UI Feature Products
      .library(name: "CommandLineSetup", targets: ["CommandLineSetup"]),
      .library(name: "FilesSearch", targets: ["FilesSearch"]),
      .library(name: "MachineTranslation", targets: ["MachineTranslation"]),

      // MARK: - UI Feature Products
      .library(name: "Paywall", targets: ["Paywall"]),
      .library(name: "ProjectsBrowser", targets: ["ProjectsBrowser"]),
      .library(name: "Settings", targets: ["Settings"]),
   ],

   // MARK: - Dependencies
   dependencies: [
      // MARK: - Non-UI Helper Dependencies (AppFoundation)
      .package(url: "https://github.com/marksands/BetterCodable.git", from: "0.4.0"),
      .package(url: "https://github.com/sindresorhus/Defaults", from: "6.3.0"),
      .package(url: "https://github.com/FlineDev/HandySwift", branch: "main"),

      // MARK: - UI Helper Dependencies (AppUI)
      .package(url: "https://github.com/SFSafeSymbols/SFSafeSymbols", from: "3.3.0"),
      .package(url: "https://github.com/pointfreeco/swift-composable-architecture", from: "0.40.2"),

      // MARK: - Test Helper Dependencies (AppTest)
      .package(url: "https://github.com/pointfreeco/swift-custom-dump", from: "0.3.0"),

      // MARK: - Non-UI Feature Dependencies
      .package(url: "https://github.com/FlineDev/Microya", branch: "main"),
      .package(url: "https://github.com/JohnSundell/Splash.git", from: "0.16.0"),
      .package(url: "https://github.com/jakeheis/SwiftCLI.git", from: "6.0.3"),
      .package(url: "https://github.com/TelemetryDeck/SwiftClient", branch: "main"),

      // MARK: - UI Feature Dependencies
   ],

   // MARK: - Targets
   targets: [
      // MARK: - Grouping Targets
      .target(
         name: "AppFoundation",
         dependencies: [
            // Internal
            "Analytics",
            "Constants",
            "Utility",

            // External
            .product(name: "BetterCodable", package: "BetterCodable"),
            .product(name: "HandySwift", package: "HandySwift"),
         ]
      ),
      .target(
         name: "AppUI",
         dependencies: [
            // Internal
            "Assets",
            "HelpfulErrorUI",
            "ReusableUI",

            // External
            .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
            .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
         ]
      ),
      .target(
         name: "AppTest",
         dependencies: [
            // Internal
            "TestResources",

            // External
            .product(name: "CustomDump", package: "swift-custom-dump"),
         ]
      ),

      // MARK: - Non-UI Helper Targets (AppFoundation)
      .target(
         name: "Analytics",
         dependencies: [
            // Internal
            "Constants",

            // External
            .product(name: "HandySwift", package: "HandySwift"),
            .product(name: "TelemetryClient", package: "SwiftClient"),
         ]
      ),
      .testTarget(name: "AnalyticsTests", dependencies: ["AppTest", "Analytics"]),
      .target(
         name: "Constants",
         dependencies: [
            .product(name: "Defaults", package: "Defaults"),
            .product(name: "HandySwift", package: "HandySwift"),
         ]
      ),
      .target(
         name: "Utility",
         dependencies: [
            // Internal
            "Analytics",
            "Constants",

            // External
            .product(name: "HandySwift", package: "HandySwift"),
            .product(name: "Defaults", package: "Defaults"),
         ]
      ),
      .testTarget(name: "UtilityTests", dependencies: ["AppTest", "Utility"]),

      // MARK: - UI Helper Targets (AppUI)
      .target(
         name: "Assets",
         dependencies: [.product(name: "Defaults", package: "Defaults")],
         resources: [
            .process("Colors.xcassets"),
            .process("Images.xcassets"),
            .copy("Sounds"),
         ]
      ),
      .target(
         name: "HelpfulErrorUI",
         dependencies: [
            // Internal
            "AppFoundation",
            "Assets",
            "ReusableUI",
         ]
      ),
      .target(
         name: "ReusableUI",
         dependencies: [
            // Internal
            "AppFoundation",
            "Assets",

            // External
            .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
            .product(name: "Splash", package: "Splash"),
            .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
         ]
      ),

      // MARK: - Test Helper Targets (AppTest)
      .target(
         name: "TestResources",
         dependencies: [],
         path: "TestResources",
         exclude: ["Package.swift"],
         sources: ["TestResources.swift"],
         resources: [
            .copy("CustomSample"),
            .copy("EmptyFileStructureSamples"),
            .copy("GitHubSampleProjects"),
         ]
      ),

      // MARK: - Non-UI Feature Targets
      .target(name: "CommandLineSetup", dependencies: ["AppFoundation"]),
      .target(
         name: "MachineTranslation",
         dependencies: [
            // Internal
            "AppFoundation",

            // External
            .product(name: "Microya", package: "Microya"),
         ]
      ),
      .testTarget(
         name: "MachineTranslationTests",
         dependencies: ["AppFoundation", "AppTest", "MachineTranslation"],
         exclude: ["Resources/secrets.json.sample"],
         resources: [.copy("Resources/secrets.json")]
      ),

      // MARK: - UI Feature Targets
      .target(name: "Paywall", dependencies: ["AppFoundation", "AppUI"]),
      .target(
         name: "ProjectSetup",
         dependencies: [
            "AppFoundation",
            "AppUI",
            "ProjectDragAndDrop",
            "ProjectAnalyzer",
         ]
      ),
      .target(
         name: "Settings",
         dependencies: [
            "AppFoundation",
            "AppUI",
            "SettingsTabCurrentPlan",
            "SettingsTabGeneral",
            "SettingsTabMachineTranslation",
         ]
      ),
      // ... many more features related to Project, Settings etc.
   ]
)

☑️ Similar to AppFoundation and AppUI, I also introduced an AppTest grouping target to my app which I use to unify imports of XCTest and dependencies/helpers like CustomDump (highly recommended!).

To replace all relevant imports with AppFoundation/AppUI, I used this trick:

1. First, I used Xcodes Find & Replace for every @_exported lib and replaced all imports with AppFoundation, so I ended up with a lot of files with multiple imports of AppFoundation.

2. Next, I used the SwiftLint rule duplicate_imports which supports auto-correction. Install it via brew install swiftlint, then run these 3 lines:

echo "only_rules: [duplicate_imports]" > temp_swiftlint.yml
swiftlint lint --config temp_swiftlint.yml --path Sources --autocorrect
rm temp_swiftlint.yml

Adjust the parameter passed to –path if yours is different than Sources.

1. Lastly, I reverted the changes for files that lie inside modules which are themselves part of AppFoundation using Git, also AppFoundation.swift itself.

2. Then I repeated the above steps for AppUI. It all took less than 10 minutes!

That’s it! As you can see, before cleaning up I had ~2,000 imports in my project:

After the cleanup, I have now only 1,200 imports, roughly 40% less than before!

Also, my Package.swift manifest file got a lot shorter, from 827 lines to 575 lines, that’s roughly a third less. And it’s all so much more structured, I’m happy! 😍

Conclusion

Thanks to @_exported import and separation of modules into four groups by asking if they are (A) “UI-related” or “Non-UI-related”, and (B) more “globally useful” or more “domain-specific”, I can now import an infinite number of “Helper” modules into my “Feature” modules with just one or two import lines! Not only that, but these groups with their import rules also serve as a guide to easily place my code into the right module to prevent circular dependencies.

The result: Less code to write, fewer chances for build errors – a win-win!

In the end, I also answer some frequently asked questions:

• Apple Silicon or Intel?

• How much disk space do I need?

• How much RAM do I need?

• What about the Mac Studio?

This article was last updated in December 2024. If 6 months have passed since then, ping me on Bluesky & remind me to update.

The Cheapest Mac for Developers ($750+)

Hardware:

M4 Mac Mini (16GB RAM & 256GB SSD) for $600

• monitor (at least $120)

• wireless mouse & keyboard (at least $30)

Pros:

• Fast build times with future-proof M4 Apple Silicon processor

• Fast SSD for opening Xcode projects quickly (many small files)

• Cheapest overall option with a total price (including periphery) of ~$750

• Built-in ports, no adapter needed (5x USB-C, HDMI, LAN, 3.5mm)

Cons:

• Immobile (not a Laptop)

• Requires additional periphery (mouse, keyboard, monitor)

• 256 GB SSD is barely enough for development, no space for other media

Upgrade Options

• Get 512GB SSD if you plan to use it for other purposes as well (+$200)

• OR buy a 2TB external SSD for a slightly lower price (for media only)

• Get the 24” iMac for a 4.5K monitor, Apple mouse & keyboard (+$550)

Recommended Group

When money is the main concern, e.g. this is just a hobby for you, and you know you’re going to be coding from a fixed place. Or if you want to use the Mac as a media server as well for your home (with an external hard drive).

The Cheapest Mobile Mac for Devs ($1,000+)

Hardware:

13” M4 MacBook Air (16GB RAM & 256GB SSD) for $1,000

Pros:

• Fast build times with good-enough M4 Apple Silicon processor

• Fast SSD for opening Xcode projects quickly (many small files)

• Mobile (Laptop with 13” built-in screen, keyboard & trackpad)

Cons:

• More expensive than the Mac mini (even with peripherals included)

• Using an external hard drive instead of upgrading SSD is not viable

• You will need to buy and take with you a USB-C adapter for compatibility

• 256 GB SSD is barely enough for development, no space for other media

Upgrade Options

• Get 512GB SSD if you plan to use it for other purposes as well (+$200)

Recommended Group

When money is a concern but you need a Laptop anyways, e.g. because you’re a student, and you want to be flexible and take it always with you.

The Best Value Mac for Developers ($2,500+)

Hardware:

16” M4 Pro MacBook Pro (24GB & 512GB) for $2,500

Pros:

• 14-core M4 Pro with another ~50% faster build times (compared to M4)

• Larger & higher quality 4K, 120Hz, HDR screen (compared to Air)

• Longest battery life in any Mac ever (longer than M4 Max or 14” variants)

• Built-in card-reader and HDMI port & 1 extra USB-C (compared to Air)

• Fast 512GB SSD for opening Xcode projects quickly (many small files)

• Extra 8 GB RAM headroom for more advanced developer workflows

• Mobile (Laptop with 16” built-in screen, keyboard & trackpad)

Cons:

• Quite expensive (saved built time worth it if coding professionally)

Upgrade Options

• Get 1TB SSD if you want to have some extra headroom (+$200)

• Get M4 Max for 20% faster CPU, 48GB RAM, 1TB SSD, faster GPU (+$1,500)

Recommended Group

When build performance is your main concern (= professional developers) and you don’t want to waste any money on small improvements, get this.

If you prefer the 14” form factor for $2,200 (don’t forget to upgrade to 14-core CPU!), that is similarly recommendable but comes with some smaller drawbacks such as a shorter (but still amazing) battery life and louder (but still very silent) fans for just $100 of savings. Then better choose the base 14” model which costs $500 less ($2,000) but be aware that this comes with a 10% slower 12-core CPU.

Frequently Asked Questions

Some frequently asked hardware questions and my personal take on them.

Apple Silicon or Intel?

A more realistic minimum calculation therefore is:

• 40 GB for macOS

• 80 GB for 2 versions of Xcode installed at the same time

• 20 GB for having 4 SDK versions installed at the same time

• 30 GB for build artifacts of 3 different projects at the same time

• 20 GB for other development-related apps and tools

• 50 GB for other apps (Pages, Numbers, Notion, Slack, Zoom, etc.)

That adds up to 240 GB, so a 256 GB SSD is just enough to do serious iOS development. But this only works if you exclusively do iOS development on this Mac and don’t use it to sync your iPhone photos or videos on it, for example. If you want to use the Mac for other uses as well, get at least 512 GB SSD. This will also give you the headroom to try out other technologies, like installing Android Studio to try out Android development as well.

How much RAM do I need?

Short answer: At least 16 GB, better 24GB+.

Long answer:
8GB is a good start if you already own a Mac and you should be able to run a single Simulator plus Safari with many tabs easily on it without many hiccups. But as soon as your project gets larger and you start doing two things at once and maybe even have a server or VM running in the background, you’ll be limited by the RAM.

And if you consider ever doing Android development on the machine, too, you definitely need the 16GB option because (unlike iOS Simulators) the Android Emulator can’t efficiently share RAM with the host system.

While the difference is very noticeable when comparing 8GB to 16GB, the differences are much smaller when going from 16GB to 24GB or higher. Matt Gallagher recently wrote a good comparison on Twitter, ending with the final note: “Don’t choose RAM over faster CPU”. I totally agree with that.

Thankfully, since 2024, all new Macs have at least 16 GB, so you should be good.

What about the Mac Studio?

Short answer: Wait for the M4 Ultra Mac Studio, if you can afford it. It’s a beast.

Long answer:
The current Mac Studio machines are in a weird spot, still running on M2 Max and M2 Ultra chips. The current M4 Pro is ~33% faster than the M2 Max, and the M4 Max is ~7% faster than the M4 Ultra for development tasks. So it’s currently not a good idea to buy any of the Mac Studio machines. Instead, if you like the form factor, just get a M4 Pro Mac Mini (make sure to upgrade to the 14-core CPU!) at a cost of $1,600 ($400 less than the M2 Max Mac Studio).

The base Mac Studio for $2,000 has a 33% slower 12-core CPU than the best-value MacBook Pro recommended above. You can of course get it to save $500 if you don’t need the MacBook’s amazing screen, speaker system, and mobility. But then you need to pay for a monitor, mouse & keyboard which (as we’re at the professional level here) can cost you about the same unless you have them.

The M2 Ultra variant for $4,000 used to be the more interesting device here because it had twice the CPU cores and came with yet again faster build times compared to the Max chips. If money isn’t a concern to you but performance is, feel free to wait for the M4 Ultra and get it for the fastest possible builds.

Features

This first release is already jam-packed with many features that’ll help you:

• Focus: Don’t ever leave the context of your Swift file – keep coding

• Be Faster: No longer manually edit Strings files when adding new keys

• Automate: Set up DeepL or Microsoft Translator to translate your app

• Lint: Get warnings in Xcode for empty translations or duplicate keys

• Normalize: Strings files sorted alphabetically to help find translations

• Synchronize: Auto-update Strings files on Storyboard/XIB file changes

• Learn: Lots of explanations, step-by-step guides, and even videos

• Pluralize: Auto-detection & language-aware form for easy pluralization

Roadmap

But that’s just the beginning. Each month, a new feature will be added, like:

• Fastlane support: Translate App Store description & “What’s New”

• Verification: Easy way of inviting others to check/provide translations

• Strings editor: A special UI to make edits on Strings(dict) files nicer

• Google Translate & Yandex: Support for more translation services

• Open Source: Support the community by making Pro features Free

• … and much more – [explore & vote on features or request your own](https://github.com/FlineDev/ReMafoX/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+Request%22+sort%3Areactions-%2B1-desc&ref=fline.dev)!

Previews

Still not convinced? Then check out the following 3 GIFs showcasing RemafoX:

Add a new translation to a project in many languages with just one step:

Find empty translations in Strings files and use machine translation:

Set up a project in RemafoX and customize with documented config options:

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Special Offer

Purchase a lifetime subscription today to **save ~30% **with the Early Bird discount running til the end of October. Monthly or yearly subscriptions support the continued development of this project and come all with a Free Trial period. So you can see for yourself how ReMafoX improves your developer workflow.

But there’s also a Free tier for smaller projects including all of the above features except pluralization. I promise that I will never remove any features from the Free tier, so if this tier works for you today, it will always do! And most of the planned features will benefit the Free tier as well.

Get Started Now!

So there should really be no reason not to use RemafoX! Get it now:

‎ReMafoX: Easy App Localization

If you come across any issues or have questions, please consult the ‘Help’ menu.

While the first “Dub Dub” — that’s how most who have once attended the event in person like to refer to it — was actually a closed event with an NDA to be signed because they showed off a new product up-front to developers, it opened up the following year, and has been open to developers to attend since. At least for those who can pay a fee of ~$1,600, can afford a one-week trip to California, and were lucky enough to win the lottery as tickets were limited.

But because such large conferences were unthinkable in 2020 due to the COVID-19 pandemic, Apple had to do something different and since then, WWDC truly holds up to its name and actually is attendable by all developers worldwide — for free! While this is the positive side of things, of course it’s a different experience to attend an online conference than an in-person one. So this year, they are trying a mixed approach with a Special Event at Apple Park for a lucky few, but the conference itself is open to everyone worldwide still.

With these changes in place and the yearly conference potentially staying in this online format, let’s take a look at the three key aspects of the conference and how we can make the most of it for each of them if we can offer the time:

• Learning about the newest Apple technologies

• Connecting with other Developers & having a good time

• Discussing the impact of new technologies, features & products

Learning

Apple

What learning opportunities Apple offers officially throughout the week.

Keynote & Platforms State of the Union
The WWDC Keynote is where Apple presents the latest software and product updates to the public. It’s not specifically targeted at developers, but it does include a short developer section towards the end, and big announcements like Swift in 2014 or SwiftUI in 2019 have all been unveiled here (watch the linked sections & listen to the crowd to get excited about this year’s keynote!).

The Platforms State of the Union is also called the “Developer Keynote” for a reason. It’s basically unveiling and demoing all the new amazing APIs much like the keynote is unveiling and demoing all the new products & services. It’s targeted specifically at developers so they can go into more detail and if there’s a single video you have time to watch for the whole WWDC, this is the one I would recommend because it’s like a summary of the rest of the week. It’s also a great way to find topics you’re interested in. All technologies mentioned here have dedicated sessions throughout the week.

Sessions
The more than 200 session videos form the core of WWDC and are the best place to learn about the latest technologies in more detail. A good place to watch them is the dedicated Developer app, which recently also got support for SharePlay so you can even watch a session together with someone remotely and discuss it right away. Apple groups the sessions by topics so you can easily filter the videos inside the app. You can also bookmark sessions to watch later. This is what I do right after the developer keynote.

In case you get overwhelmed by the sheer amount of sessions, a good start is to look out for all sessions titled “What’s new in …” or “Meet …”, as these are summary sessions for a specific topic or framework. Then in these sessions, they mention other sessions to dive deeper into certain details if needed.

To get the most out of the sessions, I like to take notes so I can easily find something I found interesting later on, and it also helps keep my attention up.Here are the notes I took during WWDC 2021 and WWDC 2020, for example. I recommend you do this too, and if you do, consider contributing your notes to the WWDC Notes community project to help other developers in the future.

Labs
If you are having problems with some Apple technology such as integrating with the system or with Xcode, or if you simply don’t understand how you could use a framework to implement a specific feature due to a lack of documentation for your use case, the Labs are a great opportunity to talk to an Apple engineer and get direct feedback from the people who implemented these things and know all the nitty-gritty details. There’s also a lab for getting help with App Review and one for getting feedback for your app’s Design.

You will be able to request an appointment inside the Developer app if you’re signed in with an Apple ID that is part of the paid Apple Developer Program or if you’re a this year’s Student Challenge winner. Request early and note that:

Since availability is limited, requests will be reviewed and you’ll receive an email with your status at 10:00 p.m. PT the night before your lab.

Challenges
Apple tried something new at WWDC 2021 by providing 25 “Challenges”, on the official WWDC22 page they mention “daily coding and design challenges”, so they will see a return. Most developers seem to have missed them last year (and no, I’m not talking about the Swift Student Challenge!).

Apple makes them unnecessarily hard to explore, I couldn’t find a good overview of them online that I could link to, I could only find links for those that have an accompanying sample project, because then the download page links to a news article. The easiest way to find them all for me was by searching for “Challenge” within the developer app:

I’m not sure if many people participated in these challenges, the Developer Forum only has 8 threads marked with the official tag from last year. But if you have enough time and are more the “learning by doing” type of person, check out this years challenges!

Community

What learning opportunities others in the Community offer during the week.

WWDC Notes
This amazing community project organized by Federico Zanetello is a great resource to learn what the different sessions hold without having to watch them all. While not all sessions are covered yet, as mentioned above, if we all put our notes together there, we can easily change that this year. It also serves as an archive for WWDC content dating back as much as WWDC 2010. Apple only offers videos back to WWDC 2014 at the moment, but they silently remove some older videos each year and by far not all content from 2014 is available.

Articles, Podcasts & More
Of course, all the iOS Dev content creators won’t just consume Apple’s content, but they will also write, talk or stream about it. I’m actually planning to live stream the whole week myself while I watch the sessions I’m interested in & take notes — feel free to join me on Twitch to discuss new APIs in the chat!

John Sundell is usually covering WWDC content, both in his podcast & blog. Paul Hudson writes great summaries throughout the whole week in his blog. In the last two years, he also put together a nice overview of all the WWDC-related content in this repository, maybe he’ll do it again this year? If not, check out this iOS Dev feed aggregator by Andew Yates based on the iOS Dev Directorymaintained by Dave Verwer for all iOS dev content, I’m sure many of them will cover WWDC content throughout the week.

Dub Dub Series
Similar to the “Challenges” from Apple mentioned above, Jordi Bruin recently organized a set of coding challenges called the SwiftUI Series. Unlike Apples challenges, these community-driven challenges had 3 judges for each topic who looked at the project and gave feedback in a livestream video. And Jordi plans to organize the same thing for June 10th, right after WWDC ended with the Dub Dub Series. Details aren’t up yet, but if it’s going to be anything like the SwiftUI Series, it’s gonna be pretty cool and focused on the new APIs this time.

Connecting

Apple

Special Event at Apple Park
As mentioned above, Apple is hosting a Special Event on the first day of the WWDC week at Apple Park. Submissions are closed already, so if you’re not in yet, you’re out of luck. But for those few lucky ones, they’ll be able to meet other developers in person and enjoy the keynotes together, Apple offers lots of opportunities for doing that throughout the day, including breakfast, lunch, and even guided tours within Apple Park.

Community

WWDC22 Discord
Active members in the community, like Mikaela Caron, have created a “WWDC22” space in Discord which you can join using this invite link, to organize meetups around the Bay Area around the WWDC week, for example, a Sunday dinner organized by Jordi Bruin. If you don’t know Discord, it’s pretty much the same as Slack, but with more of gaming & audio-call-focused history. This is why the Discord space could also be used for discussions pretty well! Consider checking the Discord during WWDC to meet developers & discuss new APIs! The Discord space had ~300 members at the time of this writing.

iOS Developers Slack
Already some time ago, the community had started a Slack space for iOS developers to stay in touch with each other, which you can join through this website. With over 22k members, I’m sure there’ll be many people around in the dedicated #wwdc channel to discuss the latest APIs throughout the week.

WWDC Community Week
This dedicated website tries to bring together the community during WWDC week by organizing and listing Keynote Watch Parties and other events such as Twitter “Spaces” (live, interactive audio-discussions) like the Mega-Pre-WWDC Twitter Space before WWDC or the iOS Dev Happy Hour during the week. They also organize get-togethers (in-person and online), a community hackathon, and collect memorable moments from the community on a mural. They also just introduced their own Discord server, you can join it here.

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Discussing

Apple

Digital Lounges
Like last year, Apple will offer Digital Lounges again this year, which were basically controlled Slack channels that are open only at certain times and which you need to register for up-front — registration opens May 31st and requires Apple Developer Membership / Student Challenge Winnership.

Forums
The Apple Developer Forums will also get 4 dedicated tags to discuss new APIs and ask questions about them with a chance to get answered by Apple Engineers directly. While I prefer the forum technology Apple uses on the Swift Forumsover this custom implementation, some of the more tricky questions get only answered here, so it can be a lifesaver sometimes!

Community

Of course, you can discuss new APIs in one of the Discord servers or the Slack server mentioned above for “Connecting”. Here are some more options:

Dub Dub Together
This website created by Khoa is a place you can watch both Keynotes and chat with other developers live about it in one screen. While you could in theory also watch the first keynote on YouTube and chat there, you can’t do this for the developer keynote and you’ll find many non-developers wiring in the chat, too. So definitely worth considering!

Livestreams
Some known developer sites like RayWenderlich will be live streaming the event and discussing the APIs as they are presented. I already mentioned that I’ll be streaming, too, and you might find other Twitch streamers doing the same, I’ve even contacted some to discuss APIs together in our streams. Please note that Apple doesn’t allow to re-distribute the Keynote or Sessions, so you’ll have to open Apple’s content on a second device to follow, just a heads up.

I hope that all this information will help you have an amazing WWDC 2022. Let’s hope that all our wishes come true!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

**Software: **Broadcasting Software, Keyboard Shortcuts Tool
**3rd Party Services: **Community Building, Audio Routing, Background Music

Software Setup

Check out the first part of this series to learn about which hardware I’m using. But here’s the software side of things, the most important streaming-related apps including price, my settings, and some alternatives to consider.

Broadcasting Software: SE.Live (OBS with plugins)

ℹ Description:
The heart of all streams is the braodcasting software. This is what produces the live video & sends it to Twitch (or other platforms like YouTube) as a combination of many different sources. I use it to capture my screen, my webcam, apply a green screen filter, capture my microphone audio, run filters on the audio, run background music, show stream-related alerts like follows, provide sound alerts, switch between different scenes e.g. when I start/stop the stream or have a break.

This is quite a lot of things in one software, so it’s really important to choose the right tool here. The good news is, there’s an open-source project for this named “Open Broadcaster Software”, short “OBS” with 37k starts on GitHub with lots of features that other companies can rely on. I use the StreamElements variant because it’s very close to the original OBS Studio with some extra plugins for community building purposes.

💰 Price: Free (the OBS base is fully Open Source, the plugins are not)

⚙️ My Settings:
I basically set up two types of scenes: When I’m not visible and when I am. For the latter, I downloaded a nice background video from Pixabay and added a dim layer on top of it so the screen feels alive even if I’m not there. I’ve created 3 scenes (before/break/after) with basically the same setup but different text:

For when I’m streaming, I also have 3 scenes: One with a Pomodoro timer (currently using the Flow app, but gonna use my own Open Focus Timer once it’s ready), one without a timer (e.g. at end of stream) and one with screen censored (e.g. when I need to sign in/up somewhere). After many tries, I decided to place myself at the bottom right of the screen (but not the edge):

For my webcam, I have set up a “Chroma Key” filter for the green screen:

My audio settings are a little more advanced. First, my mic settings. I’m using 4 filters for my mic which seem to be all recommended by audio pros:

“Noise Suppression” helps filter out background noise such as loud fans.

With “Noise Gate” I can completely “turn off the mic” if a specified loudness threshold isn’t met. This helps remove keyboard typing when I’m not talking.

Sometimes people can get very loud when they are surprised by something. Imagine I’m visiting a website and there’s a jump scare. To not bother my viewers with a sudden loud noise from me, I’ve setup a “Compressor” to “compress” any loudness above a given treshold by a factor of 10.

Lastly, the “Limiter” does a very similar thing to a compressor, but instead of “compressing” the extra audio by a customizable factor, it simply always uses the factor “infinity” and therefore limits the loudness to a given max.

Let’s move on to other audio settings. Two things should be noted here: First, there’s a concept called a “monitor”. A monitor is the audio you as the streamer will hear back. For example, if you turn the “monitor” on for your mic, you will hear yourself on your headphones. I have it turned on for everything except the mic as it feels weird to hear myself (with some delay). Second, for each audio source, you can specify an audio track number. This is useful if you plan to edit your videos later, e.g. to produce more narrowed-down YouTube videos (like I plan to do). For example, I’m putting my voice on its own track, the background music on another one, and all sound alerts on yet another track. This way I can cut the video source and keep parts of my voice without having the background music “jump”. And I can remove alert sounds entirely or change their volume independently if I need to. See here:

Additionally, I set up all my streams to be recorded to a .mkv file automatically with all the audio tracks from 1 to 5. See here:

That’s a selection of my OBS settings, but not all. There’s so much you can do with OBS that it can be intimidating. For example, I skipped Browser sources.

⎇ Alternatives:
– Streamlabs Desktop: Free (Open Source), custom OBS UI (matter of taste)
– Ecamm Live: $400 per year, native Mac app, easy but limited flexibility

Keyboard Shortcuts Tool: KeyCastr

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

3rd Party Services

These are the 3rd party services I’m using and every streamer should consider.

Community Building: StreamElements

ℹ Description:
What makes streaming really fun is the interaction with your viewership. While Twitch as the streaming platform provides a built-in chat, there are so many more ways to interact with your community. For example, you might want to show in your stream an alert when somebody follows you to give the viewer the feeling of truly being part of the stream. Or you want to celebrate with an on-screen animation when another streamer raids you. And you probably have some reminders like links to your socials you want to share with your always changing viewership. These and more features are provided by third-party services which I highly recommend you use at least one of to stay connected with your viewers and build a community of fans over time.

💰 Price: Free (they take a cut if you use their Merch Store or Partnerships)

⚙️ My Settings:
StreamElements provides many features, but I’m using mostly 2 of them:

First, I’m using their Alerts & Overlays Feature with a custom overlay. The two most important layers I’ve setup are the Alert Box and the Kappagen ones:

ℹ Description:
Apple is securing macOS on many levels. One of them is the protection of system audio: By default, there’s no way to fetch audio output from other apps into OBS so your viewers can hear the same as you do. This might be useful e.g. if you want to play background music in a dedicated music app or watch a tutorial video and comment it live. There is a way to turn off some security features and give apps access to system audio, but OBS doesn’t support that (yet). So you’d need extra software that routes audio from other apps or your system into a fake “virtual” microphone, which you can then add to OBS as a source like any other mic. You can find a nice detailed slideshow for how to set up the tool on both Intel & M Chip Macs here.

💰 Price: $99 (one-time payment)

⚙️ My Settings:
The most important setting here is the “Video Content” device because it provides me the audio from videos I may play using QuickTime or Safari.

⎇ Alternatives:
– Blackhole: Free (Open Source) — haven’t tried it, but looks very similar

Background Music: Pretzel

ℹ Description:
A coding session without some relaxing background music is very tiring to me. I think it is even more important to have some good background music if you are live streaming, as you’re probably not going to talk the whole time and the pauses can feel weird as a viewer if there’s no noise at all. At the same time, licensing music is a complicated topic and you are not allowed to stream everything on Twitch. In my case, I am also uploading my streams to YouTube and the rules are different between these platforms. Generally speaking, more is allowed on Twitch, and even more is allowed if you turn off the “video-on-demand” feature on Twitch, so viewers can only listen to the music while you’re live and there’s no way to watch it later.

But if you do want to provide recordings of your streams long-term, you have to find some “royalty-free” music or at least have a license for the music you use, otherwise, you might get a DMCA takedown of (parts of) your videos. If you do this repeatedly on either YouTube or Twitch, your channel might even get banned. Don’t risk it and make sure you conform to the rules.

💰 Price: Freemium ($15/month to remove chatbot posting every song)

⚙️ My Settings:
I always have “YouTube Safe” turned on. I used to have “Instrumental” turned on and play the stations “LoFi” and “Chill” a lot. But lately, I have started to listen to the “Rock” station as well, and with that filter, there were no songs, so I keep the “Instrumental” filter off now.

My preferred Pretzel settings.

LoFi, Chill and Rock are part of my favorite stations.

⎇ Alternatives:
– Monstercat Gold: $7.50/month, supports music download
– Playlists on Apple Music / Spotify / Amazon Music, e.g. from Anjunabeats
– Here’s a list of more alternatives

Next Up

This wraps up the software I use & how I have them configured — it should get you another step closer to your own live streams. In part 3 of this series, I will be covering my system settings and some other tips you should keep in mind while streaming software development on Twitch. Follow me to not miss!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

✨ 2023 Update: I’ve added 3 more wishes in this successor article.

Each year, there’s this very special time, when a specific group of people is making wishes and getting their hopes up for all sorts of things. Some share their wishes with others, some just keep them secret in their heads to not get too disappointed if not fulfilled. I used to be in the latter group, but this time I’d like to share my wishes to improve the probability of them coming true — if not this year, then maybe the next. After all, Santa might be listening.

I’m going to skip any of the obvious topics that are on top of almost every iOS developer’s list, such as a more stable Xcode, a more bug-free Swift, a more complete SwiftUI, or more reliable SwiftUI Previews. Let’s get started!

#3: Importing App Icons in all sizes from One Image

Problem

Every app is required to have an app icon. Xcode requires us to provide the app icon in dozens of different sizes though, without any support to resize them. While there are many apps & tools to help get there, only a few of them support the latest set of sizes as Apple likes to add new sizes over time. This is an unnecessary obstacle for new developers just starting.

But they are all generated as Optional types in Swift code anyhow. This and the whole NSManagedObjectContext API design feels quite outdated and not very “Swifty” (as in “not safe”). It’s time for something new!

Solution

Apple could introduce a new Swift-only framework (like SwiftUI) named something like SwiftData which provides a high-level API to define and manage persistable models. Defining a model could look something like this:

import SwiftData

actor Category: PersistableObject {
  @Persisted
  var colorHexCode: String

  @Persisted
  var iconSymbolName: String

  @Persisted
  var name: String

  @PersistedRelation(inverse: \CategoryGroup.categories)
  var group: CategoryGroup
}

For models to store in iCloud, you’d need to prepend distributed in front of actor. Normally accessing any property of an actor would require the awaitkeyword, but some magic property wrappers could simplify this to:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    Label(
      self.category.name, 
      systemImage: self.category.iconSymbolName
    )
    .foregroundColor(
      Color(hex: self.category.colorHexCode)
    )
  }
}

And writing to an actor property isn’t possible from outside, but the @Persistedproperty wrapper might have some Binding magic to allow this:

import SwiftUI
import SwiftData

struct CategoryView: View {
  @PersistedObject
  var category: Category

  var body: some View {
    TextField("Name", self.category.$name.bind())
  }
}

I have to admit, I have not used Actors in practice yet, so forgive me if some of the above examples don’t make any sense. But I have a feeling that Actors could play an important role in a SwiftData framework for safe access.

Additionally, Xcode could come with a UI that makes it easy to version data models and provide a graphical migration tool that could be written in a declarative Swift syntax and be previewed as a UML diagram on the right (like SwiftUI previews). But maybe I started dreaming too big here …

Probability

Many were expecting this already for the last two years because it’s a logical next step after SwiftUI. But this year, with Actors already shipped in Swift 5.5 and Distributed Actors (for iCloud support) being accepted just recently as well, the technology might just be ready to ship the first version by September.

Conclusion

There are lots of things Apple could announce in June, and the above are just my personal wishes. But in the past, I was always surprised by at least one or two frameworks entirely, like SwiftUI in 2019, WidgetKit in 2020, and DocC in 2021. What will it be this year? I can’t wait to find out!

Motivation: Sharing with/Giving back to Community, Time Efficiency
Hardware Setup: Mac, Headset, Webcam, Green Screen, Mic, Light

Motivation

**Price: **~$2,700

👍 Pros:
– M1 Pro builds 40% faster than M1, only 2% slower than M1 Max (source)
– Double the battery life of Intel MacBooks (also ~25 % longer than M1 Max)
– 1TB has plenty of space for multiple Xcodes, iOS simulators, 1080p streams

👎 Cons:
– More than double the price of an M1 Mac Mini with 16GB+1TB → the 40% reduced build time combined with the great monitor & mobility is worth it
– No headroom with only 16GB of RAM (the 32GB option costs extra $400!)

Recommended? **💁‍♂️ **Oh yes. M1 Ultra builds yet 37% faster though, consider!

⎇ Alternatives:
– M1 Mac mini with 16GB RAM + 1TB ($1,300)
– M1 MacBook Air with 16 GB RAM + 1 TB ($1,650)
– M1 Ultra Mac Studio with 64 GB RAM + 1 TB (~$4,000)

Headset: AirPods Max

Price: 300€ ($335) — Note: I bought them second-hand.

Pros: 👍
– Easy to connect to Apple devices
– Very long battery life (I hardly have to charge)
– Comfortable even after hours of stream

Cons: 👎
– Expensive when bought new ($550)
– Cable-mode requires extra Lightning-to-3.55mm cable ($35)

**Recommended? 💁‍♂️ **If you own more Apple devices, then: Yes. Else: No.

⎇ Alternatives:
– Logitech Pro X ($90), good quality detachable mic
– HyperX Cloud II ($70), also very popular with gamers
– Any headphones you already own (if you get an external mic anyways)

Webcam: Logitech C920S Pro

**Price: **~$70

Pros: 👍
– Reliable (I see cams in streams turning off randomly, never happened to me)
– Good 1080p quality & natural colors
– Privacy shutter (after all Edward Snowden told us the NSA is watching 👀)
– Auto-focus & auto-lighting that can be configured via Logitech software

Cons: 👎
– Built-in mic that can’t be turned off physically (NSA, remember?)

**Recommended? 💁‍♂️ **Yes!

Green Screen: Elgato Collapsible Chroma Key Panel

Price: ~$120

Pros: 👍
– Easy & fast to set up & put away
– Stable stand
– Good height

Cons: 👎
– Could be even a bit wider (I have to cut the sides of my webcam image)

**Recommended? 💁‍♂️ **Yes, really convenient if you need a green screen.

⎇ Alternatives:
– Setup a nice looking background for your workspace if you have the space

✨ Want to see your ad here? Contact me at ads@fline.dev to get in touch.

Mic: Blue Yeti

Price: ~$100

Pros: 👍
– Flexible modes that also allow for interviews & more
– Great sound out of the box without any filters applied
– Logitech software ships with multiple filter presets

Cons: 👎
– Default stand not well enough shielded against vibrations (keyboard)
– Clicking mute button creates too loud noise to use during stream

**Recommended? 💁‍♂️ **Yes, this is actually recommended by many for starters.

⎇ Alternatives:
– HyperX Quadcast, convenient tap-to-mute sensor ($110)
– Rode NT-USB, ships with a pop shield ($170)
– If you have a good quality headset mic, use that instead (e.g. Logitech Pro X)

Light: LAVKOW 10 Inches RGB Selfie Ring Light (US alternat.)

Price: ~$30

Pros: 👍
– Cheap
– Supports different colors

Cons: 👎
– Not very bright, but good enough for streaming when sitting close

**Recommended? 💁‍♂️ **To save money, get a selfie light, Yes. For quality: No.

⎇ Alternatives:
– Elgato Key Light (~$200)

See also Twitch’s hardware recommendations page for more alternatives.

Other Periphery I Use

Not exactly streaming related, but if you’re interested in what else I have on my desk while streaming, here’s a quick commented list:

• Apple Wireless Magic Keyboard 2 ($65):
  I’d prefer Logitech ERGO K860 now.

• Logitech MX Vertical ($80):
  A savior for my wrist, wouldn’t wanna go back.

• Inateck HB2021 5-in-1 Adapter ($35):
  Only one cable to connect, like a dock.

• Boyata Laptop Stand ($30):
  Nice build quality, very stable & grippy. 👍

• Lamicall Phone Stand S1 ($10):
  Good enough, hole for cable. Does its job.

• MAXLVL Gaming Mauspad XL ($15):
  Size of 90cm x 40cm is perfect for me.

That’s it for my motivation & my hardware setup. I hope this helps future streamers to get started. The next part covers the software side which I think is even more interesting: All tools I use and how I have them and my hardware set up to work together. Make sure to follow me to not miss it!

💁🏻‍♂️ Enjoyed this article? Check out my app RemafoX! A native Mac app that integrates with Xcode to help translate your app. Get it now to save time during development & make localization easy.

So in one of my streams (this is an open-source app I am developing fully in the open while streaming live on Twitch) I decided to tackle this problem and fix the SwiftUI preview error once and for all. And I failed:

Just failed at fixing a #SwiftUI preview error during my #livestream. Could fix one issue, but then got stuck at "MessageError: Connection interrupted". Any ideas? The project is open source:https://t.co/ppevrcRMtK

I started getting this error here:https://t.co/AQz2l7vnTv pic.twitter.com/aTYQy5gzHi

— Cihat Gündüz (@Jeehut) March 2, 2022

Thanks to some help from the great Swift community on Twitter, I could figure out the root cause of the issue: SwiftUI previews get into trouble when CoreData models are referenced in them.

But while I thought that it’s just a path issue that can be fixed with a simple workaround, it was not as simple as that. Yes, there is a path issue involved, but while solving the previews, I came across multiple levels of failure. And I learned how to debug SwiftUI previews along the way. Let me share my learnings…

#1: Explicit Dependencies in Package Manifest

First things first. Using Point-Free’s modularization approach means you’ll have a Package.swift file to manage manually. For each module, you’ll add a target, a testTarget and a library entry and for each target, you’ll need to specify the dependencies. Xcode does not help here in any way other than recognizing the changes you make in that file. With many packages, the manifest file can grow significantly, and there’s currently no help I’m aware of to make this easier. This is what my manifest looks like right now:

// swift-tools-version:5.5
import PackageDescription

let package = Package(
  name: "OpenFocusTimer",
  defaultLocalization: "en",
  platforms: [.macOS(.v12), .iOS(.v15)],
  products: [
    .library(name: "AppEntryPoint", targets: ["AppEntryPoint"]),
    .library(name: "Model", targets: ["Model"]),
    .library(name: "TimerFeature", targets: ["TimerFeature"]),
    .library(name: "ReflectionFeature", targets: ["ReflectionFeature"]),
    .library(name: "Resources", targets: ["Resources"]),
  ],
  dependencies: [
    // Commonly used data structures for Swift
    .package(url: "https://github.com/apple/swift-collections", from: "1.0.2"),

    // Handy Swift features that didn't make it into the Swift standard library.
    .package(url: "https://github.com/Flinesoft/HandySwift", from: "3.4.0"),

    // Handy SwiftUI features that didn't make it into the SwiftUI (yet).
    .package(url: "https://github.com/Flinesoft/HandySwiftUI", .branch("main")),

    // ⏰ A few schedulers that make working with Combine more testable and more versatile.
    .package(url: "https://github.com/pointfreeco/combine-schedulers", from: "0.5.3"),

    // A library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind.
    .package(url: "https://github.com/pointfreeco/swift-composable-architecture", from: "0.33.1"),

    // Safely access Apple's SF Symbols using static typing Topics
    .package(url: "https://github.com/SFSafeSymbols/SFSafeSymbols", from: "2.1.3"),
  ],
  targets: [
    .target(
      name: "AppEntryPoint",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "HandySwiftUI", package: "HandySwiftUI"),
        "Model",
        "ReflectionFeature",
        "TimerFeature",
        "Utility",
      ]
    ),
    .target(
      name: "Model",
      dependencies: [
        .product(name: "OrderedCollections", package: "swift-collections"),
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
      ],
      resources: [
        .process("Model.xcdatamodeld")
      ]
    ),
    .target(
      name: "TimerFeature",
      dependencies: [
        .product(name: "HandySwift", package: "HandySwift"),
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        "Model",
        "ReflectionFeature",
        "Resources",
        .product(name: "SFSafeSymbols", package: "SFSafeSymbols"),
        "Utility",
      ]
    ),
    .target(
      name: "ReflectionFeature",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        .product(name: "HandySwift", package: "HandySwift"),
        "Model",
        "Resources",
        "Utility",
      ]
    ),
    .target(
      name: "Resources",
      resources: [
        .process("Localizable")
      ]
    ),
    .target(
      name: "Utility",
      dependencies: [
        .product(name: "CombineSchedulers", package: "combine-schedulers"),
        "Model",
      ]
    ),
    .testTarget(
      name: "ModelTests",
      dependencies: ["Model"]
    ),
    .testTarget(
      name: "TimerFeatureTests",
      dependencies: [
        .product(name: "ComposableArchitecture", package: "swift-composable-architecture"),
        "TimerFeature",
      ]
    ),
  ]
)

The problem with managing this file manually isn’t just the manual work. Xcode seems to behave inconsistently regarding the dependencies: When you do a normal build targeting the Simulator for example, a dependency of a dependency seems to get automatically linked to your target. So if my TimerFeature is importing Utility for example, but it’s not listed as a dependency under the TimerFeature target, Xcode might still be able to compile without errors if another dependency, e.g. Model also depends on Utility so Xcode can indirectly access Utilityinside of TimerFeature because TimerFeature is listing Model as its dependency.

While this sounds very useful, it can become quite frustrating because SwiftUI previews work differently. For them, as far as I can tell, this transitive kind of implicit imports don’t work. The same seems to be true for running tests as well (at least sometimes). In other words: It’s important to always double-check the dependencies for each target and not to forget to add every import you make in a target to the related target in your Package.swift manifest file.

Maybe, someone will write a tool to help make this easier in the future. 🤞

#2: Generated Code not reliably picked up by Xcode

Another issue I had come across was that even when my builds succeeded, Xcode would (after showing me the “Build succeeded” dialog) show an error in the editor within PreviewProvider stating it can’t find FocusTimer:

Note that you will need to delete and re-create these generated files each time you make a change to the model (which you should do rarely anyways to prevent database migration problems). Additionally, select the model in Xcode and set Codegen to Manual/None.

With this done, the editor no longer shows an error.

#3: SwiftUI Diagnostics != SwiftUI Crash Reports

Here’s a learning for those (like me) wondering how to make use of errors like this after pressing the Diagnosticsbutton when SwiftUI previews fail:

Viewing the contents of the highlighted folder will reveal many files that hold different kinds of details about the SwiftUI preview build. The most useful file for debugging lies inside the folder CrashLogs where you can find one or multiple .ips files that we can easily open in Xcode via a double-click:

Thankfully, here the aforementioned pointer of a kind developer in the Swift community on Twitter helped, which pointed me to a thread with this answer on StackOverflow.

It’s basically saying that there’s currently a bug in Xcode (or SwiftPM?) which makes Bundle.module point to the wrong path in SwiftUI previews. To fix it, they are suggesting to add a Bundle extension with a custom search. Here’s the full code slightly adjusted to fit my coding & commenting style:

import Foundation

extension Foundation.Bundle {
  /// Workaround for making `Bundle.module` work in SwiftUI previews. See: https://stackoverflow.com/a/65789298
  ///
  /// - Returns: The bundle of the target with a path that works in SwiftUI previews, too.
  static var swiftUIPreviewsCompatibleModule: Bundle {
    #if DEBUG
      // adjust these for each module
      let packageName = "OpenFocusTimer"
      let targetName = "Model"

      final class ModuleToken {}

      let candidateUrls: [URL?] = [
        // Bundle should be present here when the package is linked into an App.
        Bundle.main.resourceURL,

        // Bundle should be present here when the package is linked into a framework.
        Bundle(for: ModuleToken.self).resourceURL,

        // For command-line tools.
        Bundle.main.bundleURL,

        // Bundle should be present here when running previews from a different package (this is the path to "…/Debug-iphonesimulator/").
        Bundle(for: ModuleToken.self).resourceURL?.deletingLastPathComponent().deletingLastPathComponent()
          .deletingLastPathComponent(),
        Bundle(for: ModuleToken.self).resourceURL?.deletingLastPathComponent().deletingLastPathComponent(),
      ]

      // The name of your local package, prepended by "LocalPackages_" for iOS and "PackageName_" for macOS.
      let bundleNameCandidates = ["\(packageName)_\(targetName)", "LocalPackages_\(targetName)"]

      for bundleNameCandidate in bundleNameCandidates {
        for candidateUrl in candidateUrls where candidateUrl != nil {
          let bundlePath: URL = candidateUrl!.appendingPathComponent(bundleNameCandidate)
            .appendingPathExtension("bundle")
          if let bundle = Bundle(url: bundlePath) { return bundle }
        }
      }

      return Bundle.module
    #else
      return Bundle.module
    #endif
  }
}

When copy and pasting this code, make sure to adjust the packageName and targetName variables to your package & target names accordingly.

Note that I wrapped the workaround into an #if DEBUG to ensure my production code does not accidentally use this path search and instead relies on the official Bundle.module. Also, I removed the fatalError from the workaround code found on StackOverflow, so in case it can’t find a Bundle in the custom search paths it doesn’t fail but instead I return Bundle.module as a fallback. This is supposed to make the code more resilient and continue to work even when this bug gets fixed in a future Xcode release but the custom search paths may no longer work.

Now, the last change I had to make in the PersistenceController was to replace the call to Bundle.module with a call to the new Bundle.swiftUIPreviewsCompatibleModule:

let modelUrl = Bundle.swiftUIPreviewsCompatibleModule.url(forResource: "Model", withExtension: "momd")!
let managedObjectModel = NSManagedObjectModel(contentsOf: modelUrl)!
container = NSPersistentContainer(name: "Model", managedObjectModel: managedObjectModel)

And finally, my SwiftUI previews started working again!

If this were the case, SwiftUI could even be used for prototyping where a “working but not beautiful” version of an app idea could be quickly built and shown to users to verify if the app idea has any chances of success. Also, this way one could also quickly gather feedback about which parts actually need a much better understandable UI (the parts not yet understood well) and which could be mostly kept to the default components with some visual adjustments.

In other words: SwiftUI in my eyes has the potential to make MVP-driven product development much more interesting to many more developers which is definitely a good thing as it saves a lot of time that would otherwise be invested in things that would eventually turn out to fail in one way or another. This goes in line with the Lean Startup methodologywhich I think is a great way to tackle any kind of new product.

The Current State of SwiftUI

For this to be possible, I would expect SwiftUI to already cover all common types of input that might be needed in forms, like for user registration or other kinds of data, as many types of apps, in the end, are nothing else than a form that accepts input data, transforms it in some way and presents data back in a special way or time. Unfortunately, SwiftUI isn’t quite there yet.

The approach Apple seems to be taking with SwiftUI is to consider which are the most missing components in SwiftUI and adding some of them each year. For example, at WWDC 2020 they added ProgressView, Gauge, Image support within Text and improved a lot of other details of existing views, both for performance and more flexibility. At WWDC 2021 they’ve added multiple async/await related APIs, such as AsyncImage or the .refreshable and .task view modifiers, amongst other improvements & additions.

The upside of that approach is, once something is added to the framework, one can expect it to exist and work in the same manner for a long time, so no big code changes are needed with every release (like it was for Swift as a language before Swift 4). The downside is that many components are still missing. And that’s where I think the community can jump in to provide temporary solutions that can be easily replaced by official components provided by Apple sometime in the future.

Implementing a Multi-Selection View Component

In this post, I would like to focus on one such component and provide my initial solution for it: A multi-selector to choose multiple options out of a given set of options. As of now Apple does provide a Picker, but it doesn’t support the selection of multiple entries and even automatically leaves the list screen once a single choice was made. So let’s get right to it and fix that!

What kind of data structure could require a multi-selector? Let’s have a look at this example:

struct Goal: Hashable, Identifiable {
    var name: String
    var id: String { name }
}

struct Task {
    var name: String
    var servingGoals: Set<Goal>
}

So basically, in our app we have a collection of goals and a collection of tasks. And we want to model the relation describing which goals each task serves. When creating or editing a Task we want to select which goals the task is serving. Here’s the SwiftUI code for a TaskEditView:

import SwiftUI

struct TaskEditView: View {
    @State
    var task = Task(name: "", servingGoals: [])
    
    var body: some View {
        Form {
            Section(header: Text("Name")) {
                TextField("e.g. Find a good Japanese textbook", text: $task.name)
            }

            Section(header: Text("Relationships")) {
                Text("TODO: add multi selector here")
            }
        }.navigationTitle("Edit Task")
    }
}

struct TaskEditView_Previews: PreviewProvider {
    static var previews: some View {
        NavigationView {
            TaskEditView()
        }
    }
}

The above code renders to this preview:

To show off, how things would work if we only had one goal to serve, we could simply replace our TODO Text entry with a Picker like this:

// mock data:
let allGoals: [Goal] = [
    Goal(name: "Learn Japanese"), 
    Goal(name: "Learn SwiftUI"), 
    Goal(name: "Learn Serverless with Swift")
]

Picker("Serving Goal", selection: $task.servingGoal) {
    ForEach(allGoals) {
        Text($0.name).tag($0 as Goal)
    }
}

This is what the TaskEditView now looks like:

And when clicking the picker, this is the detail view:

Pretty straight-forward. Note that Goal needs to be Identifiable for this to work, that’s why I added var id: String { name } to it in the first place. For our multi-selector we want the UI to actually look pretty much the same, but instead of one, we would like to be able to choose multiple entries.

First, we need to re-create the entry in the TaskEditView, I’ve chosen the name MultiSelector as the replacement type name for Picker. Here is it’s implementation:

import SwiftUI

struct MultiSelector<LabelView: View, Selectable: Identifiable & Hashable>: View {
    let label: LabelView
    let options: [Selectable]
    let optionToString: (Selectable) -> String
    var selected: Binding<Set<Selectable>>

    private var formattedSelectedListString: String {
        ListFormatter.localizedString(byJoining: selected.wrappedValue.map { optionToString($0) })
    }

    var body: some View {
        NavigationLink(destination: multiSelectionView()) {
            HStack {
                label
                Spacer()
                Text(formattedSelectedListString)
                    .foregroundColor(.gray)
                    .multilineTextAlignment(.trailing)
            }
        }
    }

    private func multiSelectionView() -> some View {
        Text("TODO: add multi selection detail view here")
    }
}

Note that I decided to represent each entry with a String, thus the optionToString closure is needed which will provide the Stringrepresentation of the options type.

The call to ListFormatter.localizedString makes sure that we join a list of selected options together in the correct localization format (e.g. ["A", "B", "C"]becomes “A, B and C” for English).

This is the preview code I used for the view:

struct MultiSelector_Previews: PreviewProvider {
    struct IdentifiableString: Identifiable, Hashable {
        let string: String
        var id: String { string }
    }
  
    @State 
    static var selected: Set<IdentifiableString> = Set(["A", "C"].map { IdentifiableString(string: $0) })
    
    static var previews: some View {
        NavigationView {
            Form {
                MultiSelector<Text, IdentifiableString>(
                    label: Text("Multiselect"),
                    options: ["A", "B", "C", "D"].map { IdentifiableString(string: $0) },
                    optionToString: { $0.string },
                    selected: $selected
                )
            }.navigationTitle("Title")
        }
    }
}

Note that instead of Goal I used an internal type to make the preview independent from my specific project. This is what the preview looks like:

Let’s place this into our TaskEditView and see what it looks like in that context by replacing the TODO Text call with:

MultiSelector(
    label: Text("Serving Goals"),
    options: allGoals,
    optionToString: { $0.name },
    selected: $task.servingGoals
)

The preview now changes to this, which looks just as expected:

But when clicking on it, we see this, which is not right yet:

Let’s implement the detail view then. I’ve chosen the type name MultiSelectionView for the detail view and this is its code:

import SwiftUI

struct MultiSelectionView<Selectable: Identifiable & Hashable>: View {
    let options: [Selectable]
    let optionToString: (Selectable) -> String

    @Binding 
    var selected: Set<Selectable>
    
    var body: some View {
        List {
            ForEach(options) { selectable in
                Button(action: { toggleSelection(selectable: selectable) }) {
                    HStack {
                        Text(optionToString(selectable)).foregroundColor(.black)

                        Spacer()

                        if selected.contains { $0.id == selectable.id } {
                            Image(systemName: "checkmark").foregroundColor(.accentColor)
                        }
                    }
                }.tag(selectable.id)
            }
        }.listStyle(GroupedListStyle())
    }

    private func toggleSelection(selectable: Selectable) {
        if let existingIndex = selected.firstIndex(where: { $0.id == selectable.id }) {
            selected.remove(at: existingIndex)
        } else {
            selected.insert(selectable)
        }
    }
}

Except for label, this has basically the same properties. But this time, they are actually used, for example when checking if the checkmark should actually be shown by calling contains on the selected collection.

When one of the entries is clicked, toggleSelection is used on the entry to remove or insert it into the selectedproperty. For the checkmark, I’m using the SF Symbol “checkmark” which looks exactly like the checkmark icon of Picker.

This is the preview code I’ve setup for the detail view, note that it’s pretty much a copy of the MultiSelector preview:

struct MultiSelectionView_Previews: PreviewProvider {
    struct IdentifiableString: Identifiable, Hashable {
        let string: String
        var id: String { string }
    }

    @State 
    static var selected: Set<IdentifiableString> = Set(["A", "C"].map { IdentifiableString(string: $0) })
    
    static var previews: some View {
        NavigationView {
            MultiSelectionView(
                options: ["A", "B", "C", "D"].map { IdentifiableString(string: $0) },
                optionToString: { $0.string },
                selected: $selected
            )
        }
    }
}

This is what it looks like in the Xcode preview:

Now finally, let’s integrate our MultiSelectionView to our MultiSelector by replacing the TODO Text entry with:

MultiSelectionView(
    options: options,
    optionToString: optionToString,
    selected: selected
)

Basically, we’re just passing the data onto the detail view. But let’s see what our app looks like now in this animated GIF I recorded from the simulator:

Nice, it’s working!

I’ve uploaded the Demo project to GitHub if you want to just copy the contents of the MultiSelector and MultiSelectionView, you can find them in this folder.

For example, Point-Free has a great free episode on this topic and Majid Jabrayilov recently wrote a 4-parts series on “Microapps architecture” (parts 1, 2, 3, 4) which I can both recommend to get started.

Also, you might even want to hide secrets in public Open Source libraries, e.g. in the unit tests of some 3rd party service integration where users of the library will provide their own token, but you want your tests to run with your own.

What these situations have in common is that they are based on a custom maintained Package.swift file — not the one Xcode maintains for you if you just add a dependency to an app project. The app or project is split into many small modules with no corresponding .xcodeproj file, Xcode just opens the Package.swift file directly, without the need for a project.

This also means, that for the separate modules, there’s no way to specify any build settings or build scripts within Xcode, all needs to be done right within the Package.swift manifest file.

While more and more such features are being added to SwiftPM (like SE-303, SE-325, SE-332) in future releases, there’s no sign they will support any Xcode-specific features such as .xcconfig files.

How can we hide secrets from committing to Git to ensure we’re not leaking them to our Git provider or anyone else with access to our repo today?

SwiftPM resources & JSONDecoder

I’m sure there’s no single “best” answer to this and others may have smarter ideas than mine. But I like to keep things simple and I also like to use basic features because I know them well & I expect other developers to understand them quickly if needed. Plus I can be sure they’re future-proof.

The approach I want to use is the classical .env file approach which is common in web development. But instead of a custom-formatted .env file, I want to simply have a .json file with my secrets in it, because JSON files are familiar to many iOS developers and we have built-in support for parsing them in Swift thanks to JSONDecoder. Loading files or more generally “resources” is also supported by SwiftPM since Swift 5.3 (SE-271).

Here’s the basic idea of how I want to hide secrets from Git outlined:

1. Check in a secrets.json.sample file into Git with the keys, but no values

2. Let developers duplicate it , remove the .sample extension & add values

3. Ignore the secrets.json file via .gitignore so it’s never checked in

4. Provide a simple struct conforming to Decodable to read the secrets

The rest of this article is a step-by-step guide on how to apply this approach. I will be using the unit tests of my open source translation tool BartyCrouch which integrates with two 3rd-party translation services as an example.

⚠️ Please note that if you plan to apply this approach to an app target which you will ship to users, you will probably run into the same problem as described in the .xcconfig approach in this NSHipster article. My method only helps hiding the secrets from Git, you will need additional obfuscation if you plan to ship to users.

Adding the secrets.json resource file

First, let’s add the secrets.json file to our project. As there’s going to be a corresponding secrets.json.sample and a Secrets.swift file, I opt for creating a folder Secrets first, then I create an empty file which I name secrets.json and I add a simple JSON dictionary structure with two keys:

And so my CI is also set up to access my secrets safely without leaking them.

But these strategies are designed for a higher-level kind of prioritization, as in deciding if you should be implementing feature A or feature B first or if feature C is even needed in the next version at all. They **don’t scale down **to tasks or even sub-tasks of your features though, so it’s quite possible to do too much within a specific feature. Also, they don’t help answer when you can start putting the feature in users’ hands for early feedback to apply user-focused approaches, such as the Lean Startup methodology. One could of course opt for a method that is independent of scale, like the MoSCoW method, but their categories wouldn’t be easy to rate because they’re so abstract that different people would have different expectations for each category.

The goal of the Laser Focus prioritization strategy is to provide clear rating categories, help with task scopes and provide an easy-to-apply method for interpretation. All three aspects together help you stay laser-focused.

Laser Focus categories

There are three goals we want to reach with our categories:

1. Decide which tasks are in the scope of the currently planned release.

2. Prioritize tasks needed for an Alpha or Beta version higher than the others.

3. The Categories names should have an actionable, self-contained meaning.

We’re suggesting the following categories which fulfill all requirements:

Vital

Absolute minimum needed for the first round of testing. Can be ugly.

This allows for shipping a product with just “Vital” features or tasks implemented to a small group of testers to get feedback early. Of course, the scope of this Alpha testing should be made clear stating what basic features or tasks are still missing so they are not unnecessarily reported by the testers. But the vitals of the product or feature can be tested already and we get the first round of feedback showing if we’re headed in the right direction.

Essential

Core aspects required for basic functionality. Can have rough edges.

A second and bigger round of testing can be started as soon as all “Essential” features or tasks are implemented. At this level, no specific testing scope needs to be communicated, it should be enough to call the version a “Beta” version where the base features are available but still a lot of things are missing or incomplete.

Completing

Ironing out rough edges and completing aspects of functionality.

The “Completing” level defines the scope where the final product is ready to be released. In some situations, e.g. if a new version was announced for a specific date, the product can also be released while still, some “Completing” tasks are open, but then it should be publicly marked as “Beta”. Typically this level includes all kinds of features or tasks that are important for a bigger customer base but are not relevant to evaluating the core of the product.

Optional

Nice-to-haves that can be delayed to later (versions) or skipped entirely.

The “Optional” level has the notion that the features or tasks rated as such are wanted things, but that they are in no way necessary to release a finalized version of a product, even long term. Hence they can also be easily delayed or scrapped if needed as per the resources of the team.

Retracting

Nice-to-haves (at first sight) that can (potentially) cause more harm than improve things.

Unlike “Optional”, features or tasks rated as “Retracting” should be actively avoided. That means it can make sense to document or keep them somewhere including the rationale why they should be avoided for long-term decision-making. This saves time when the same idea comes up again sometime in the future. Also, if multiple people are involved in the rating, it can help identify the tasks where discussion might be necessary to clarify the effect of a task on the product.

Laser Focus matrix

The second pillar of the Laser Focus strategy is its multi-dimensional scalability. To explain what this means and why it is important, let’s apply the categories we have so far with an example: Let’s develop a stopwatch app to track time for different things done throughout the day. This is the initial list of feature ideas, rated using the Laser Focus categories:

1. Create projects
   → Essential (essential to app, but pre-filled projects enough for first test)

2. Edit projects
   → Completing (not a necessity for testing purposes, but for final release)

3. Delete projects
   → Completing (cleanup task, not needed for testing purposes, but for final)

4. Start/Stop a timer
   → Vital (core idea of app, vital part of the app)

5. Select a project for the timer
   → Vital (without selecting project, app idea not fulfilled)

6. Edit past tracked times
   → Retracting (V2 planned with competitive feature, risk of cheating)

7. Delete past tracked times
   → Optional (nice to have, no risk of cheating as no added time)

8. Show historical time tracked on a selected project
   → Essential (core use case for app)

9. Show projects with the most tracked time
   → Essential (core use case for app)

Thanks to the categorization, we can already exclude two features from the first release and recognized even a feature we should probably never implement (6) that should be permanently documented. But more importantly, we now know that 4 and 5 are the “Vital” features to implement first.

Let’s start working on their sub-tasks:

4. Start/Stop a timer: (Vital)

a. Design Start/Stop button layout (low fidelity)
b. Design Start/Stop button coloring & icons (high fidelity)
c. Design Start/Stop button pulsating shadow effect (animations)
d. Implement Start/Stop button layout (low fidelity)
e. Implement Start/Stop button coloring & icons (high fidelity)
f. Implement Start/Stop button pulsating shadow effect (animations)
g. Setup basic tracked time database models
h. Persist Start/Stop actions into database

5. Select a project for the timer: (Vital)

a. Design project selector navigation & layout (low fidelity)
b. Design project selector shapes, colors & icons (high fidelity)
c. Implement project selector navigation & layout (low fidelity)
d. Implement project selector shapes, colors & icons (high fidelity)
e. Persist selected project into tracked time database model

All clear, let’s get started, right? Right?

No. I’m sure you noticed it already while reading/skimming through them. There’s a problem. We have prioritized the features thinking about what’s really necessary for being testable, for putting the app into users’ hands. But now we have the same problem again, just on a different level. These tasks (and potentially also their sub-tasks) aren’t all “Vital” for our very first version to put in users’ hands. How can we fix this? Should we apply another rating for the tasks, too?

Yes, absolutely! This is actually a requirement in the Laser Focus strategy: Apply the rating on all levels down the road! Not necessarily above levels, where you are allowed to choose any alternative prioritization technique. But the lower levels from wherever you want to start from should all be rated like this.

Let’s assign the Laser Focus categories to the tasks, too, and then see what this means for overall priority:

4. Start/Stop a timer: (Vital)

a. Design Start/Stop button layout (low fidelity)
→ Vital
b. Design Start/Stop button coloring & icons (high fidelity)
→ Completing
c. Design Start/Stop button pulsating shadow effect (animations)
→ Optional
d. Implement Start/Stop button layout (low fidelity)
→ Vital
e. Implement Start/Stop button coloring & icons (high fidelity)
→ Completing
f. Implement Start/Stop button pulsating shadow effect (animations)
→ Optional
g. Setup basic tracked time database models
→ Essential
h. Persist Start/Stop actions into database
→ Essential

5. Select a project for the timer: (Vital)

a. Design project selector navigation & layout (low fidelity)
→ Vital
b. Design project selector shapes, colors & icons (high fidelity)
→ Completing
c. Implement project selector navigation & layout (low fidelity)
→ Vital
d. Implement project selector shapes, colors & icons (high fidelity)
→ Completing
e. Persist selected project into tracked time database model
→ Essential

It’s important to note that the reference value for the ratings of the tasks was the feature because it’s the direct parent. This means that I asked myself the question “Is persisting Start/Stop actions into database vital or essential to the feature Start/Stop a timer?” and not to the app or anything else. This makes answering the questions much easier.

Let’s visualize these two different levels of rating with a simple matrix. On the X-axis we put the ratings of the features. On the Y-axis are the ratings of the tasks. The circles represent the tasks:

As you can see, tasks 4a, 4d, 5a, and 5c are in the bottom left field, the “Vital-Vital” field, or short “VV”. The field’s background is tinted red. It contains all tasks the focus should be on first. Once they’re all implemented, the very first testing round can begin, and the Alpha phase starts.

The tasks 4g, 4h, and 5e in the yellow-tinted field “Vital-Essential” or short “VE” should be tackled next. Once all tasks in all three yellow-tinted fields (VV, VE, EV) are completed, the Beta phase starts.

The “VC” field with its “Completing” tasks for the “Vital” features should be tackled last among the tasks we defined so far. Once all tasks in all green-tinted fields (VC, CV, EC, CE, CC) are done, it’s Release time.

In the above example, we skipped the tasks for all non-Vital features. If we had rated them also, the full matrix could have looked something like this, including also the “Retracting” rating:

We can see how the Alpha, Beta, and Release tasks are circularly layered around the origin point (bottom left corner), visually providing us a priority for each task based on its distance to the origin. This easily scales to a third axis if for example sub-tasks were added to each task. Formally speaking, this scales to any number of dimensions. To calculate the overall category of any given element, just look up all ancestors and just select the lowest priority as the overall category of the “atomic” (lowest level) element. For example, imagine a sub-task with the category rating “Essential”, a parent task rated “Vital” and its parent feature rated “Completing”. Overall, the lowest priority is “Completing”, so this is the overall category of the sub-task.

Calculating the overall category alone can lead to many tasks being on the same level, especially at “Completing” where we have 5 different fields. A way of prioritizing features or tasks within the same category is by calculating the average of its own category combined with that of all its ancestor’s categories. To do this, let’s assign each category a number (from 1 “Vital” to 5 “Retracting”), the lowest level (e.g. a sub-task) can then be represented by a tuple, e.g. (2, 1, 3) in the above example. The average of these numbers is simply calculated by (2 + 1 + 3) / 3 = 2.0. Another task with more ancestors and the same overall “Completing” category might be rated as (3, 2, 3, 1) and therefore have an average of (3 + 2 + 3 + 1) / 4 = 2.25, so it should be prioritized lower. The higher the overall average, the lower the priority – that makes a lot of sense as the average number roughly resembles the distance to the origin – the highest possible priority.

But don’t worry, you don’t actually have to calculate these averages, there’s a simpler way based on the matrix we’ve seen above with enough precision:

The above diagram shows in which order the fields should be tackled, based on origin distance. Note that there are two fields placed 2nd, 4th, and 5th each. For these fields, there’s a choice to be made that can be different depending on the situation: Should we focus more on adding more features? Or should we focus more on improving the already started features? For a feature focus expansion first, you should continue in direction of the “Feature category”, e.g. “EV” before “VE”. For improving existing features first, it should be the other way around.

Laser Focus breakdown

In the above section, we learned that categorization on multiple levels is key to the Laser Focus concept. If you try to apply this to your project right away, you may realize though that many or even all of your features or tasks are actually “Vital” or “Essential” to you. If this is the case, then it’s a sign that you have probably not efficiently split your tasks yet.

That’s why breaking down your tasks the right way is important before categorizing them. The guiding question you should ask yourself while splitting features into tasks or tasks into sub-tasks should not be restricted to “which steps do I need to make to finalize it”. You should also think about the effort for each step and if the effort isn’t negligibly small, you might want to consider splitting it away. Sometimes it might seem to be hard doing that, but more often than not, it’s a good idea to follow the approach “make it work, then make it better” while splitting the tasks.

For example, for the above feature “Start/Stop a timer” we could have split it up into 3 tasks: “Design the Start/Stop buttons”, “Implement the Start/Stop buttons” and “Persist data”. The problem with this is that there are no different levels of completion. It’s better to break it down even further. Of course, we could do that as sub-tasks under these tasks, but to make priority calculation easier, it is recommended to do it on fewer levels. So instead we opted for “Design the Start/Stop button layout”, “Implement Start/Stop button layout” and the same two tasks also for “… coloring & icons” and “… pulsating shadow effect”.

Ask yourself which parts have their own effort and split them so each task is worth being prioritized based on the effort needed. Don’t split micro-tasks away, it’s not worth prioritizing such small tasks, just keep them as part of another task.

A proper breakdown is very important for the Laser Focus strategy to be effective.

Summary

Let’s sum up the Laser Focus prioritization strategy in the right order:

1. Break down your features and tasks into smaller steps of different completion levels

2. Rate them on each level with “Vital”, “Essential”, “Completing”, “Optional” or “Retracting”

3. Visualize or calculate the overall priority for the lowest level by considering all ancestors

Apply these steps at any given time for your project and it will help you keep focusing on the important things and confidently put your work-in-progress versions into users’ hands as soon as reasonable.

Obviously, they need to be resolved before the work branch can be merged. But the question is: How should this situation be resolved? Should we merge the main branch into the work branch? Or should we rebase the work branch onto the latest main branch?

In my opinion, there’s only one correct answer to this question. From my experience, the main reason why so many discussions arise around this topic is that there’s a lot of misunderstandings out there about how merge and rebase differ from each other in this context and a general lack of understanding, what a rebase even is.

So I created an FAQ for my team which tries to clarify things. Let me share:

What is a merge?

A commit, that combines all changes of a different branch into the current.

What is a rebase?

Re-comitting all commits of the current branch onto a different base commit.

What are the main differences between merge and rebase?

1. merge executes only one new commit. rebase typically executes multiple (number of commits in current branch).

2. merge produces a new generated commit (the so called merge-commit). rebase only moves existing commits.

In which situations should we use a merge?

Use merge whenever you want to add changes of a branched out branch back into the base branch.

Typically, you do this by clicking the “Merge” button on Pull/Merge Requests, e.g. on GitHub.

In which situations should we use a rebase?

Use rebase whenever you want to add changes of a base branch back to a branched out branch.

Typically, you do this in work branches whenever there’s a change in the main branch.

Why not use merge to merge changes from the base branch into a work branch?

1. The git history will include many unnecessary merge commits. If multiple merges were needed in a work branch, then the work branch might even hold more merge commits than actual commits!

2. This creates a loop which destroys the mental model that Git was designed by which causes troubles in any visualization of the Git history.

Imagine there’s a river (e.g. the “Nile”). Water is flowing in one direction (direction of time in Git history). Now and then, imagine there’s a branch to that river and suppose most of those branches merge back into the river. That’s what the flow of a river might look like naturally. It makes sense.

But then imagine there’s a small branch of that river. Then, for some reason, the river merges into the branch and the branch continues from there. The river has now technically disappeared, it’s now in the branch. But then, somehow magically, that branch is merged back into the river. Which river you ask? I don’t know. The river should actually be in the branch now, but somehow it still continues to exist and I can merge the branch back into the river. So, the river is in the river. Kind of doesn’t make sense.

This is exactly what happens when you merge the base branch into a work branch and then when the work branch is done, you merge that back into the base branch again. The mental model is broken. And because of that, you end up with a branch visualization that’s not very helpful.

Example Git History when using merge:

Example Git History when using merge

Note the many commits starting with Merge branch ‘main’ into … (marked with yellow boxes). They don’t even exist if you rebase (there, you will only have pull request merge commits). Also note the many visual branch merge loops (main into work into main).

Example Git History when using rebase:

Example Git History when using rebase

Much cleaner Git history with much less merge commits and no cluttered visual branch merge loops whatsoever.

Are there any downsides / pitfalls with rebase?

Yes:

1. Because a rebase moves commits (technically re-executes them), the commit date of all moved commits will be the time of the rebase and the git history loses the initial commit time. So, if the exact date of a commit is needed for some reason, then merge is the better option. But typically, a clean git history is much more useful than exact commit dates.

2. If the rebased branch has multiple commits that change the same line and that line was also changed in the base branch, you might need to solve merge conflicts for that same line multiple times, which you never need to do when merging. So, on average, there’s more merge conflicts to solve.

Tips to reduce merge conflicts when using rebase:

1. Rebase often. I typically recommend doing it at least once a day.

2. Try to squash changes on the same line into one commit as much as possible.

I hope this FAQ helps some teams out there.

Regular Expressions (short Regexes) are Strings that work as a DSL (domain-specific language) to do some common tasks within other Strings. A DSL can also be subscribed as “a programming language within a programming language”.

In the case of Regexes, the outer programming language can be any programming language that supports the Stringtype, it just has to support Regexes. Nearly all popular programming languages support Regexes, which makes Regexes so useful to know. The inner language of Regexes consists of only String with some characters having a special meaning.

For example in the String ".*@.*\\.com" the . means “any character”, the * means “any amount of ”, together .* means “any amount of any character”. Then we have a non-special character @, then again .*followed by \\ which means “escape the next character and treat like a non-special character” so \\. together reads like a normal . character without the special meaning “any character”. Lastly, there’s com which is just a set of characters without any special meaning. Overall this Regex is a simple matcher for any email address ending with .com and containing a @ somewhere.

What can I do with the “Regular Expression DSL”?

ℹ️ With Ruby installed (on Macs it’s preinstalled), you can type irb to start an interactive Ruby shell to play around with the samples below.

There are three main functions that any Regex string can be used with:

1. matches: Given a Regex and another String, this function checks if the given String “matches” the Regex. This means if there’s “any” part within the given String that matches the specified Regex, it returns true, otherwise, it’s false. For example in Ruby (where matches is called match? – ? is part of the function name):

/.*@.*\\.com/.match?('harry.potter@hogwarts.co.uk') # => false /.*@.*\\.com/.match?('queenie.goldstein@ilvermorny.com') # => true

1. captures: Given a Regex and another String, this function can read substrings out of the given text which matches marked portions of the given Regex. The portions in the Regex can be marked via ( and ). They are called “capture groups”. For example in Ruby (where captures can be accessed on the Match object):

/(.*)@(.*)\\.com/.match('queenie.goldstein@ilvermorny.com').captures # => ["queenie.goldstein", "ilvermorny"]

1. replace: Given a Regex and a Template String, this function can automatically replace matches with a given String where even the capture groups can be referenced via $1, $2 or in some languages also \\1 , \\2, etc. For example in Ruby (where replace is called gsub):

'queenie.goldstein@ilvermorny.com'.gsub(/(.*)@(.*)\\.com/, '\\1@\\2.org') # => "queenie.goldstein@ilvermorny.org"

What does the “Regular Expressions DSL” look like?

There’s plenty of useful “cheat sheets” for this with great examples:

• https://www.rexegg.com/regex-quickstart.html#chars

• Regular Expression Examples

Generally, there are 5 different kinds of DSL components to understand:

1. Character/Group Modifiers (e.g. *, +, {,}, ?)

The default “building” block of Regexes are characters. After each character, you can write a modifier that tells how many times the preceding character is matched. The following modifiers are available:

**0 or 1 times: **
? (example: a?b?c? matches all of a, ab, abc, bc, c)

**1 time exactly: **
No modifier (default)

**0 to ♾️ times: **
* (example: a*bc matches bc, abc, aaabc)

1 to ♾️ times:
+ (example: a+bc matches abc, aaabc but not bc)

X times exactly:
{X} (example: a{3}bc matches aaabc but not aabc, aaaabc)

X to Y times:
{X,Y} (example: a{2,5}bc matches aaaaabc, but not abc)

X to ♾️ times:
{X,} (example: a{2,}bc matches aaaaaaaabc but not abc)

The same modifiers also work on Groups (e.g. (abc)+) (see below for groups).

Custom Sets (created with [ and ])

You can define custom sets of characters by listing them without any separator within brackets, e.g. for a set of the characters a, b, c and numbers 1, 2, 3 we would write [abc123]. This is then considered as “one character of this set”, thus matching multiple of them need character modifiers as in [abc123]* or [abc123]{2,5}.

You can also use ^ at the beginning of a custom set to specify that you accept any character except the set you specified in the brackets, e.g. [^\\n] to accept any character except a newline.

Characters of which you know are ordered right after each other like numbers or the Alphabet you can also use ranges by putting a - in between, e.g. [a-zA-Z0-9].

[abc123]{3,} would not match a, b, c, ab, but would match 111, abc

Predefined Sets (\\s, \\S, \\d, \\D, \\w, \\W)

The following sets (simplified) are already pre-defined and can be used directly:

• \\s effectively same as [ \\t\\n], reads “any whitespace character”

• \\S effectively same as [^ \\t\\n], reads “any non-whitespace character”

• \\d effectively same as [0-9], reads “any digit”

• \\D effectively same as [^0-9], reads “any non-digit”

• \\w similar to [a-zA-Z_0-9] (includes Umlauts etc.), reads “any word character”

• \\W similar to [^a-zA-Z_0-9] reads “any non-word character”

Groups (e.g. ( and ), (?<name> and ))

Groups could be thought of like “words” or “sentences”, they change the default building block, which is “character” for any modifier to a set of characters, or a “group”. For example, writing abc* reads “one time a, one times b and any number of times c”. If you want to write “any number of times abc” you do this: (abc)*. The abc is then considered one group and the regex would match the whole string abcabcabc.

Groups also allow for specifying different options to choose from. For this, you write a group and separate the different words via a | like so: (abc|def) – this reads “either abc or def” and would match both 123abc123 and 456def456 but not adbecf.

These capture some sub-portions of a Regex and assign them a number or name which then can be used to reference them in code or in replacement template Strings. Typically capture groups like in (.*)@(.*).com are used then referenced back via \\1@\\2.com or $1@$2.com (depending on the language).

It’s also possible to give the groups names, e.g. (?<user>.*)@(?<domain>.*).com to reference back like in ${user}@${domain}.com, but these are advanced features which are implemented differently in different languages (and are missing in some).

Match Modifiers (e.g. \\A, \\z, ^, $, Lookaheads and Lookbehinds)

By default, a match for a Regex, like abc is done like a contains method. But you can also specify that the abc string needs to be at the beginning or end of a given string or of a line. For example, the ^ in ^abc makes sure only strings with abc at the beginning of a new line match. This will match def\\nabc but not defabc. The $ in abc$ makes sure there’s a line-end after abc. Use \\A and \\z to match among the entire String (matching multiple lines).

Lookaheads & Lookbehinds are more of an advanced topic and useful mostly when you want to match that the beginning or end of your Regex does NOT match a given Regex. In most cases, Regexes with Lookaheads & Lookbehinds can be rewritten with Capture Groups, so you should try to write them as Capture Groups instead and only read about these if the other options don’t work as Lookaround are CPU-intensive operations and also kind of restricted (e.g. they don’t support most modifiers).

Here’s a good place to learn about them:

Common Quirks and validating new Regexes

One common thing to consider is that . in most languages does not match the newline character by default. But it can typically be turned on with an option, in Ruby by specifying the /m at the end which stands for “make dot match newlines”.

Also note that in every language there are different characters that are reserved due to how Strings work in them, for example in Ruby / needs to be escaped with \\/, in Swift this escape is not needed but there you need to escape { and } with \\{ and \\}. These quirks are important to remember when copy & pasting Regexes written for other languages.

Generally, when writing a new Regex, I recommend using a website or tool with 3 features:

1. An option to add a sample String to match against.

2. A Regex cheat sheet visible right on the screen to look up things.

3. A live matcher for the regex you write among the given sample String.

The site I’ve come to use here is this (runs Ruby in the background):

Rubular

How can I use Regexes in my projects today?

There’s no need to wait until there’s a good opportunity to use Regexes, you can simply lint your projects using Regular expressions (including Auto-Correction support) via AnyLint:

github.comFlineDev / AnyLintLint anything by combining the power of scripts & regular expressions