DEV Community: swiftui

Designing friction instead of blocking: what I learned building a screen-time app

Martin Ma — Sat, 17 Oct 2026 23:45:36 +0000

App Store: https://apps.apple.com/us/app/id6769946195

The problem with every blocker I tried

I've tried the usual stuff on my own phone: hard limits, one-tap locks, deleting apps. They all fail the same way. The block is absolute, so the fix is absolute too — you flip the switch off, and you're back to zero. Every attempt resets to the same starting line.

My wife had the same pattern, worse: down at eleven, still awake at two, half of it short video and half of it shopping. So instead of another lock, I tried the opposite: keep access, add a small pause.

Three rules we committed to

Never make it impossible. If the user can't get back in, they'll remove the app — and then there's no signal left to work with.
Make the exit visible. Every bypass is counted and shown back to you. Hiding friction removes the feedback loop that changes behaviour.
Never go around the system. No MDM profiles, no fake network tricks. Use the platform's own Screen Time stack.

What that looks like on iOS

Under the hood it's the Screen Time APIs (Family Controls authorization, DeviceActivity for monitoring, ManagedSettings for shields). The interesting part isn't the API calls — it's the choices on top of them:

Per-app allowance instead of one global limit. A single 60-minute budget for the whole phone gets spent in ten minutes. Per-app budgets spread out.
A pause screen, not a wall. When the allowance runs out you get a sentence and a way back in: wait a bit, or use one of a small number of unlocks you chose in advance.
Unlocks are logged, not blocked. The point isn't prevention at all costs: it's seeing the pattern (three unlocks at 1am is information, not failure).
Friend Freeze. A trusted person can freeze apps for you for a set window. Accountability without surveillance.

What changed, measured

Before: phone in hand until 2am, screen time after midnight ~50 minutes. After six weeks: down to about 20 minutes, and the useful part — it didn't feel like a fight. The unlock count went from 5–6 a night to 0–1.

If you want to try it

ChoiceField is free to start on iOS 17+. No account, everything on-device.

https://apps.apple.com/us/app/id6769946195

If you're building something similar and want to compare notes on the Screen Time APIs — especially the entitlement review process — happy to share what we hit.

Add a video editor to your iOS app (UIKit and SwiftUI)

Rajesh Sharma — Sat, 17 Oct 2026 16:10:21 +0000

If you ship a Swift app, you already know where Apple's help stops.
UIVideoEditorController trims a clip. AVFoundation will compose, mix and encode whatever you describe to it. Neither
gives your users a timeline to drag clips on, a text tool, or music they can line up with a cut. This post walks through adding Nitrakit, an iOS video editor SDK, to a UIKit or SwiftUI app, and what changes when the same code runs on macOS. Every snippet is taken from the
iOS guide.

Where AVFoundation ends and the editor begins

Apple's frameworks are good at the media work: reading assets, composing tracks, exporting a file. What they leave to you is the product your users touch. A scrubbing timeline with snapping. Text they can pinch to size. Undo that covers every gesture. A preview that shows exactly what the export will contain. That surface is where in-house editors spend their time, and we've laid out the trade-off for decision-makers in Build or buy an in-app video editor.

Nitrakit fills that gap with two UIViews and a project object. You keep AVFoundation for whatever else your app already does with it, such as recording or playback elsewhere.

Add the iOS video editor SDK as a Swift package

There's nothing to sign up for before you install. In Xcode, open File → Add Package Dependencies, paste https://github.com/Nitrakit/nitrakit-swift, and tick both products for your app target: Nitrakit and NitrakitUI. Teams that manage dependencies in a manifest add this instead:

dependencies: [.package(url: "https://github.com/Nitrakit/nitrakit-swift", from: "0.2.0")],
// in your target:
.product(name: "NitrakitUI", package: "nitrakit-swift"),

The floor is iOS 16 or macOS 13. Builds and test runs need no key.

One `Editor` per project

Everything the user does lands in an Editor: the clips, the text, the undo stack. Give it the canvas size and frame rate you want to publish at, then place the first clip:

let editor = Editor(width: 1080, height: 1920, fpsNum: 30, fpsDen: 1)

let media = try editor.addMedia(id: assetId, file: pickedFileURL)
let track = try editor.apply(edit: .addTrack(kind: .visual, magnetic: true))
_ = try editor.apply(edit: .insertMedia(
    track: track, source: media.source,
    startUs: 0, sourceInUs: 0, durationUs: media.durationUs))

Note the assetId. It's whatever key your backend or local store already uses for that file, and it's the only way the project names its media. That small choice is why a project can later reopen on a different device.

UIKit: two views, your layout

The editor arrives as a pair. NitrakitPreviewView shows the video and lets people grab and move layers on it; NitrakitTimelineView holds the timeline, the tool bar and its panels. Point both at the same Editor:

import NitrakitUI

let preview = NitrakitPreviewView(frame: .zero)
preview.editor = editor

let dock = NitrakitTimelineView(frame: .zero)
dock.editor = editor

From there they behave like any view you constrain in Auto Layout or a stack view. A common arrangement puts the preview above a dock roughly 400 points high. Build them in code, not in Interface Builder.

Splitting the editor this way pays off when a screen needs less than everything. A caption fixer could show the preview alone with your own transport buttons. An app with a toolbar of its own might show just the timeline. The layouts page shows each variant.

SwiftUI: wrap once, then compose

Both views are UIKit views, so SwiftUI needs a thin wrapper, written once. Each one goes into a UIViewRepresentable, and a plain SwiftUI View stacks them:

import SwiftUI
import Nitrakit
import NitrakitUI

struct EditorPreview: UIViewRepresentable {
    let editor: Editor
    func makeUIView(context: Context) -> NitrakitPreviewView {
        let view = NitrakitPreviewView(frame: .zero)
        view.editor = editor
        return view
    }
    func updateUIView(_ view: NitrakitPreviewView, context: Context) {}
}

struct EditorDock: UIViewRepresentable {
    let editor: Editor
    var onRequest: (@MainActor (EditorRequest) async -> RequestResponse?)?
    func makeUIView(context: Context) -> NitrakitTimelineView {
        let view = NitrakitTimelineView(frame: .zero)
        view.editor = editor
        view.onRequest = onRequest
        return view
    }
    func updateUIView(_ view: NitrakitTimelineView, context: Context) {}
}

struct EditorScreen: View {
    let editor: Editor
    var body: some View {
        VStack(spacing: 0) {
            EditorPreview(editor: editor)
            EditorDock(editor: editor, onRequest: { request in nil })  // your pickers: step 5
                .frame(height: 400)
        }
        .background(Color.black)
    }
}

The one SwiftUI trap is identity. body runs often, so the Editor must live outside it: in your observable model, or in @State that you fill on appear. Push EditorScreen from a NavigationStack, present it as a sheet, or put it in a tab; it's an ordinary view to the rest of your hierarchy.

The same editor on the Mac

The package also builds for macOS 13 and later, with AppKit views. In a SwiftUI Mac target, swap UIViewRepresentable for NSViewRepresentable and keep the rest of the structure. One
difference to plan for: on macOS the SDK ships no built-in choosers for fonts, colours or filters, so your app supplies every one of those screens. In return, a Mac companion app can share the editing feature, and its projects, with your iOS code.

Photos access and your media library

Nitrakit never asks the user for anything by itself. It doesn't present the photo library, a document browser, or a font list unprompted. When someone taps Add media, the timeline view
calls your onRequest closure, and your app decides what appears. That might be [PhotosUI (https://developer.apple.com/documentation/photosui), your own catalogue of stock clips, or a list of the user's uploads from your server:

dock.onRequest = { request in
    switch request.kind {
    case .addMedia, .addOverlay, .addAudio, .addSticker:
        guard let file = await presentMediaPicker() else { return .cancel }   // your picker
        let id = startUpload(file)                                            // your storage
        let media = try? editor.addMedia(id: id, file: file)
        return media.map { .source(id: $0.source) } ?? .cancel
    default:
        return nil // built-in picker
    }
}

Because the closure is async and isolated to the main actor, presenting a sheet and awaiting the choice reads top to bottom, with no delegate dance. Returning nil hands fonts, colours, text styles and filters to the SDK's stock screens on iPhone and iPad, so a first build only has to wire up media. The full request list is on the
Pickers page.

On permissions: if your flow reads from the user's photo library, your Info.plist needs an NSPhotoLibraryUsageDescription string, as it would without Nitrakit. The SDK itself requests nothing.

Drafts that follow the user

A project serialises to JSON that refers to media by your ids, so your app decides where drafts live: on the device, in iCloud, or on your own backend.

let json = editor.toJson()

let reopened = try Editor(open: json)
reopened.loadMedia()   // from the device, else through NitrakitMedia.resolve

Start a reel on the iPhone, finish it on the iPad. When a draft opens somewhere its files aren't, the SDK calls one async function you set at launch, and you answer with a URL (signed or not). Clips show download progress while they arrive:

NitrakitMedia.resolve = { id in
    .remote(try await api.signedURL(for: id))   // or .file(localURL)
}

For autosave, register a change listener on the editor. Missing files and uploads in flight are covered in [Projects and media (https://docs.nitrakit.dev/concepts/projects-and-media/).

Rendering the final MP4

Rendering happens off the main thread, and the timeline stays usable while it runs. You pass a path and a listener:

final class Progress: ExportListener {
    func progress(fraction: Float, frames: UInt64, total: UInt64) {
        DispatchQueue.main.async { /* update your progress bar */ }
    }
    func finished(result: ExportResult, message: String) {
        // .done: the file is at your path. .cancelled or .failed: no file (message says why).
    }
}

let job = editor.export(path: outputPath,
                        settings: editor.exportSettingsFor(shortSide: 1080),
                        listener: Progress())
// job.cancel()

Callbacks arrive on the export thread, hence the hop to the main queue. Once .done comes back, the file is yours: hand it to PHPhotoLibrary, a share sheet, or your upload queue. The Export page lists the settings.

Users who speak on camera can also get captions timed word by word, from the speech-to-text service your app already uses. The text and captions guide shows how.

Match your app, including dark mode

Designers will want the editor to feel native to your product, not to ours. The theme is set on the dock:

dock.theme = EditorTheme(
    background: "#101418",
    bar: "#0b0e11",
    accent: "#2ee6a6",
    font: "Brand Sans",
    clips: .init(video: "#3355ff", audio: "#18a058")
)

The editor doesn't watch the system appearance on its own. Read the trait collection when it changes and assign the light or dark theme you've defined; that keeps the decision with your design system. Tools can be hidden or added, icons replaced and labels translated, all at run time. The [Customisation docs (https://docs.nitrakit.dev/customization/) cover each.

Before you submit to App Review

Two things to sort out before a build goes to TestFlight for real users.

The license key. Development and testing run without one. For the release, the key is set once at launch, for example in the app delegate:

import NitrakitUI

let status = NitrakitLicense.set("nk2.…")
if !status.problems.isEmpty { print("Nitrakit:", status.problems) }

It's tied to your bundle IDs, which is why it isn't a secret and can sit in source control. If a bundle ID doesn't match, problems tells you. See the License key page.

Download size. The SDK adds one dynamic framework, and App Store thinning ships only the device slice. The App size page has the current figures and explains how App Store encryption affects them.

Where to go from here

The fastest check is to paste EditorScreen into a scratch SwiftUI project and point it at a clip on the simulator. If you'd rather click before you compile, the browser demo runs the same editor. Ready to wire it into your real app? The iOS guide goes step by step, and the
iOS overview sums it up for whoever signs off. Your Android team gets the same editor from the Android guide, and a React Native app can share one codebase: [see that post (https://nitrakit.dev/blog/react-native-video-editor/).

Shipping date in sight? Talk to us about a key. Stuck on something in Xcode? The Nitrakit Discord is where we answer.

Hidden Screenshot Preview API in watchOS 27.2

Saeed iPhone — Thu, 15 Oct 2026 10:51:58 +0000

Recent discovery in watchOS 27.2 reveals a hidden feature flag related to screenshot management. Currently, watchOS triggers a direct transfer to the paired iPhone via the Bridge framework. The new implementation suggests a local preview UI layer, likely utilizing SwiftUI or a specialized UIKit overlay, allowing users to handle UIImage buffers before transmission. This indicates a shift toward more granular control over system-level media capture events.

منبع خبر: https://www.macrumors.com/2026/09/24/watchos-27-2-screenshot-previews/

Stop Using NavigationView - Mastering NavigationStack in 2026

Ahtisham Hasan Khan — Sat, 03 Oct 2026 16:05:49 +0000

If you are still wrapping your SwiftUI views in NavigationView in 2026, we need to talk.

Apple soft-deprecated NavigationView years ago. While it might still "work" for simple prototypes, it is a nightmare for scalable, real-world applications. If you want to handle push notifications, deep links, or complex onboarding flows, you must use NavigationStack.

In this guide, I’ll show you how to move from "Push-and-Pray" navigation to a robust, state-driven routing system.

The Problem with the Old Way

In the early days of SwiftUI, we used NavigationLink directly inside our lists. It looked innocent enough:

// The Old Way (Don't do this anymore)
NavigationView {
    List(0..<5) { i in
        // ❌ Problem: DetailView is initialized immediately for EVERY row!
        NavigationLink("Go to Detail \(i)", destination: DetailView(i: i))
    }
}

Two things go wrong here. First, NavigationLink(destination:) builds every DetailView up front, even for rows nobody taps. Second, navigation lives inside the views. There is no single value that says "the user is on screen X", so you can't push a screen from a notification, restore it from a deep link, or pop back to the root from code.

The New Way: navigation as data

NavigationStack (iOS 16+) flips this around. You describe where a link goes with a value, and you describe how to show that value once, with navigationDestination(for:):

struct ContentView: View {
    var body: some View {
        NavigationStack {
            List(0..<5) { i in
                // ✅ Only a value is created here. DetailView is built on tap.
                NavigationLink("Go to Detail \(i)", value: i)
            }
            .navigationDestination(for: Int.self) { i in
                DetailView(i: i)
            }
        }
    }
}

The destination view is now built lazily, and the link only carries an Int.

Step 1: Model your routes

Real apps have more than one kind of screen. Put them in one Hashable enum so every place in the app can name a destination the same way:

enum Route: Hashable {
    case profile(userID: String)
    case settings
    case order(id: Int)
}

Step 2: Own the path in a router

Bind the stack to an array of routes. Whoever owns that array controls navigation:

import Observation

@Observable
final class Router {
    var path: [Route] = []

    func push(_ route: Route) { path.append(route) }
    func pop() { _ = path.popLast() }
    func popToRoot() { path.removeAll() }
}

@Observable needs iOS 17. On iOS 16, make it an ObservableObject with @Published var path.

Step 3: Wire the stack to the router

struct RootView: View {
    @State private var router = Router()

    var body: some View {
        NavigationStack(path: $router.path) {
            HomeView()
                .navigationDestination(for: Route.self) { route in
                    switch route {
                    case .profile(let userID): ProfileView(userID: userID)
                    case .settings: SettingsView()
                    case .order(let id): OrderView(id: id)
                    }
                }
        }
        .environment(router)
    }
}

Any child view can now navigate without knowing about its parents:

struct HomeView: View {
    @Environment(Router.self) private var router

    var body: some View {
        Button("Open settings") { router.push(.settings) }
    }
}

Step 4: Deep links and notifications for free

Because the whole stack is just [Route], opening a screen from outside the UI means setting an array. For a URL like myapp://order/42:

.onOpenURL { url in
    guard url.host == "order",
          let id = Int(url.lastPathComponent) else { return }
    router.path = [.order(id: id)]
}

The same works when a push notification arrives: parse the payload into a Route and assign the path. To jump several screens deep, assign several routes, for example [.profile(userID: "me"), .settings].

Mixed value types: NavigationPath

If different features push unrelated types and you don't want one big enum, use NavigationPath, a type-erased path that accepts any Hashable value:

@State private var path = NavigationPath()

NavigationStack(path: $path) {
    FeedView()
        .navigationDestination(for: Post.self) { PostView(post: $0) }
        .navigationDestination(for: User.self) { UserView(user: $0) }
}

An enum is easier to read and test, so I start there and only reach for NavigationPath when features need to stay independent.

Quick migration checklist

Replace NavigationView with NavigationStack. For sidebar layouts on iPad and Mac, use NavigationSplitView.
Change NavigationLink(destination:) to NavigationLink(value:).
Add one navigationDestination(for:) per value type, high in the hierarchy rather than inside lists.
Move the path into a router you can reach from anywhere.
Route deep links and notifications by assigning the path.

If you're building an iOS app and want routing like this from day one, that's the kind of work I do.

Originally published at iahtisham.com.

I'm Ahtisham, an independent iOS developer building native Swift apps. More from me:

🌐 Portfolio and client work: iahtisham.com
💸 AppPriceKit: free App Store subscription prices by country
🧾 JustInvoice: invoice maker for iPhone
📄 ScanIt: document scanner and PDF for iPhone
🌙 NUR: prayer times, offline Qur'an and adhkar, free with no ads
🏢 PrismCode Labs

Find me on X @iAhtishamDev · GitHub · LinkedIn · Upwork

Continuous Native iOS Widget Animation in Pure SwiftUI: Architecture & App Store Review

Nikita Limo — Fri, 02 Oct 2026 18:47:40 +0000

Within the iOS developer community, a deep-rooted belief exists that creating continuous, fluid animation on home screen widgets is technically impossible due to Apple's strict refresh limits and resource allocation policies. Most attempts to realize such a UI boil down to using heavy image sequences or wrappers for video files, which inevitably leads to RAM overload, battery drain, and swift rejection during App Store Review.

However, this "technical impossibility" is a myth born from the wrong approach. Continuous animation is absolutely possible, provided the widget architecture is built exclusively on native, mathematically deterministic SwiftUI mechanisms, without attempting to "bypass" the system.

Does Apple Allow Widget Animation? Official WidgetKit Documentation

The official Apple documentation (in the Animating data updates in widgets and Live Activities section) explicitly states:

"Widgets and Live Activities support all built-in SwiftUI transitions and animations."

The system does not prohibit animation. It prevents the inefficient use of resources. Passing App Store Review goes smoothly: since the developer uses exclusively Apple's native ecosystem, it would be completely illogical for moderators to reject an application that works flawlessly and optimally on their own built-in technologies.

Architecture Without GIF or Video: Bézier Curves (Path) and TimelineProvider

Instead of forcing the TimelineProvider to manually refresh the widget dozens of times per second, the approach is built on orchestrating three core native components:

Deterministic Timeline: TimelineProvider is used strictly for its intended purpose—it delivers key anchor states at permitted intervals. It does not generate the animation itself; it sets the schedule of states.
Vector Geometry (Bézier Curves): All graphical elements are drawn via Path. Complex objects are not images, but pure mathematics:

path.addCurve(to: CGPoint(x: toX, y: toY), 
              control1: CGPoint(x: control1X, y: control1Y), 
              control2: CGPoint(x: control2X, y: control2Y))

Native Interpolation: The heavy lifting is done by the standard SwiftUI modifier. When the timeline switches a state, the system hardware (via CoreGraphics) smoothly renders the morphing:

.animation(.spring(response: 1.5, dampingFraction: 0.65), value: state)

Why Developers Give Up, or The Complexity of Native Vector Morphing

The reason for the lack of such solutions in the market lies in the extremely high barrier to entry. Testing the fundamental principles of vector morphing inside WidgetKit and building a stable architecture takes months of deep R&D. However, now that the basic principle is clear and the core is built, creating a new complex animation takes no more time than assembling a standard file in popular editors like Lottie or Rive.

Advantages of Pure SwiftUI: Dynamic Color, 100 KB Size, and Zero Battery Drain

Utilizing pure code unlocks capabilities fundamentally unavailable to pre-rendered files:

Absolute Customization: In real-time, you can modify everything just like in the source vector file: shape, line thickness (stroke), transparency (.opacity), blur (.blur), scale (.scaleEffect), rotation (.rotationEffect, .rotation3DEffect), shadows (.shadow), and the color of any element, supporting the full spectrum of color models (RGB, HSB).
Multi-layering and Reactivity: A single widget can run several independent animations concurrently (for example, a continuous looped background animation and simultaneously an instant reaction to a "tap"). Animations easily bind to events: time of day, achieving a new level in a game, a system reminder triggering, or toggling a native switch right on the widget.
Extreme Optimization (50-100 KB): Once compiled, a highly complex animation weighs only 50-100 KB. An equivalent result in a video format would consume megabytes of memory.

Integration with Flutter, React Native, and Support for 4x6 Widgets in iOS 27

Because the architecture is based on foundational Swift, it possesses 100% versatility:

Integration: The native Widget Extension is written in Swift but seamlessly integrates with any cross-platform projects on Flutter, React Native, and other frameworks (via App Groups).
Dimensions: The graphics fit perfectly into any size—from the classic Small size up to the massive 4x6 widgets introduced in iOS 27.
Ecosystem: Code written once requires no additional adaptations and runs natively on iPhone, iPad, macOS desktop widgets, in the Smart Stack on Apple Watch, and also supports 120Hz ProMotion on Pro device displays.

Proof of Concept: Offline Mode and Xcode Profiling

Any developer can verify the absence of "hidden hacks" or server-side computations (convincing someone that we do not use third-party engines like Lottie/Rive is pointless, as iOS fundamentally blocks them at the widget level) by observing the following criteria:

Full Autonomy (Offline mode): When network access is disabled (Airplane mode), continuous animation and dynamic color changes continue to work without interruptions.
Infinite Zoom: When the graphics are heavily zoomed in, the quality remains crystal clear, without pixelation effects.
Security Audit and Resource Profiling: The source code of the open XCFramework can be downloaded from my GitHub repository and run through any static code analysis systems or Xcode Instruments. You will personally confirm that it exclusively uses Apple's native frameworks, exhibits no memory leaks, and places minimal load on the CPU.

Production Examples

Evaluate the technology in production through published apps:

Lim: Relaxing Animated Widgets: Interactive, aesthetic continuous animations. View Project
Clock Widgets Home Screen: Continuous native motion utility widgets. View on App Store

Deep Dive into Architecture & B2B Services
This article is part of our comprehensive documentation on native iOS motion.
To see how this is built under the hood using Bézier curves and TimelineProvider, read the full Architecture & App Store Review guide.

Looking to implement continuous animation in your product without failing App Review? We provide production-ready XCFrameworks. Explore our Custom Engineering Services.

How to stop your AI coding agent from inventing SwiftUI UI

Daniel S — Sat, 26 Sep 2026 05:39:07 +0000

Ask a coding agent for a few SwiftUI screens in separate sessions and you get a separate set of decisions each time. The corner radius is 10 on one and 12 on another. The blue is .blue here and Color(red: 0.2, green: 0.4, blue: 0.9) there. Each screen compiles and looks fine alone. Side by side they read as different apps, and each fix is another prompt to pay for.

The agent has nothing in the project that says what your app looks like, so it guesses. The setup below gives it something to read and something to run into when it strays. It uses DesignFoundation, a free MIT-licensed SwiftUI package I work on, but the three parts (a token theme, instruction files, a lint rule) apply to any design system. The longer argument for why this works is in the companion post on the NerdSnipe blog.

Step 1: put the theme in the environment

Add the package. It needs Xcode 16 and targets iOS 18, macOS 15, and visionOS 2.

dependencies: [
    .package(url: "https://github.com/NerdSnipe-Inc/design-foundation", from: "1.0.0")
]

Then set a preset once at the app root:

import SwiftUI
import DesignFoundation

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .dfThemePreset(.slate)
        }
    }
}

Five presets ship: .slate, .aurora, .copper, .sage, and .garnet. Each has a light and a dark theme and follows the system setting. Every DesignFoundation component below that modifier reads colors, spacing, radii, typography, and shadows from the theme, so DFButton("Save") { } picks up the preset without any styling in the call.

Your own views read the same tokens through the environment:

struct ProfileChip: View {
    @Environment(\.dfTheme) private var theme
    let name: String

    var body: some View {
        HStack(spacing: theme.spacing.sm) {
            Circle()
                .fill(theme.colors.primary)
                .frame(width: 8, height: 8)
            Text(name)
                .font(theme.typography.label.font)
                .foregroundStyle(theme.colors.textPrimary)
        }
        .padding(.horizontal, theme.spacing.md)
        .padding(.vertical, theme.spacing.xs)
        .background(theme.colors.surfaceElevated, in: Capsule())
    }
}

To change one thing, copy a theme, edit it, and inject it:

var custom = DFTheme.sageLight
custom.colors.primary = .purple

ContentView().dfTheme(custom)

Step 2: give the agent the rules

The repo ships instructions for the agents that will write against it: AGENTS.md, CLAUDE.md, a Cursor rule at .cursor/rules/design-foundation.mdc with alwaysApply: true, and docs/llms.txt. The first rule in all of them is to never build UI the package already provides. Below that they list real signatures, mostly the places generic SwiftUI habits break. Three examples:

DFCheckbox(isChecked: $agreed, label: "I agree")             // label: is a keyword argument
DFButton("Delete", style: .ghost, role: .destructive) { } // destructive is a role; no icon: or isLoading:
DFText("Account", scale: .headline)                        // scale:, not style:

SwiftPM checks out the whole repository, so these files are already on your disk once the package resolves. In a package-manifest project they sit in .build/checkouts/design-foundation/. In Xcode they are under DerivedData in SourcePackages/checkouts/design-foundation/. I confirmed both AGENTS.md and the Cursor rule are present in a fresh checkout of the current release.

How you wire them into your own app is up to you, since the package doesn't prescribe it. Two options I'd consider. You can copy the file your agent reads into your app repo, which is simple and goes stale when you upgrade the package. Or you can point your app's own instruction file at the checked-out copy, so it updates with the package:

# UI rules
Before writing any SwiftUI, read the DesignFoundation instructions at
.build/checkouts/design-foundation/AGENTS.md and follow them.
Never build a component that DesignFoundation provides.

That block is my example, not something from the repo. Adjust the path for your setup.

The repo also has a workflow, doc-snippets.yml, that compiles every Swift block in those files against the real package on every change, so the instructions can't drift from the API unnoticed. I compiled the snippets in this post against the current release for the same reason.

The cost is context. AGENTS.md is about 400 lines, and the agent loads it every session. If you are generating one small screen, that overhead can outweigh the saving.

Step 3: add the lint rules

Instructions can't stop a raw Color(red:green:blue:) from landing in a pull request, and neither can the Swift compiler. The package includes Tooling/swiftlint-design-foundation-tokens.yml, a block of SwiftLint custom_rules with four rules:

design_foundation_no_raw_color for Color(red:...), Color(hue:...), and similar
design_foundation_no_named_color_literal for Color.red, Color.gray, and the rest
design_foundation_no_raw_font for .font(.system(...))
design_foundation_no_hardcoded_corner_radius for cornerRadius: 10

Merge the block into your .swiftlint.yml, or pull it in with !include. Each rule has a message that names the token to use instead, for example "A literal corner-radius value won't track a theme's radius scale, use theme.radius.sm/md/lg/xl instead." An agent that runs SwiftLint reads that message and knows the fix.

The rules are regex-based and set to warning, so expect the occasional false positive, like a preview fixture or a third-party API that needs a plain Color. Silence those on the line with // swiftlint:disable:next design_foundation_no_raw_color. In CI, the warnings show up on the pull request.

You still review every diff, since none of this makes the agent's logic correct. The components don't need #if os(), but your own scene declarations and any platform API the package doesn't wrap still do. The token saving is less generated code, and no benchmark backs a number for it: the docs site's "Foundation Way" comparison page rests on its own line-count samples and a rough 35-characters-per-line estimate.

If you keep asking the agent for the same whole screens (sign-in, analytics, settings) and rewiring them each time, there's a paid add-on on the same tokens, DesignFoundationPro, with 55 finished screens and 18 navigation shells. The free package works without it.

The source is on GitHub, and the docs have the component reference. Build one real screen in a sandbox app, then run SwiftLint over it.

Turn any iOS app into a full HTTPS server

Danilo — Thu, 24 Sep 2026 17:37:20 +0000

https://github.com/priore/SwiftCoreWeb

Design Handoff That Survives Contact With SwiftUI, Compose and React Native

James Sanderson — Wed, 16 Sep 2026 14:19:19 +0000

You receive a Figma link. The screens are clean, the spacing is consistent, and the prototype clicks through nicely. Then you start building and the questions arrive. What does this list do with 2,000 rows? What happens when the display name is 40 characters? Where is the offline state? Does this sheet behave the same on a foldable?

The design was not wrong. It was incomplete in exactly the places that cost engineering time. This post is a developer-side view of what a handoff should contain so that it maps to real code.

Tokens are the contract, not the artwork

If the design system only exists as Figma styles, every engineer re-derives it by eye, and drift starts on day one. The fix is a token source of truth that generates platform constants.

A minimal token file might look like this. Illustrative only; your naming scheme will differ.

{
  "color": {
    "surface": { "default": "#FFFFFF", "raised": "#F5F6F8" },
    "text": { "primary": "#14161A", "secondary": "#5B6270" },
    "accent": { "default": "#2F5BEA" }
  },
  "space": { "xs": 4, "sm": 8, "md": 16, "lg": 24 },
  "radius": { "card": 12 }
}

Generated for SwiftUI. Illustrative output.

enum Tokens {
    enum Color {
        static let surfaceDefault = SwiftUI.Color("surfaceDefault")
        static let textPrimary = SwiftUI.Color("textPrimary")
        static let accentDefault = SwiftUI.Color("accentDefault")
    }
    enum Space {
        static let sm: CGFloat = 8
        static let md: CGFloat = 16
    }
}

And for Jetpack Compose. Illustrative output.

object Tokens {
    val SurfaceDefault = Color(0xFFFFFFFF)
    val TextPrimary = Color(0xFF14161A)
    val AccentDefault = Color(0xFF2F5BEA)
    val SpaceSm = 8.dp
    val SpaceMd = 16.dp
}

For React Native, the same source typically emits a typed theme object consumed by a StyleSheet or your styling library of choice.

A few rules make this hold up:

Semantic names, not raw values. text.secondary, not grey500. Dark mode and theming then become a mapping change rather than a refactor.
Colours reference asset catalogues or resources so light and dark variants live in platform-native places.
Typography tokens map to scalable text styles, so Dynamic Type on iOS and font scaling on Android keep working.
One pipeline, versioned. Token changes arrive as a reviewable diff, not a Slack message.

Ask your design partner whether their components correspond one to one with code components. If the Figma "Card" has six variants and your code has two, someone will guess.

Document every state, or developers will invent them

Happy-path screens are maybe a third of the UI. The rest is states. A usable handoff specifies, per screen or component:

Empty. First run, no results, filtered to nothing. These are different states with different copy.
Loading. Skeleton or spinner, and what is interactive while loading.
Error. Recoverable versus fatal, retry behaviour, and message tone.
Offline. Cached content shown with a staleness cue, queued actions, and what is disabled.
Partial data. Missing avatar, missing price, one field failed to load.

One cheap way to enforce this in code is to model the states explicitly, so an undesigned state is a compile-time gap rather than a runtime surprise. Illustrative Kotlin.

sealed interface OrdersUiState {
    data object Loading : OrdersUiState
    data object Empty : OrdersUiState
    data class Content(val orders: List<Order>, val isStale: Boolean) : OrdersUiState
    data class Error(val retryable: Boolean) : OrdersUiState
}

If a when over that type has a branch with no corresponding design, you have found a handoff gap before shipping it.

Stress cases belong in the spec

These are the questions that turn a two-day ticket into a two-week one when nobody answered them up front:

Long strings. Names, addresses and translated copy that are two or three times the English length. Truncate, wrap or scale? Where does the ellipsis go?
Large lists. A list with 2,000 items needs virtualisation, stable keys, pagination or incremental loading, and a decision about section headers and scroll position restoration.
Largest accessibility text sizes. Does the layout reflow, or does the horizontal row need to stack?
Foldables and tablets. Two-pane layouts, what happens on fold or unfold mid-task, and whether state survives configuration changes.
Low-end devices. Which animations are essential, and which can be reduced when the device or the user's reduced-motion setting asks for it.

A good mobile app design agency answers these in annotations. A great one has already prototyped the awkward ones.

Design QA on real builds, not screenshots

Comparing a screenshot to a Figma frame catches spacing bugs. It does not catch jank, gesture conflicts, keyboard overlap or a transition that feels wrong at 60 frames per second on a mid-range phone.

A workable rhythm:

Every build increment goes to designers on physical devices, both platforms, including at least one lower-spec Android phone.
Designers file issues against the build, tagged by severity, with a screen recording.
Engineers flag expensive interactions early, before polish, so the design can change while change is cheap.
Token or component changes go through the same review as code changes.

The teams that do this well treat designers as part of the build loop, not a phase that ended. That is also the practical argument for partners who handle design and mobile app development from one backlog: questions get answered in hours, not after a weekly sync.

For the buyer-side view of evaluating a design partner, including how to spot a genuine mobile specialist, see the full guide: Mobile App Design Agency: How to Choose One That Designs for Engineering, Retention and AI.

Frequently Asked Questions

What is the minimum a mobile design handoff should include?

A versioned token source, components that match code components, annotated screens covering empty, loading, error and offline states, motion specs, accessibility notes, and a commitment to review real builds during development.

Should design tokens live in Figma or in the repository?

Author them wherever designers work best, but export them to a versioned file in the repository and generate platform constants from it. The repository copy is what builds depend on, so changes should be reviewable.

How do tokens support dark mode on iOS and Android?

Use semantic token names and map them to asset catalogue colours on iOS and resource-qualified colours or theme values on Android. Switching appearance then changes the mapping rather than every component.

How should very long lists be specified?

The design should state loading behaviour, placeholder rows, section headers, empty and error states, and scroll restoration. Engineering then chooses virtualisation and pagination strategies that match that behaviour.

What does design QA on real builds catch that screenshots miss?

Frame drops, gesture conflicts with system navigation, keyboard overlap, touch target problems, awkward transitions and layouts that break at large text sizes or on foldable screens.

Can cross-platform frameworks share one token set?

Yes. A single token source can generate a theme object for React Native or Flutter alongside native SwiftUI and Compose constants, with platform-specific overrides where conventions differ.

iOS 27 Just Redefined Swift: 5 Game-Changing Features Every iOS Developer Must Master

JIBIN MATHEW — Wed, 16 Sep 2026 05:23:03 +0000

If you’ve been building iOS applications over the last few years, you are already familiar with the shift toward declarative UI and structured concurrency. But iOS 27 marks a watershed moment for the Apple developer ecosystem.

Just as iOS 7 dismantled skeuomorphism and iOS 13 brought SwiftUI into our daily lives, iOS 27 completely rewrites the rules for how Swift interfaces with system hardware, on-device neural engines, and spatial display pipelines.

If your team is still writing Swift patterns from 2022, your code isn't just accumulating tech debt—it’s falling behind the platform's core performance optimizations.

Here are the 5 biggest Swift and platform changes in iOS 27 that every iOS engineer, tech lead, and architect needs to master today.

1. Zero-Data-Race Concurrency: Region-Based Isolation is Mandatory

In previous Swift releases, handling data races across thread boundaries required manual actor isolation and constant annotations. With iOS 27 and the latest Swift toolchain, Region-Based Isolation is fully enforced at compile time.

Swift no longer just checks if a type is Sendable; the compiler tracks the memory region of mutable values across async execution boundaries.

Code Comparison: Transferring Non-Sendable State

Before (iOS 25/26 Workaround):


swift
// Needed verbose @unchecked Sendable or heavy locks
final class UserSession {
    var token: String
    init(token: String) { self.token = token }
}

func syncSession(_ session: UserSession) async {
    // Danger: Potential data race if mutated concurrently on another thread
    await Task.detached {
        print("Syncing: \(session.token)")
    }.value
}

What a small macOS tracker taught us about privacy boundaries

Klik — Tue, 15 Sep 2026 02:17:44 +0000

Pacering is a small open-source macOS productivity tracker from our wider R&D shelf. The interesting part is not another dashboard; it is where the product draws its data boundaries.

Keep the measurement loop understandable

The app is built with SwiftUI and Combine. It uses NSWorkspace to observe active applications, lets the user decide which apps count as work, and keeps the core tracking state in UserDefaults. UI-driven changes are debounced rather than written on every keystroke.

That is a modest architecture, but modest can be good: a user can understand what is measured, choose the relevant applications, set a daily goal, and inspect the resulting history.

Optional intelligence is a separate boundary

The repository also contains an optional GLM-backed analysis path. That distinction matters. “The tracker is local” should not be allowed to blur into “every optional analysis path is local.” Product copy, permissions, and implementation should all make that boundary legible.

Performance work is product work

The current code and README describe debounced persistence, cached window-title lookups, and limiting more expensive inspection to browser applications. Those are small choices, but together they reduce how intrusive a background productivity tool feels.

The broader lesson: privacy is easier to reason about when collection, local persistence, and optional network intelligence are separate decisions—not one vague toggle.

Source and implementation: https://github.com/chengyixu/pacering

iPhone Duo: What Apple's 'Boring' Keynote Actually Means for iOS Developers

Kirill Lukyanov — Mon, 14 Sep 2026 14:28:34 +0000

Apple's September keynote felt like "nothing interesting": a slightly faster Pro, a slightly pricier Pro, new watches, new earbuds, and a foldable that looked almost exactly like the leaks. For buyers, that's a fair summary. For iOS developers, it's the opposite — the evening quietly delivered the biggest layout change since the iPhone X notch, and the clock on it runs out on October 23.

The day before the event I published 13 predictions with probabilities. Here's how they did, what was actually shown, and — the part I really care about — what the iPhone Duo's inner display means for your code.

Scorecard: 11 out of 13

Probabilities were set on the morning of September 9, before the stream, and haven't been touched since. Anything below 50% means I was betting against the event.

Prediction	My odds	What happened	Result
A foldable iPhone is shown	95%	Shown — iPhone Duo	✓
It's called iPhone Ultra	55%	It's called iPhone Duo	✗
Foldable starts at $2,000	85%	$1,999 for 256 GB	✓
Touch ID instead of Face ID on the foldable	75%	Touch ID in the side button	✓
No telephoto on the foldable	70%	Main 48 MP + ultra wide; 2x is a crop of the main sensor	✓
No base iPhone 18	90%	Moved to spring 2027	✓
A20 Pro on 2 nm in all three iPhones	90%	All three	✓
iPhone 18 Pro gets at least $100 pricier	70%	$1,199 / $1,299 — exactly +$100	✓
Variable aperture on the Pro main camera	65%	Yes, plus manual aperture and shutter	✓
Ceramic Apple Watch Series 12	70%	Ceramic finish in the lineup	✓
AirPods 5 with a new H3 chip	65%	H3, $129 / $149 — ANC on both models	✓
Home hub is shown (bet against)	35%	Not shown	✓
Something not in any leak (bet against)	30%	Front camera under the foldable's inner display	✗

Brier score: 0.118 (answering 50/50 on everything scores 0.25). I missed exactly where I warned I would: specs leak for months because thousands of factory workers know them, while the name is known by about twenty people who stay quiet. And I got cocky betting against a surprise.

What was announced

Device	US price	Pre-order	Available
iPhone 18 Pro	from $1,199	Sep 12	Sep 18
iPhone 18 Pro Max	from $1,299	Sep 12	Sep 18
iPhone Duo	from $1,999	Oct 16	Oct 23
Apple Watch Series 12	from $399	now	Sep 18
Apple Watch Ultra 4	from $799	now	Sep 18
AirPods 5	$129 / $149	now	Sep 18
iOS 27, macOS Golden Gate & co	free	—	Sep 14

The good: a foldable whose two displays share (almost) the same proportions, so content scales instead of reflowing; Split View on an iPhone for the first time; a real variable aperture; 45 hours of video on the Pro Max; ANC in the $129 AirPods; and Apple Reference Image, which signs sensor data so a photo can later be proven to be a photo — arguably the most underrated announcement of the night.

The not-so-good: +$100 on the Pro and +$300 on the 1 TB tier, price bumps on older models; Siri AI ships in beta, English-only, with daily usage limits and "expanded access for a fee in the future" (and not at all on iPhone in the EU or mainland China); the iPhone 18 Pro display is unchanged apart from a narrower Dynamic Island; the Duo is eSIM-only and doesn't support Apple Pencil Pro.

Not shown: the base iPhone 18, the home hub, HomePod mini, Apple TV, any Mac — and, for developers, the iOS 27.1 SDK.

The new screen in numbers

For 19 years the iPhone has been a tall, narrow strip: 1.5 on the original, 2.17 on today's Pro Max. Every mobile layout we write grew up inside that strip. The Duo's inner display breaks it.

	iPhone 18 Pro Max	Duo, outer	Duo, inner
Diagonal	6.9″	5.4″	7.6″
Pixels	1320 × 2868	1398 × 2034	2670 × 1878
Points (w × h)	440 × 956	466 × 678	890 × 626
Density	460 ppi	460 ppi	430 ppi
Aspect ratio	2.17	1.45	1.42
Size classes (portrait)	compact × regular	compact × regular	regular × regular
Supported orientations	honored	honored	ignored

Three takeaways:

1.42 is roughly √2 — the A4 paper ratio. Fold such a sheet in half and each half keeps the same shape. In Split View the inner display splits into two panes of roughly 445 × 626 points, each almost the shape of the outer display. Two apps side by side each get an "outer screen". That's hardware designed with software in mind.
The open Duo is wider than tall. It's not a phone turned sideways — it's the new default posture. The Dynamic Island sits vertically on the side, so safe-area insets are asymmetric, and with the 27.1 SDK vertical bars move to the left edge.
16:9 video loses. At 890 points wide a video is 890 × 501, leaving 125 points of black — a fifth of the screen.

How the Duo shows your app if you do nothing

Built without the iOS 27 SDK: a familiar phone-sized window in the middle of the inner display, surrounded by black. A postcard in a giant frame.
Built with the iOS 27 SDK: wider, but part of the screen is still empty.
Built with the iOS 27.1 SDK: edge to edge, toolbars and tab bars move to the left. This is the native look — and the SDK for it isn't even in beta yet.

What to grep for this week

The good news: almost all of this is stuff Apple has asked us to do for years. The bad news: iPhones were always narrow, and plenty of codebases quietly relied on it. The Duo is still an iPhone, but inside it's regular × regular, like an iPad.

In your code	Why it breaks on Duo	Replace with
`UIScreen.main.bounds`, hardcoded widths	Two differently shaped screens, the app moves between them live	Your view's geometry (`onGeometryChange`), screen via `UIWindowScene`
Interface orientation checks	The inner display ignores supported orientations	`horizontalSizeClass` / `verticalSizeClass`
`userInterfaceIdiom == .phone` as "narrow screen"	Duo is an iPhone with regular × regular and Split View	Layout by size class, not by device type
Symmetric safe-area insets	The Dynamic Island is on the side	Handle each inset and margin independently
`UIRequiresFullScreen` in Info.plist	No longer prevents resizing from iOS 27	Support live resizing
A hardcoded "Sign in with Face ID" label	Duo has Touch ID in the side button	Branch on `LAContext.biometryType`
One window per app	Split View opens multiple scenes, new windows only on the inner display	Support multiple scenes and handle refused requests

Biometrics is the easy one:

import LocalAuthentication

func biometryLabel() -> String {
    let context = LAContext()
    _ = context.canEvaluatePolicy(.deviceOwnerAuthentication, error: nil)
    return switch context.biometryType {
    case .faceID:  "Sign in with Face ID"
    case .touchID: "Sign in with Touch ID"
    case .opticID: "Sign in with Optic ID"
    default:       "Sign in with passcode"
    }
}

Layout isn't rocket science either if you're on SwiftUI — NavigationSplitView collapses to one column in compact width and expands on the inner display:

struct RootView: View {
    @Environment(\.horizontalSizeClass) private var hSize

    var body: some View {
        NavigationSplitView {
            SidebarList()
        } detail: {
            DetailView()
                .padding(hSize == .regular ? 32 : 16)
        }
    }
}

Apple's "Preparing your app for iPhone Duo" material also names foldable-specific APIs: onHingeChange / UIHingeInteraction for hinge states and angle, ArrangementView / UIArrangementViewController for two-pane layouts around the fold, reservedRegion on GeometryProxy / UIView to keep controls off the fold, CameraCaptureAccessory for a preview or teleprompter on the outer display, and AVCaptureDeviceDirectionCoordinator — because camera position is no longer camera direction.

Two easy-to-miss extras: StandBy on the Duo runs on either display even when not charging, so apps without widgets or Live Activities simply don't exist there. And health apps should expect a lot more data — Series 12 and Ultra 4 sample heart rate every five seconds all day.

The next six weeks

Sep 14 — iOS 27 ships. Its SDK (already in RC) decides whether your app resizes.
Sep 16–17 — Apple group labs on iPhone Duo; Q&As on Sep 23.
Xcode 27.1 beta — iOS 27.1 SDK and a Duo simulator you can open, close, rotate and partially fold.
Oct 23 — iPhone Duo ships on iOS 27.1, and people who paid $1,999 start opening your app.

Bottom line

If you own an iPhone 16 Pro or 17 Pro, you could have skipped this keynote. If you write iOS apps, this is the busiest autumn since 2017, when the iPhone X taught everyone the words "safe area". This time the lesson is that an iPhone can be wider than it is tall, that size classes on a phone aren't a formality, and that one window per app is no longer a given. The keynote was boring precisely because everything important in it was for Xcode, not for the store window.

How many UIScreen.main references are in your project?

Originally published at klukyanov.ru.

UIKit and SwiftUI Interoperability Patterns

rahul bandal — Sun, 13 Sep 2026 13:37:01 +0000

As iOS developers, we often find ourselves working on projects that started in the UIKit era but are now embracing SwiftUI for new features and UI components. Or perhaps you're building a new app in SwiftUI but need to leverage a complex, existing UIKit component or a third-party library that doesn't yet have a SwiftUI equivalent. In these scenarios, knowing how to seamlessly integrate UIKit and SwiftUI is not just a "nice-to-have" skill – it's essential.

This article will guide you through the core patterns for interoperability,…

Read the full article on Swift By Rahul → Continue reading

The complete tutorial includes Swift code examples, SVG diagrams, and step-by-step explanations on our website.