Coder Legion - Recent posts tagged swiftui

Tap-to-Match Marble Game in SpriteKit and SwiftUI: Physics, Cluster Matching, Lives and Power-Ups

Tue, 27 Oct 2026 12:39:50 +0000

Originally published at https://bestlatestapps.com/blog/building-a-tap-to-match-marble-game-with-spritekit-and-swiftui/

A complete walkthrough of the game loop: marbles that settle under real physics, finding touching same-colour clusters, a pause-safe countdown, lives and levels, Lightning, Heart and Bomb power-ups, and particle effects, all hosted in SwiftUI with SpriteView

Every game developer has a "small" game that taught them how games actually work. Mine is Marbles Popperz, a puzzle game where you tap marbles of the same colour to match them and score points before time runs out. It has a lives system, levels that get harder, three power-ups (Lightning Flash, Heart and Bomb) and global leaderboards.

On paper that's a weekend project. In practice it touches nearly every part of a real game: a physics world, hit-testing, a frame-driven clock that has to survive pausing, difficulty tuning, juicy feedback, and a SwiftUI interface laid over a SpriteKit scene.

This article walks through how I'd build each piece with SpriteKit, Apple's 2D game framework. The code is mine, written for this article, and the design choices are labelled as the approach I'd use. Game Center leaderboards get their own article, my Speck Match piece, so here I'll stay on gameplay.

1. Why SpriteKit, and how it fits with SwiftUI

For a 2D casual game on Apple platforms, SpriteKit is the shortest path. It gives you a scene graph (SKScene, SKSpriteNode), actions for animation (SKAction), a built-in physics engine (SKPhysicsBody) and particles (SKEmitterNode), all rendered on the GPU, with no third-party engine to update.

Since iOS 14, SpriteView lets a SwiftUI view host a scene directly. So menus, the HUD and settings can be ordinary SwiftUI, and only the playfield is SpriteKit:

import SwiftUI
import SpriteKit

struct GameScreen: View {
    @StateObject private var state = GameState()
    @State private var scene: MarbleScene = {
        let s = MarbleScene(size: CGSize(width: 390, height: 700))
        s.scaleMode = .resizeFill
        return s
    }()

    var body: some View {
        ZStack(alignment: .top) {
            SpriteView(scene: scene, preferredFramesPerSecond: 60)
                .ignoresSafeArea()
                .onAppear { scene.state = state }

            HUD(score: state.score, lives: state.lives,
                timeLeft: state.timeLeft, level: state.level)
                .padding()
        }
    }
}

@MainActor
final class GameState: ObservableObject {
    @Published var score = 0
    @Published var lives = 3
    @Published var level = 1
    @Published var timeLeft: TimeInterval = 60
    @Published var isGameOver = false
}

The rule I follow: the scene owns the simulation; SwiftUI owns the chrome. The scene writes to a shared GameState, and SwiftUI just renders it. Keep SwiftUI state changes to a few per second, not 60, or you'll pay for view updates every frame.

2. A playfield of marbles that settle under physics

Marbles should behave like marbles. When some pop, the ones above should roll down and fill the gap. Giving each marble a circular physics body, and the scene an edge loop, gets you that for free:

import SpriteKit

enum MarbleColor: CaseIterable { case red, blue, green, yellow, purple }

final class Marble: SKSpriteNode {
    let color: MarbleColor
    static let radius: CGFloat = 22

    init(color: MarbleColor) {
        self.color = color
        let texture = SKTexture(imageNamed: "marble-\(color)")    // from a texture atlas
        super.init(texture: texture, color: .clear,
                   size: CGSize(width: Self.radius * 2, height: Self.radius * 2))
        name = "marble"
        let body = SKPhysicsBody(circleOfRadius: Self.radius)
        body.restitution = 0.2          // a little bounce
        body.friction = 0.3
        body.allowsRotation = true
        physicsBody = body
    }
    required init?(coder: NSCoder) { fatalError() }
}

final class MarbleScene: SKScene {
    weak var state: GameState?
    var config = LevelConfig.forLevel(1)
    var remaining: TimeInterval = 60
    private var lastUpdate: TimeInterval = 0

    override func didMove(to view: SKView) {
        backgroundColor = .black
        physicsBody = SKPhysicsBody(edgeLoopFrom: frame)         // the walls of the jar
        physicsWorld.gravity = CGVector(dx: 0, dy: -9.8)
        view.ignoresSiblingOrder = true                          // lets SpriteKit batch draws
        fill(count: config.marbleCount)
    }

    func fill(count: Int) {
        let palette = Array(MarbleColor.allCases.prefix(config.colorCount))
        for i in 0..<count {
            let marble = Marble(color: palette.randomElement()!)
            marble.position = CGPoint(x: .random(in: 40...(size.width - 40)),
                                      y: size.height + CGFloat(i) * 8)   // drop in from above
            addChild(marble)
        }
    }
}

Two cheap wins: put every marble texture in one texture atlas, so all marbles are drawn in a few batched calls; and set ignoresSiblingOrder so SpriteKit is free to reorder draws for batching.

3. Tap-to-match: finding the touching cluster

The listing describes the core loop simply: "Tap marbles of the same color to match them… The more marbles you match, the higher your score." The approach I'd use is cluster matching. Tapping a marble pops it together with every same-colour marble it is touching, directly or through a chain. A lone marble doesn't pop. Bigger clusters score more, which rewards looking before you tap.

Hit-testing uses nodes(at:). The cluster is a breadth-first search over "touching" neighbours:

extension MarbleScene {
    override func touchesBegan(_ touches: Set<UITouch>, with event: UIEvent?) {
        guard let point = touches.first?.location(in: self),
              let tapped = nodes(at: point).compactMap({ $0 as? Marble }).first else { return }

        let cluster = cluster(from: tapped)
        guard cluster.count >= 2 else {
            tapped.run(.sequence([.moveBy(x: 6, y: 0, duration: 0.04),
                                  .moveBy(x: -12, y: 0, duration: 0.08),
                                  .moveBy(x: 6, y: 0, duration: 0.04)]))   // "no match" wiggle
            return
        }
        pop(cluster)
        state?.score += score(forClusterOf: cluster.count)
    }

    func cluster(from start: Marble) -> [Marble] {
        let all = children.compactMap { $0 as? Marble }.filter { $0.color == start.color }
        let touchDistance = Marble.radius * 2 + 4                  // small tolerance for resting contact
        var visited: Set<ObjectIdentifier> = [ObjectIdentifier(start)]
        var queue = [start], result: [Marble] = []

        while let current = queue.popLast() {
            result.append(current)
            for other in all where !visited.contains(ObjectIdentifier(other)) {
                if hypot(other.position.x - current.position.x,
                         other.position.y - current.position.y) <= touchDistance {
                    visited.insert(ObjectIdentifier(other))
                    queue.append(other)
                }
            }
        }
        return result
    }

    /// Quadratic reward: 2 marbles = 20, 5 marbles = 125, 10 marbles = 500.
    func score(forClusterOf n: Int) -> Int { n * n * 5 }
}

With a few dozen marbles on screen, this brute-force neighbour check is trivially fast. If you ever have hundreds, bucket marbles into a grid by position first. Distance-based neighbours work better than physics contact callbacks here, because resting marbles don't keep reporting contacts.

4. Popping with juice

A match should feel good: a quick scale-up, a fade, a particle burst and a sound. The physics then lets the marbles above fall into the gap.

extension MarbleScene {
    func pop(_ marbles: [Marble]) {
        for (i, marble) in marbles.enumerated() {
            marble.physicsBody = nil                              // stop it interacting while it pops
            let delay = SKAction.wait(forDuration: Double(i) * 0.03)   // a ripple through the cluster
            let burst = SKAction.run { [weak self] in self?.spawnBurst(at: marble.position) }
            let vanish = SKAction.group([.scale(to: 1.4, duration: 0.12), .fadeOut(withDuration: 0.12)])
            marble.run(.sequence([delay, burst, vanish, .removeFromParent()]))
        }
        run(.playSoundFileNamed("pop.caf", waitForCompletion: false))
    }

    func spawnBurst(at point: CGPoint) {
        guard let emitter = SKEmitterNode(fileNamed: "Pop.sks") else { return }   // designed in Xcode
        emitter.position = point
        emitter.numParticlesToEmit = 24
        addChild(emitter)
        emitter.run(.sequence([.wait(forDuration: 0.6), .removeFromParent()]))
    }
}

The 30 ms stagger is the cheapest "juice" there is. A cluster of eight pops as a ripple instead of all at once, and players read that as a chain reaction. Always remove finished emitters, or they pile up invisibly and eat frame time.

5. A countdown that survives pausing

"Watch the timer – you need to match quickly!" The timer must stop when the game is paused, when a phone call comes in and when the app goes to the background. A Timer or Date arithmetic gets this wrong. The robust pattern is to accumulate frame deltas in update(_:), and only while the game is actually running:

extension MarbleScene {
    override func update(_ currentTime: TimeInterval) {
        defer { lastUpdate = currentTime }
        guard lastUpdate > 0, !isPaused, let state, !state.isGameOver else { return }

        // Clamp so a long hitch (or resuming from pause) can't eat seconds at once.
        let dt = min(currentTime - lastUpdate, 1.0 / 20.0)
        remaining -= dt

        // Push to SwiftUI only when the displayed whole second changes.
        let shown = max(0, remaining.rounded(.up))
        if shown != state.timeLeft { state.timeLeft = shown }

        if remaining <= 0 { timeUp() }
        if children.compactMap({ $0 as? Marble }).isEmpty { levelCleared() }
    }
}

(remaining and lastUpdate are the stored properties declared on the scene in section 2.) Three details carry the weight:

Clamp dt. After a pause, currentTime jumps forward. Without the clamp, the first frame back would subtract all of the paused time.
Guard on isPaused. Pausing the SKView stops the frame loop entirely. Pausing just the scene stops its actions and physics, and the explicit guard makes sure the clock stops too, whichever you use.
Throttle UI updates. Writing to @Published state 60 times a second makes SwiftUI re-render the HUD 60 times a second. Write only when the displayed value changes.

Pausing itself is one line, scene.isPaused = true. Wire it to the scene phase going to .inactive or .background in SwiftUI.

6. Lives and levels

The listing has a "Lives system – be careful not to run out!" and "Level progression – difficulty increases as you advance". The approach I'd use: running out of time on a level costs a life and restarts that level, and clearing the jar advances you. Difficulty lives in one small table, so tuning never means touching game logic:

struct LevelConfig {
    let marbleCount: Int
    let colorCount: Int
    let seconds: TimeInterval
    let powerUpChance: Double

    static func forLevel(_ level: Int) -> LevelConfig {
        LevelConfig(
            marbleCount: min(30 + level * 4, 80),       // more marbles
            colorCount: min(3 + level / 3, 5),          // more colours = smaller clusters
            seconds: max(60 - Double(level) * 2, 30),   // less time
            powerUpChance: max(0.08 - Double(level) * 0.004, 0.03)
        )
    }
}

extension MarbleScene {
    func timeUp() {
        guard let state else { return }
        state.lives -= 1
        if state.lives <= 0 { state.isGameOver = true; isPaused = true }
        else { restartLevel() }
    }

    func restartLevel() {
        enumerateChildNodes(withName: "marble") { node, _ in node.removeFromParent() }
        remaining = config.seconds
        fill(count: config.marbleCount)
    }

    func levelCleared() {
        state?.level += 1
        config = .forLevel(state?.level ?? 1)
        remaining = config.seconds
        fill(count: config.marbleCount)
    }
}

Adding a colour is the most powerful difficulty knob in a colour-match game. Each extra colour shrinks the average cluster, which lowers scores and raises pressure without touching the clock.

7. Power-ups: Lightning, Heart and Bomb

The listing names three power-ups: "Lightning Flash – Clear multiple marbles at once", "Heart – Gain an extra life" and "Bomb – Explode surrounding marbles". I'd model them as special marbles that spawn occasionally and trigger when tapped:

enum PowerUp { case lightning, heart, bomb }

extension MarbleScene {
    func trigger(_ powerUp: PowerUp, at point: CGPoint) {
        let marbles = children.compactMap { $0 as? Marble }
        switch powerUp {
        case .lightning:
            // Clear every marble of the most common colour.
            let counts = Dictionary(grouping: marbles, by: \.color)
            if let biggest = counts.max(by: { $0.value.count < $1.value.count })?.value {
                pop(biggest); state?.score += score(forClusterOf: biggest.count)
            }
        case .heart:
            state?.lives += 1
        case .bomb:
            let blastRadius: CGFloat = 110
            let hit = marbles.filter { hypot($0.position.x - point.x, $0.position.y - point.y) < blastRadius }
            pop(hit); state?.score += hit.count * 10
            // Push the survivors outwards for a satisfying shove.
            for m in marbles where !hit.contains(m) {
                let d = CGVector(dx: m.position.x - point.x, dy: m.position.y - point.y)
                let len = max(hypot(d.dx, d.dy), 1)
                m.physicsBody?.applyImpulse(CGVector(dx: d.dx / len * 30, dy: d.dy / len * 30))
            }
        }
    }
}

Which marbles "Lightning" clears is my design choice; the listing only says it clears multiple at once. The bomb's impulse on survivors is where the physics world pays off a second time. The jar visibly reacts, and the new arrangement creates fresh clusters.

8. Real-world example: Marbles Popperz

This walkthrough is based on building Marbles Popperz. The code here is the approach I'd use, not the shipped source.

At the time of writing, its App Store listing shows:

Free, in Games (Puzzle, Board)
First released in December 2021
3 ratings in the US store, averaging about 3.7 stars
Supports iOS 16.0 and later

How the listing maps to this article:

What the listing says	Where it's covered
"Simple tap-to-match gameplay" / "Match marbles by color to remove them"	Hit-testing and cluster matching (section 3)
"Beautiful visual effects and animations"	Staggered pops and particle bursts (section 4)
"Watch the timer - you need to match quickly!"	Pause-safe countdown in `update(_:)` (section 5)
"Lives system" / "Level progression - difficulty increases as you advance"	Lives and a level table (section 6)
"Lightning Flash", "Heart", "Bomb"	Power-ups (section 7)
"Global leaderboards - compete with players worldwide"	Game Center, covered in my Speck Match article

The rating average is a useful honest signal for a small game: three ratings is too few to mean much. The way to learn what players struggle with is to watch someone play your first three levels without saying a word.

9. Before you ship a casual game: a checklist

The timer pauses on pause, on interruptions and in the background, and dt is clamped on resume.
The UI isn't updated every frame, only when displayed values change.
Textures are in an atlas and ignoresSiblingOrder is on. Check the draw count with showsDrawCount during development.
Finished emitters and actions are removed. No invisible nodes pile up.
The difficulty table is data, and each level has been played by someone other than you.
Taps feel fair. The hit area isn't smaller than the visible marble, and a mis-tap gets clear feedback.
Colour isn't the only cue. Add patterns or symbols to marbles for colour-blind players.
Sound respects the silent switch, and there's a mute option.
Test on the oldest supported device at 60 fps with the maximum marble count.

Wrapping up

A tap-to-match game is a perfect classroom. Physics gives you settling for free. A simple search gives you clusters. A clamped delta gives you an honest clock. A table gives you difficulty. And a few milliseconds of stagger turn "it works" into "it feels good". SpriteKit and SwiftUI together cover all of it with nothing to install.

Play the game, or explore my other work:

Marbles Popperz (iOS): https://apps.apple.com/us/app/marbles-popperz/id1601511276
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

What's your favourite bit of game "juice"? Share it in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/building-a-tap-to-match-marble-game-with-spritekit-and-swiftui/

Offline Quotes App in SwiftUI: 50K-Quote Library, Daily Quote, Streaks and Share-as-Image

Mon, 26 Oct 2026 12:42:11 +0000

Originally published at https://bestlatestapps.com/blog/building-an-offline-quotes-app-in-swiftui/

Bundling and importing a large library into SwiftData, picking a "quote of the day" deterministically, search with recent queries, collections, time-zone-safe streaks, rendering shareable quote cards with ImageRenderer, and Light/Dark/Auto themes

A quotes app looks like the simplest thing in the App Store: a list of text and a share button. Then you build one and the real questions show up. Where do 50,000 quotes live, and how do they get onto the phone without a slow first launch? How does every user get the same "quote of the day" without a server deciding it? What counts as a reading streak when someone flies from Delhi to San Francisco? And how do you turn a quote into an image that looks good on Instagram?

I've worked through those questions building Facts and Quotes, my app of curated quotes, motivational facts and wisdom. It has categories, offline access, search with recent searches, collections, reading streaks and achievements, sharing quotes as images or text, and Light, Dark and Auto themes.

This article walks through how I'd build each of those pieces in SwiftUI and SwiftData. Availability was checked against Apple's documentation. Where I describe an approach rather than the app's exact implementation, I say so.

1. Ship the library in the bundle, import it once

"Offline access, read anywhere" means the quotes ship with the app. A plain JSON file in the bundle is easy to produce, diff and validate. Decoding 50,000 small records is quick, but querying them is better done from a real store, so I'd import into SwiftData on first launch:

import SwiftData
import Foundation

@Model
final class Quote {
    @Attribute(.unique) var id: String
    var text: String
    var author: String
    var category: String
    var isFavorite: Bool = false
    var collections: [QuoteCollection] = []

    init(id: String, text: String, author: String, category: String) {
        self.id = id; self.text = text; self.author = author; self.category = category
    }
}

@Model
final class QuoteCollection {
    var name: String
    var createdAt: Date = Date.now
    @Relationship(inverse: \Quote.collections) var quotes: [Quote] = []
    init(name: String) { self.name = name }
}

struct QuoteRecord: Decodable { let id, text, author, category: String }

The import runs once, in the background, in batches, so memory stays flat and the UI never blocks:

@ModelActor
actor LibraryImporter {
    func importIfNeeded(bundleVersion: Int) throws {
        let key = "library.importedVersion"
        guard UserDefaults.standard.integer(forKey: key) < bundleVersion,
              let url = Bundle.main.url(forResource: "quotes", withExtension: "json") else { return }

        let records = try JSONDecoder().decode([QuoteRecord].self, from: Data(contentsOf: url))
        let existing = Set(try modelContext.fetch(FetchDescriptor<Quote>()).map(\.id))

        for (index, record) in records.enumerated() where !existing.contains(record.id) {
            modelContext.insert(Quote(id: record.id, text: record.text,
                                      author: record.author, category: record.category))
            if index % 2_000 == 0 { try modelContext.save() }   // batch saves
        }
        try modelContext.save()
        UserDefaults.standard.set(bundleVersion, forKey: key)
    }
}

Two design points:

A library version number. When an app update adds quotes, bump the version and the importer adds only the new IDs. Favourites and collections are untouched because existing rows are never rewritten.
Stable IDs. Give every quote a permanent ID in the source file. If you ever key on the text, fixing a typo would orphan a user's favourite.

For a "daily new quotes automatically updated" feature, the same importer can accept a small JSON file downloaded from your own server. The bundled library guarantees it still works offline on day one.

2. A quote of the day with no server

A "daily quote" should be the same all day, change at midnight and need no network. The trick is a deterministic pick from the local date:

import Foundation

enum DailyPick {
    /// Same answer for everyone on the same local calendar day.
    static func index(for date: Date = .now, count: Int, calendar: Calendar = .current) -> Int {
        guard count > 0 else { return 0 }
        let c = calendar.dateComponents([.year, .month, .day], from: date)
        let key = "\(c.year!)-\(c.month!)-\(c.day!)"
        return Int(stableHash(key) % UInt64(count))
    }

    /// FNV-1a: stable across launches and devices (unlike Swift's `hashValue`).
    static func stableHash(_ string: String) -> UInt64 {
        var hash: UInt64 = 0xcbf2_9ce4_8422_2325
        for byte in string.utf8 {
            hash ^= UInt64(byte)
            hash &*= 0x0000_0100_0000_01B3
        }
        return hash
    }
}

The gotcha worth a paragraph: don't use String.hashValue. Swift randomises hashing per process launch, so your "quote of the day" would change every time the app opened. Use a fixed algorithm like FNV-1a.

Then fetch by a sorted offset rather than loading everything:

func quoteOfTheDay(in context: ModelContext) throws -> Quote? {
    let total = try context.fetchCount(FetchDescriptor<Quote>())          // iOS 17+
    var descriptor = FetchDescriptor<Quote>(sortBy: [SortDescriptor(\.id)])
    descriptor.fetchOffset = DailyPick.index(count: total)
    descriptor.fetchLimit = 1
    return try context.fetch(descriptor).first
}

Sorting by the stable ID matters too. Without a sort order, "the 1,234th quote" isn't guaranteed to be the same row tomorrow.

3. Search across content, author and category, with recent searches

SwiftUI's searchable (iOS 16+) and SwiftData's #Predicate (iOS 17+) do most of the work. localizedStandardContains gives the case- and diacritic-insensitive matching people expect from a search box:

import SwiftUI
import SwiftData

struct SearchView: View {
    @State private var text = ""
    @AppStorage("recentSearches") private var recentData = Data()

    var body: some View {
        NavigationStack {
            QuoteResults(query: text)
                .navigationTitle("Search")
                .searchable(text: $text, prompt: "Quotes, authors, categories")
                .searchSuggestions {
                    if text.isEmpty {
                        ForEach(recent, id: \.self) { term in
                            Text(term).searchCompletion(term)
                        }
                    }
                }
                .onSubmit(of: .search) { remember(text) }
        }
    }

    private var recent: [String] { (try? JSONDecoder().decode([String].self, from: recentData)) ?? [] }

    private func remember(_ term: String) {
        let trimmed = term.trimmingCharacters(in: .whitespaces)
        guard !trimmed.isEmpty else { return }
        let updated = ([trimmed] + recent.filter { $0.caseInsensitiveCompare(trimmed) != .orderedSame }).prefix(8)
        recentData = (try? JSONEncoder().encode(Array(updated))) ?? Data()
    }
}

struct QuoteResults: View {
    @Query private var quotes: [Quote]

    init(query: String) {
        let q = query
        _quotes = Query(filter: #Predicate<Quote> {
            q.isEmpty ||
            $0.text.localizedStandardContains(q) ||
            $0.author.localizedStandardContains(q) ||
            $0.category.localizedStandardContains(q)
        }, sort: \Quote.author)
    }

    var body: some View {
        List(quotes) { quote in
            VStack(alignment: .leading, spacing: 4) {
                Text("“\(quote.text)”")
                Text("— \(quote.author)").font(.caption).foregroundStyle(.secondary)
            }
        }
    }
}

Rebuilding the Query in the child view's initialiser is the standard way to drive a dynamic predicate from parent state. Recent searches are small and per-device, so @AppStorage is the right home for them.

4. Collections and favourites

With the many-to-many relationship from section 1, collections are a few lines. Favourites are just a flag. The listing says the Favorites collection "automatically syncs your liked quotes", so I'd treat it as a virtual collection, a query, rather than a stored one that can drift out of sync:

struct FavoritesView: View {
    @Query(filter: #Predicate<Quote> { $0.isFavorite }, sort: \Quote.author)
    private var favorites: [Quote]

    var body: some View {
        List(favorites) { Text($0.text) }
            .overlay { if favorites.isEmpty { ContentUnavailableView("No favourites yet", systemImage: "heart") } }
    }
}

func add(_ quote: Quote, to collection: QuoteCollection) {
    guard !collection.quotes.contains(where: { $0.id == quote.id }) else { return }
    collection.quotes.append(quote)
}

Deleting a collection shouldn't delete its quotes. The default delete rule for a relationship, nullify, does exactly that.

5. Streaks that survive time zones

A streak is "the number of consecutive days, ending today, on which you read". The bugs come from storing timestamps and doing arithmetic in seconds. Then 23:50 and 00:10 count as the same day, or a flight makes a day disappear.

The fix is to store calendar days as the user experienced them, as plain date strings, and count backwards:

import Foundation

struct StreakTracker {
    private(set) var days: Set<String>          // "2026-10-22", in the user's local calendar at the time
    var calendar = Calendar.current

    private func key(_ date: Date) -> String {
        let c = calendar.dateComponents([.year, .month, .day], from: date)
        return String(format: "%04d-%02d-%02d", c.year!, c.month!, c.day!)
    }

    mutating func recordRead(at date: Date = .now) { days.insert(key(date)) }

    func currentStreak(asOf now: Date = .now) -> Int {
        var day = calendar.startOfDay(for: now)
        // Not read yet today? The streak can still be alive from yesterday.
        if !days.contains(key(day)) {
            day = calendar.date(byAdding: .day, value: -1, to: day)!
        }
        var count = 0
        while days.contains(key(day)) {
            count += 1
            day = calendar.date(byAdding: .day, value: -1, to: day)!
        }
        return count
    }
}

Why this is honest:

Each day is recorded in the local calendar at the moment it happens. Reading at 23:55 in Delhi is "the 22nd", whatever happens afterwards.
Today doesn't break the streak until it's over. Opening the app at 8 a.m. shouldn't show zero because you haven't read yet.
Calendar arithmetic, not 86,400-second arithmetic. date(byAdding: .day…) handles daylight-saving days of 23 or 25 hours.

Achievements, like "7-day streak" or "read 100 quotes", are then pure functions of this data. Compute them; don't store them separately.

"Share quotes as beautiful images or text" is two lines of SwiftUI once you have the pieces: ImageRenderer (iOS 16+) to rasterise a SwiftUI view, and ShareLink with a Transferable item (iOS 16+):

import SwiftUI

struct QuoteCard: View {
    let quote: Quote
    var body: some View {
        VStack(alignment: .leading, spacing: 20) {
            Text("“\(quote.text)”").font(.system(size: 44, weight: .semibold, design: .serif))
            Text("— \(quote.author)").font(.title2).foregroundStyle(.white.opacity(0.8))
        }
        .foregroundStyle(.white)
        .padding(80)
        .frame(width: 1080, height: 1350)                        // a 4:5 portrait post
        .background(LinearGradient(colors: [.indigo, .purple], startPoint: .topLeading, endPoint: .bottomTrailing))
    }
}

struct ShareableQuote: Transferable {
    let quote: Quote
    static var transferRepresentation: some TransferRepresentation {
        DataRepresentation(exportedContentType: .png) { item in
            await MainActor.run {
                let renderer = ImageRenderer(content: QuoteCard(quote: item.quote))
                renderer.scale = 1                                // the view is already 1080 px wide
                return renderer.uiImage?.pngData() ?? Data()
            }
        }
        ProxyRepresentation { "“\($0.quote.text)” — \($0.quote.author)" }   // text fallback
    }
}

struct ShareButton: View {
    let quote: Quote
    var body: some View {
        ShareLink(item: ShareableQuote(quote: quote),
                  preview: SharePreview("Quote by \(quote.author)")) {
            Label("Share", systemImage: "square.and.arrow.up")
        }
    }
}

Details that matter:

Design the card at output pixel size and render with scale = 1. Sizes stay predictable, and text is sharp at the size social apps actually use.
Offer text too. The ProxyRepresentation gives the share sheet a plain-text version, so Messages or Notes receive words, not a picture of words.
Rendering happens on the main actor. ImageRenderer is main-actor bound, hence the MainActor.run.

7. Light, Dark and Auto, with colour tokens

"Light, Dark, and Auto" is a three-way setting where Auto means "follow the system". In SwiftUI, preferredColorScheme(nil) is exactly that:

enum ThemeSetting: String, CaseIterable { case auto, light, dark
    var scheme: ColorScheme? { switch self { case .auto: nil; case .light: .light; case .dark: .dark } }
}

@main
struct QuotesApp: App {
    @AppStorage("theme") private var theme = ThemeSetting.auto
    var body: some Scene {
        WindowGroup {
            RootView().preferredColorScheme(theme.scheme)
        }
        .modelContainer(for: [Quote.self, QuoteCollection.self])
    }
}

The listing mentions a design system with 50+ colour tokens. The approach I'd use is to define each token once in the asset catalog with light and dark variants, and refer to it by meaning (Color("surfaceElevated"), Color("textSecondary")) rather than by hue. Then a theme change is free, and no screen hard-codes .black.

8. Real-world example: Facts and Quotes

All of this comes from building Facts and Quotes. The code above is the approach I'd use, written for this article, not a copy of the app's source.

At the time of writing, its App Store listing shows:

Free, in Health & Fitness and Productivity
First released in August 2022
3 ratings in the US store, all 5 stars
Supports iOS 17.6 and later

How the listing maps to this article:

What the listing says	Where it's covered
"50,000+ curated quotes", "Offline access - read anywhere, anytime"	Bundled library imported into SwiftData (section 1)
"Daily new quotes automatically updated"	Versioned importer plus a deterministic daily pick (sections 1–2)
"Search quotes by content, author, or category" / "Recent searches"	`searchable` + `#Predicate` + `searchSuggestions` (section 3)
"Create custom collections…" / "Favorites collection automatically syncs your liked quotes"	SwiftData relationships and a query-based Favorites (section 4)
"Track your reading streak and daily progress" / "Unlock achievements"	Calendar-day streaks (section 5)
"Share quotes as beautiful images or text"	`ImageRenderer` + `Transferable` + `ShareLink` (section 6)
"Light, Dark, and Auto theme support" / "50+ color tokens"	`preferredColorScheme` and semantic colours (section 7)

The listing also mentions AI-powered recommendations and haptic feedback. Those are topics for their own articles. I've written about haptics separately, in my Haptics Explorer piece.

9. Before you ship a content app: a checklist

The first launch is fast. The import runs in the background, in batches, and the UI shows today's quote immediately.
Every item has a stable ID. Updates never break favourites or collections.
The daily pick uses a stable hash. No hashValue, and the fetch has a fixed sort order.
Search is case- and accent-insensitive, and recent searches are capped.
Streaks are tested across midnight, daylight saving and a time-zone change.
Shared images are rendered at their target pixel size, with a text fallback.
Auto theme follows the system; no colour is hard-coded.
Attribution is correct. Every quote has an author, or "Unknown". Misattributed quotes are the most common complaint in this category.
Accessibility. Quote text scales with Dynamic Type, and VoiceOver reads the author after the quote.

Wrapping up

The app is simple to use because the hard parts are hidden. Ship content offline and import it once. Make "daily" deterministic. Store days, not seconds. Render share images at their real size. None of it needs a server, which is also why the app works on a plane.

Try the app, or explore my other work:

Facts and Quotes (iOS): https://apps.apple.com/us/app/facts-and-quotes/id1607878544
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

Got a favourite quote? Drop it in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/building-an-offline-quotes-app-in-swiftui/

Offline eBook Reader for iOS: Downloads, Typography, Reading Progress and Highlights

Mon, 26 Oct 2026 12:41:45 +0000

Originally published at https://bestlatestapps.com/blog/building-an-offline-ebook-reader-for-ios/

Downloading and storing public-domain books, previewing before you download, a UITextView-based reader with font, line height, margin and theme settings, saving your place as a character offset instead of a page number, bookmarks and highlights (including iOS 26's multi-range selection), reading time estimates and reading statistics

There's something special about reading a classic on your phone at night, when the book is more than a century old and the screen is the newest thing in the room. Novels Club is my app for that: thousands of public-domain classics, literature, poetry and philosophy, with recommendations, offline downloads, customisable reading settings, progress tracking, bookmarks, highlights and reading statistics.

A reading app sounds like "show text in a scroll view". It isn't, and the interesting problems are subtle. Where does a downloaded book live, and should it go into the user's iCloud backup? How do you let someone preview a book without downloading all of it? And the one that catches everybody: how do you remember someone's place when they change the font size and every "page" moves?

This article walks through how I'd build each part. The APIs are checked against Apple's documentation, including two iOS 27 deprecations in UITextView that matter for highlighting.

1. The library model

A book has metadata you can browse before downloading, and an optional local file once it's downloaded. In SwiftData:

import SwiftData
import Foundation

@Model
final class Book {
    @Attribute(.unique) var id: String
    var title: String
    var author: String
    var categories: [String]
    var wordCount: Int?
    var remoteURL: URL
    var localFileName: String?          // set once downloaded
    var progressOffset: Int = 0         // UTF-16 offset of the first visible character
    var lastOpened: Date?
    @Relationship(deleteRule: .cascade) var marks: [Mark] = []

    init(id: String, title: String, author: String, categories: [String], remoteURL: URL) {
        self.id = id; self.title = title; self.author = author
        self.categories = categories; self.remoteURL = remoteURL
    }

    var isDownloaded: Bool { localFileName != nil }

    /// "About 6 h 40 min" for a 100,000-word novel at 250 words per minute.
    var readingTimeEstimate: Duration? {
        wordCount.map { .seconds(Double($0) / 250 * 60) }
    }
}

@Model
final class Mark {
    enum Kind: String, Codable { case bookmark, highlight }
    var kind: Kind
    var location: Int                   // UTF-16 offset
    var length: Int                     // 0 for bookmarks
    var note: String?
    var created: Date = Date.now
    init(kind: Kind, location: Int, length: Int) { self.kind = kind; self.location = location; self.length = length }
}

Two decisions shape everything later. Positions are character offsets, not page numbers (section 5). And marks cascade-delete with their book, so removing a book never leaves orphaned highlights behind.

The reading-time estimate uses 250 words per minute, a common rule of thumb for adult silent reading. It's an estimate, and the UI should say "about".

2. Downloading books, and keeping them out of iCloud backup

"Download books for offline reading" with URLSession's async API (iOS 15+) is short. The details that matter are where the file goes and whether it's backed up:

import Foundation

enum BookStore {
    static var directory: URL {
        let dir = URL.applicationSupportDirectory.appending(path: "Books", directoryHint: .isDirectory)
        try? FileManager.default.createDirectory(at: dir, withIntermediateDirectories: true)
        return dir
    }

    /// Downloads a book, moves it into place and excludes it from iCloud backup.
    static func download(_ book: Book) async throws {
        let (tempURL, response) = try await URLSession.shared.download(from: book.remoteURL)
        guard (response as? HTTPURLResponse)?.statusCode == 200 else { throw URLError(.badServerResponse) }

        var destination = directory.appending(path: "\(book.id).txt")
        try? FileManager.default.removeItem(at: destination)
        try FileManager.default.moveItem(at: tempURL, to: destination)   // the temp file is deleted on return

        var values = URLResourceValues()
        values.isExcludedFromBackup = true        // re-downloadable content doesn't belong in backups
        try destination.setResourceValues(values)

        book.localFileName = destination.lastPathComponent
    }
}

Application Support, not Caches. The system can purge Caches under storage pressure, and a book vanishing mid-read on a plane is exactly what "offline reading" promises won't happen.
isExcludedFromBackup. The books can be downloaded again, so they shouldn't eat the user's iCloud quota. Apple's storage guidance asks for exactly this.
Move the temp file immediately. The async download(from:) gives you a temporary file that's deleted once you're done with it, so move it before doing anything else.

For a progress bar, pass a URLSessionTaskDelegate to download(from:delegate:), or use a URLSessionDownloadTask with a URLSessionDownloadDelegate (iOS 7+) and observe the task's progress.

3. Preview before downloading

"Preview books before downloading" doesn't need a separate preview file. If the server supports range requests, ask for just the first few kilobytes:

extension BookStore {
    static func preview(_ book: Book, bytes: Int = 16_384) async throws -> String {
        var request = URLRequest(url: book.remoteURL)
        request.setValue("bytes=0-\(bytes - 1)", forHTTPHeaderField: "Range")
        let (data, response) = try await URLSession.shared.data(for: request)

        // 206 = Partial Content. A 200 means the server ignored Range and sent everything,
        // so keep only the opening part either way.
        guard let http = response as? HTTPURLResponse, [200, 206].contains(http.statusCode) else {
            throw URLError(.badServerResponse)
        }
        let slice = data.prefix(bytes)
        // A byte cut can split a multi-byte character; trim back to valid UTF-8.
        for trim in 0..<4 {
            if let text = String(data: slice.dropLast(trim), encoding: .utf8) { return text }
        }
        return ""
    }
}

That last loop is easy to forget. A byte range can end in the middle of a multi-byte UTF-8 character, such as an accented letter in a French novel, and then String(data:encoding:) returns nil for the whole preview.

4. A reader with real typography settings

The listing promises "font size, font family, line height, margins" and "light, dark, and custom color schemes". UITextView (read-only) gives you excellent text layout, selection and accessibility for free. Since iOS 16 it can be created explicitly with TextKit 2 via init(usingTextLayoutManager:):

import SwiftUI
import UIKit

struct ReaderSettings: Equatable {
    var fontName = "Georgia"
    var fontSize: CGFloat = 19
    var lineHeight: CGFloat = 1.45       // multiple of the font's natural line height
    var margin: CGFloat = 24
    var theme = ReaderTheme.sepia
}

struct ReaderTheme: Equatable {
    var background: UIColor, text: UIColor
    static let light = ReaderTheme(background: .white, text: .black)
    static let sepia = ReaderTheme(background: UIColor(red: 0.98, green: 0.95, blue: 0.88, alpha: 1),
                                   text: UIColor(red: 0.26, green: 0.20, blue: 0.14, alpha: 1))
    static let dark  = ReaderTheme(background: UIColor(white: 0.08, alpha: 1), text: UIColor(white: 0.85, alpha: 1))
}

struct ReaderView: UIViewRepresentable {
    let text: String
    let settings: ReaderSettings
    @Binding var offset: Int             // reading position, see section 5

    func makeUIView(context: Context) -> UITextView {
        let view = UITextView(usingTextLayoutManager: true)   // TextKit 2 (iOS 16+)
        view.isEditable = false
        view.isSelectable = true                              // needed for highlights
        view.delegate = context.coordinator
        return view
    }

    func updateUIView(_ view: UITextView, context: Context) {
        guard context.coordinator.applied != settings else { return }
        context.coordinator.applied = settings

        let font = UIFont(name: settings.fontName, size: settings.fontSize)
            ?? .systemFont(ofSize: settings.fontSize)
        let paragraph = NSMutableParagraphStyle()
        paragraph.lineHeightMultiple = settings.lineHeight
        paragraph.paragraphSpacing = settings.fontSize * 0.6

        view.attributedText = NSAttributedString(string: text, attributes: [
            .font: UIFontMetrics(forTextStyle: .body).scaledFont(for: font),   // respects Dynamic Type
            .foregroundColor: settings.theme.text,
            .paragraphStyle: paragraph
        ])
        view.backgroundColor = settings.theme.background
        view.textContainerInset = UIEdgeInsets(top: 32, left: settings.margin, bottom: 48, right: settings.margin)

        context.coordinator.restore(offset, in: view)          // keep the reader's place after re-layout
    }

    func makeCoordinator() -> Coordinator { Coordinator(offset: $offset) }
}

The applied != settings guard matters. Rebuilding the attributed string for a 150,000-word novel is expensive, so do it only when a setting actually changes, not on every SwiftUI update. For very long books, the approach I'd use is to split by chapter and load one chapter at a time.

5. Reading progress that survives font changes

Here's the trap. If you save "page 143", or a scroll offset of 18,400 points, then the moment someone bumps the font from 17 to 21 point, page 143 is a different passage. The fix is to save the character the reader is looking at, a UTF-16 offset into the text, which no layout change can move:

final class Coordinator: NSObject, UITextViewDelegate {
    var offset: Binding<Int>
    var applied: ReaderSettings?
    var onHighlight: (([NSRange]) -> Void)?      // set by the reader screen to save Marks
    init(offset: Binding<Int>) { self.offset = offset }

    /// The first character at the top-left of the visible area.
    func currentOffset(in view: UITextView) -> Int {
        let topLeft = CGPoint(x: view.textContainerInset.left + 1,
                              y: view.contentOffset.y + view.textContainerInset.top + 1)
        guard let position = view.closestPosition(to: topLeft) else { return 0 }
        return view.offset(from: view.beginningOfDocument, to: position)    // UTF-16 units
    }

    func scrollViewDidEndDecelerating(_ scrollView: UIScrollView) { save(scrollView) }
    func scrollViewDidEndDragging(_ scrollView: UIScrollView, willDecelerate: Bool) {
        if !willDecelerate { save(scrollView) }
    }
    private func save(_ scrollView: UIScrollView) {
        guard let view = scrollView as? UITextView else { return }
        offset.wrappedValue = currentOffset(in: view)
    }

    /// After re-layout, bring that character back to the top.
    func restore(_ offset: Int, in view: UITextView) {
        DispatchQueue.main.async {                                  // after layout has happened
            guard let start = view.position(from: view.beginningOfDocument, offset: offset),
                  let end = view.position(from: start, offset: 1),
                  let range = view.textRange(from: start, to: end) else { return }
            let rect = view.firstRect(for: range)
            view.setContentOffset(CGPoint(x: 0, y: max(0, rect.minY - view.textContainerInset.top)), animated: false)
        }
    }
}

closestPosition(to:) and offset(from:to:) come from UITextInput (iOS 3.2+), which UITextView adopts. They do exactly what we need: convert between points on screen and positions in the text. With this:

Changing the font, line height or margins keeps the same sentence at the top of the screen.
"Continue reading where you left off" is just opening the book and restoring progressOffset.
Percentage progress is offset / text.utf16.count, which is meaningful whatever the layout.

Save on scroll end, not on every scroll event. Writing to SwiftData 60 times a second while flicking through a chapter is wasted work.

6. Bookmarks and highlights, and the iOS 26 text-selection change

Since positions are character offsets, a highlight is just (location, length) and a bookmark is (location, 0). Both are stable because a public-domain text never changes. Rendering highlights is an attribute pass:

func applyHighlights(_ marks: [Mark], to storage: NSMutableAttributedString, color: UIColor) {
    for mark in marks where mark.kind == .highlight {
        let range = NSRange(location: mark.location, length: mark.length)
        guard NSMaxRange(range) <= storage.length else { continue }
        storage.addAttribute(.backgroundColor, value: color.withAlphaComponent(0.35), range: range)
    }
}

To create highlights, add an item to the text view's edit menu. This is where the APIs are changing:

iOS 16 introduced textView(_:editMenuForTextIn:suggestedActions:), which gives you a single NSRange. Apple's documentation now marks it deprecated in iOS 27.
iOS 26 added textView(_:editMenuForTextInRanges:suggestedActions:), which gives you an array of ranges. Apple's documentation explains that a selection can be several discontiguous ranges, for example when bidirectional text is selected. Correspondingly, UITextView.selectedRange is marked deprecated in iOS 27, alongside the newer selectedRanges.

Since the app supports iOS 16.6 and later, I'd implement both and funnel them into one function:

extension Coordinator {
    private func highlightAction(for ranges: [NSRange]) -> UIAction {
        UIAction(title: "Highlight", image: UIImage(systemName: "highlighter")) { [weak self] _ in
            self?.onHighlight?(ranges.filter { $0.length > 0 })
        }
    }

    // iOS 26+: one or more selected ranges.
    @available(iOS 26, *)
    func textView(_ textView: UITextView, editMenuForTextInRanges ranges: [NSValue],
                  suggestedActions: [UIMenuElement]) -> UIMenu? {
        UIMenu(children: [highlightAction(for: ranges.map(\.rangeValue))] + suggestedActions)
    }

    // iOS 16–25: a single range (deprecated in iOS 27).
    func textView(_ textView: UITextView, editMenuForTextIn range: NSRange,
                  suggestedActions: [UIMenuElement]) -> UIMenu? {
        UIMenu(children: [highlightAction(for: [range])] + suggestedActions)
    }
}

The iOS 26 method's [NSValue] parameter type is taken from Apple's published declaration. Each value wraps an NSRange.

7. Reading statistics without surveillance

"Track your reading statistics: books read, pages read, reading time" and "reading streaks". The honest way to measure reading time is to count only while the reader is on screen and the app is active:

struct ReadingClock {
    private var startedAt: Date?
    private(set) var total: TimeInterval = 0

    mutating func resume() { if startedAt == nil { startedAt = .now } }
    mutating func pause() {
        if let start = startedAt { total += min(Date.now.timeIntervalSince(start), 30 * 60) }  // cap idle sessions
        startedAt = nil
    }
}
// In the reader: resume() on appear and when scenePhase becomes .active;
// pause() on disappear and when it leaves .active.

The 30-minute cap per session stops a phone left open on the nightstand from claiming you read for eight hours. "Pages read" can be derived from the change in character offset divided by a nominal page size (say 1,800 characters), which gives consistent numbers whatever font you use. Streaks follow the calendar-day approach I described in my Facts and Quotes article.

8. Real-world example: Novels Club

Everything here comes from building Novels Club. The code is the approach I'd use, written for this article, not the shipped source.

At the time of writing, its App Store listing shows:

Free, in Magazines & Newspapers and Entertainment
First released in December 2025
No ratings yet in the US store
Supports iOS 16.6 and later

How the listing maps to this article:

What the listing says	Where it's covered
"All books are in the public domain, so you can read them completely"	Why offsets and highlights can be stable (sections 1 and 6)
"Download books for offline reading" / "All your downloaded books are stored locally"	Downloads in Application Support, excluded from backup (section 2)
"Preview books before downloading"	Range-request previews (section 3)
"Customizable reading settings: font size, font family, line height, margins" / "light, dark, and custom color schemes"	The TextKit 2 reader (section 4)
"Reading progress tracking" / "Continue reading where you left off"	Character-offset progress (section 5)
"Bookmarks and highlights for your favorite passages"	Marks and the edit menu (section 6)
"See book ratings, reading time estimates, and difficulty levels"	Reading-time estimates (section 1)
"Track your reading statistics…" / "View reading streaks"	Honest reading time (section 7)

With no ratings yet, the app is at the stage where every piece of feedback shapes it. If you read classics on your phone, I'd love to hear what your current reader gets wrong.

9. Before you ship a reading app: a checklist

Books live in Application Support, excluded from iCloud backup.
Previews handle partial UTF-8 and servers that ignore Range.
Re-layout happens only when settings change; long books load by chapter.
Progress is stored as a character offset and restored after every settings change.
Progress is saved on scroll end, not continuously.
Highlights are offset ranges, with both edit-menu delegate methods (iOS 16 and iOS 26+).
Dynamic Type works, and the custom font size is a multiplier on top of it.
Reading time only counts while the reader is active, with an idle cap.
Themes are tested in a dark room. Pure white on black is harsh; slightly grey text reads better.
Copyright is respected. Check the public-domain status of every title for the regions you distribute in, because it varies by country.

Wrapping up

A good reader disappears. You open the book, you're exactly where you left off, the text looks the way you like, and nothing reminds you it's an app. Getting there means a few unglamorous decisions: store characters instead of pages, keep books out of backups, re-lay out only when you must, and adopt the new multi-range text APIs while keeping the old ones for older systems.

Try the app, or explore my other work:

Novels Club (iOS): https://apps.apple.com/us/app/novels-club/id6755921578
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

Which classic should everyone read at least once? Tell me in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/building-an-offline-ebook-reader-for-ios/

Drag-to-Connect and Game Center Leaderboards in a SwiftUI Puzzle Game, Updated for iOS 26

Sun, 25 Oct 2026 12:40:22 +0000

Originally published at https://bestlatestapps.com/blog/drag-to-connect-and-game-center-leaderboards-in-a-swiftui-puzzle-game/

A dot-matching board drawn with Canvas and TimelineView, drag gestures that chain same-colour dots, speed-based scoring and rising difficulty, pause and resume, and modern Game Center: authentication, submitting scores, the access point, and what iOS 26 deprecates

Speck Match is a puzzle game about speed. You tap and drag to connect matching coloured dots and clear them from the board, and the faster you match, the higher your score. New dots appear faster as you play, until the board is crowded and you're racing to keep up. Then you see where you rank on Game Center leaderboards against players worldwide.

I wrote about tap-based gameplay in SpriteKit in my Marbles Popperz article. Speck Match lets me cover two different things. The first is a drag-to-connect mechanic built entirely in SwiftUI, with Canvas and TimelineView instead of a game engine. The second is Game Center leaderboards in depth, which have changed more in the last few iOS releases than most developers realise. The latest change: Apple's documentation now marks GKGameCenterViewController as deprecated in iOS 26.

As always, the code is written for this article and checked against Apple's documentation. Gameplay rules beyond what the App Store listing says are labelled as the approach I'd use.

1. The board as plain data

Keep the game state free of SwiftUI, so you can unit-test it:

import Foundation
import CoreGraphics

enum SpeckColor: CaseIterable { case coral, mint, sky, lemon, violet }

struct Speck: Identifiable, Equatable {
    let id = UUID()
    var color: SpeckColor
    var position: CGPoint
    let bornAt: TimeInterval            // game time when it appeared, used for speed scoring
    static let radius: CGFloat = 18
}

struct Board {
    var specks: [Speck] = []
    var score = 0
    var elapsed: TimeInterval = 0       // game time only; doesn't advance while paused
    var nextSpawn: TimeInterval = 0
    var difficulty: Difficulty

    /// Seconds between new specks: starts relaxed, tightens as you play.
    var spawnInterval: TimeInterval {
        max(difficulty.minInterval, difficulty.startInterval - elapsed * difficulty.ramp)
    }

    var isOverfull: Bool { specks.count >= difficulty.maxSpecks }
}

struct Difficulty {
    let startInterval: TimeInterval, minInterval: TimeInterval, ramp: Double
    let maxSpecks: Int, colors: Int
    static let easy   = Difficulty(startInterval: 1.4, minInterval: 0.55, ramp: 0.004, maxSpecks: 40, colors: 3)
    static let normal = Difficulty(startInterval: 1.1, minInterval: 0.40, ramp: 0.006, maxSpecks: 36, colors: 4)
    static let hard   = Difficulty(startInterval: 0.9, minInterval: 0.28, ramp: 0.008, maxSpecks: 32, colors: 5)
}

"The game gets faster and more challenging as you progress" becomes one computed property, spawnInterval, and "Multiple difficulty levels" becomes three rows of numbers. The values are illustrative; tune them by playing.

2. Drawing and ticking with Canvas and TimelineView

For a few dozen circles, SwiftUI's Canvas (iOS 15+) is fast and simple. It's immediate-mode drawing, so you're not creating one view per dot. TimelineView(.animation(minimumInterval:paused:)) (iOS 15+) gives you a frame clock that can be paused, which matters later:

import SwiftUI

struct BoardView: View {
    @State private var game = GameModel(difficulty: .normal)
    @Environment(\.scenePhase) private var scenePhase

    var body: some View {
        TimelineView(.animation(minimumInterval: 1.0 / 60, paused: game.isPaused)) { timeline in
            Canvas { context, size in
                for speck in game.board.specks {
                    let rect = CGRect(x: speck.position.x - Speck.radius, y: speck.position.y - Speck.radius,
                                      width: Speck.radius * 2, height: Speck.radius * 2)
                    context.fill(Path(ellipseIn: rect), with: .color(speck.color.swiftUIColor))
                }
                if game.chain.count > 1 {                       // the line you're drawing
                    var path = Path()
                    path.addLines(game.chain.compactMap { id in game.board.specks.first { $0.id == id }?.position })
                    context.stroke(path, with: .color(.white.opacity(0.8)), lineWidth: 6)
                }
            }
            .onChange(of: timeline.date) { _, now in game.tick(now: now) }
        }
        .gesture(dragGesture)
        .onChange(of: scenePhase) { _, phase in if phase != .active { game.pause() } }
    }
}

This code uses iOS 17 conveniences (@Observable and the two-parameter onChange). For the app's iOS 15.6 minimum, the same model works as an ObservableObject with the single-parameter onChange(of:perform:). Two more notes. Keep tick cheap: spawn when due, check the overfull condition, and nothing else. And auto-pause when the scene leaves .active. A phone call shouldn't cost a player their best run, and the listing promises "Pause and resume anytime".

3. Drag to connect

The listing's core loop is "Tap and drag dots to match them by color. Connect matching colored dots to clear them from the board." The approach I'd use: touching down on a dot starts a chain. Dragging over another dot of the same colour, close enough to the last one in the chain, adds it. Lifting your finger clears the chain if it has at least two dots.

@Observable
final class GameModel {
    var board: Board
    var chain: [UUID] = []
    var isPaused = false
    private var lastTick: Date?

    init(difficulty: Difficulty) { board = Board(difficulty: difficulty) }

    func speck(at point: CGPoint) -> Speck? {
        board.specks.first { hypot($0.position.x - point.x, $0.position.y - point.y) <= Speck.radius * 1.4 }
    }

    func dragChanged(to point: CGPoint) {
        guard !isPaused, let hit = speck(at: point) else { return }
        if chain.isEmpty { chain = [hit.id]; return }
        guard let first = board.specks.first(where: { $0.id == chain[0] }),
              hit.color == first.color, !chain.contains(hit.id) else {
            // Dragging back onto the previous dot undoes the last link, like most connect games.
            if chain.count >= 2, hit.id == chain[chain.count - 2] { chain.removeLast() }
            return
        }
        chain.append(hit.id)
    }

    func pause() { isPaused = true; lastTick = nil }
    func resume() { isPaused = false }

    func tick(now: Date) {
        defer { lastTick = now }
        guard !isPaused, let last = lastTick else { return }
        board.elapsed += min(now.timeIntervalSince(last), 0.05)     // clamp hitches and resumes
        if board.elapsed >= board.nextSpawn {
            spawn()
            board.nextSpawn = board.elapsed + board.spawnInterval
        }
        if board.isOverfull { pause() /* game over: submit score, show results */ }
    }

    private func spawn() {
        let palette = Array(SpeckColor.allCases.prefix(board.difficulty.colors))
        board.specks.append(Speck(color: palette.randomElement()!,
                                  position: CGPoint(x: .random(in: 30...360), y: .random(in: 120...700)),
                                  bornAt: board.elapsed))
    }

    func dragEnded() {
        defer { chain = [] }
        guard chain.count >= 2 else { return }
        let cleared = board.specks.filter { chain.contains($0.id) }
        board.specks.removeAll { chain.contains($0.id) }
        board.score += Scoring.points(for: cleared, now: board.elapsed)
    }
}

extension BoardView {
    var dragGesture: some Gesture {
        DragGesture(minimumDistance: 0)                 // 0 so a touch-down starts the chain immediately
            .onChanged { game.dragChanged(to: $0.location) }
            .onEnded { _ in game.dragEnded() }
    }
}

DragGesture(minimumDistance: 0) is the important detail. The default minimum distance means the first few points of a drag are swallowed, which feels laggy in a speed game. Make the hit radius a bit larger than the drawn dot (1.4× here). Fingers are bigger than dots, and fair hit areas are most of what "Smooth, responsive controls" means in practice.

4. Scoring speed

"Speed matters – faster matches = higher scores." There are many ways to express that. The approach I'd use rewards how fresh the dots were when you cleared them, plus a bonus for longer chains:

enum Scoring {
    /// Each dot: 10 points, plus up to 10 more if cleared within 3 seconds of appearing.
    /// Chains: +25% per dot beyond two.
    static func points(for specks: [Speck], now: TimeInterval) -> Int {
        let perDot = specks.map { speck -> Double in
            let age = now - speck.bornAt
            let freshness = max(0, 1 - age / 3)           // 1.0 when brand new, 0 after 3 s
            return 10 + 10 * freshness
        }
        let chainBonus = 1 + 0.25 * Double(max(0, specks.count - 2))
        return Int((perDot.reduce(0, +) * chainBonus).rounded())
    }
}

The bornAt timestamp uses game time (board.elapsed), not wall-clock time. Otherwise pausing would make every dot on screen "old", and the player would be punished for taking a break.

5. Signing in to Game Center

Leaderboards start with authentication. On iOS, you set GKLocalPlayer.local.authenticateHandler once, early. GameKit calls it, possibly more than once, with either a view controller to present or the result:

import GameKit
import UIKit

@MainActor
final class GameCenter: ObservableObject {
    @Published private(set) var isAuthenticated = false

    func authenticate() {
        GKLocalPlayer.local.authenticateHandler = { [weak self] viewController, error in
            if let viewController {
                // GameKit needs to show its sign-in UI.
                UIApplication.shared.connectedScenes
                    .compactMap { ($0 as? UIWindowScene)?.keyWindow?.rootViewController }
                    .first?.present(viewController, animated: true)
                return
            }
            self?.isAuthenticated = GKLocalPlayer.local.isAuthenticated
            if self?.isAuthenticated == true {
                GKAccessPoint.shared.location = .topLeading
                GKAccessPoint.shared.isActive = false        // show it on menus, not during play
            }
            if let error { print("Game Center unavailable: \(error.localizedDescription)") }
        }
    }
}

Rules I follow:

Never block the game on Game Center. If the player declines or is offline, the game plays normally and leaderboards just aren't offered.
Present the sign-in view controller from a real, visible controller. Presenting from a controller that isn't in the window is a classic "Game Center never shows" bug.
Show the access point only on menus. GKAccessPoint (iOS 14+) is a small Game Center badge that the system draws. Set isActive = false during play so it doesn't overlap the board.

6. Submitting scores the modern way

The old GKScore class is deprecated since iOS 14. The current API is a single class method on GKLeaderboard:

extension GameCenter {
    static let leaderboardID = "speck.highscores.normal"   // as configured in App Store Connect

    func submit(score: Int, difficulty: String) {
        guard GKLocalPlayer.local.isAuthenticated else { return }
        GKLeaderboard.submitScore(score, context: 0, player: GKLocalPlayer.local,
                                  leaderboardIDs: ["speck.highscores.\(difficulty)"]) { error in
            if let error { print("Score submit failed: \(error.localizedDescription)") }
        }
    }
}

Design choices:

One leaderboard per difficulty. An easy-mode score and a hard-mode score aren't comparable, and mixing them makes the board meaningless. Each needs its own ID in App Store Connect.
Submit at game over, not per match. One call per run is plenty. Game Center keeps each player's best score according to the leaderboard's settings.
Configure the sort order and format in App Store Connect (high to low, integer). The client just sends numbers.

7. Showing leaderboards in iOS 18 and 26

This is where things have moved. For years the answer was "present a GKGameCenterViewController". Apple's documentation now marks GKGameCenterViewController deprecated in iOS 26. Meanwhile, GKAccessPoint gained trigger(leaderboardID:playerScope:timeScope:handler:) in iOS 18, which opens the system Game Center UI straight to one leaderboard.

Since Speck Match supports iOS 15.6 and later, the approach I'd use branches:

import GameKit
import SwiftUI

extension GameCenter {
    func showLeaderboard(id: String, from presenter: UIViewController) {
        if #available(iOS 18, *) {
            GKAccessPoint.shared.trigger(leaderboardID: id, playerScope: .global, timeScope: .allTime) { }
        } else {
            // iOS 14–17: the dashboard view controller (deprecated in iOS 26, fine on older systems).
            let vc = GKGameCenterViewController(leaderboardID: id, playerScope: .global, timeScope: .allTime)
            vc.gameCenterDelegate = presenter as? GKGameCenterControllerDelegate
            presenter.present(vc, animated: true)
        }
    }

    /// In-game "Top 10" without leaving the app (iOS 14+).
    func topTen(id: String) async throws -> [(rank: Int, name: String, score: String)] {
        let boards = try await GKLeaderboard.loadLeaderboards(IDs: [id])
        guard let board = boards.first else { return [] }
        let (_, entries, _) = try await board.loadEntries(for: .global, timeScope: .allTime,
                                                         range: NSRange(location: 1, length: 10))
        return entries.map { ($0.rank, $0.player.displayName, $0.formattedScore) }
    }
}

loadEntries(for:timeScope:range:) returns the local player's entry, the requested range and the total count. Use formattedScore rather than formatting the raw value yourself, so the display matches what Game Center shows everywhere else.

The app's most recent release notes include "Fixed Game Center leaderboard display issue". That's a reminder that the leaderboard display path is the fragile part. Test it on every iOS version you support, and especially on both sides of the iOS 18 branch.

8. Real-world example: Speck Match

This walkthrough is grounded in building Speck Match. The code is the approach I'd use, written for this article, not the shipped source.

At the time of writing, its App Store listing shows:

Free to play ("with optional ads that can be removed"), in Games (Board, Strategy)
First released in December 2021
1 rating in the US store, 5 stars
Supports iOS 15.6 and later

How the listing maps to this article:

What the listing says	Where it's covered
"Tap and drag to connect matching dots"	`DragGesture` chains (section 3)
"Game gets faster and more challenging as you progress" / "Multiple difficulty levels"	`spawnInterval` and difficulty presets (section 1)
"Speed matters - faster matches = higher scores"	Freshness-based scoring (section 4)
"Pause and resume anytime"	A pausable `TimelineView` and game time (sections 2 and 4)
"Game Center integration" / "Global leaderboards"	Authentication, submitting and display (sections 5–7)
Release notes: "Fixed Game Center leaderboard display issue"	Version-branching the display path (section 7)

9. Before you ship a Game Center game: a checklist

The game plays fully without Game Center. Declined sign-in and offline are both tested.
authenticateHandler is set once, early, and presents from a visible view controller.
There's no GKScore. Use GKLeaderboard.submitScore, once per run.
There's one leaderboard per difficulty, with IDs matching App Store Connect exactly.
The display path is branched. GKAccessPoint.trigger(leaderboardID:…) on iOS 18+, the view controller on older systems, and both tested.
The access point is hidden during play.
Scores use game time. Pausing never changes the outcome.
Hit areas are generous, and minimumDistance: 0 is set for instant drags.
Colour isn't the only cue. Consider shapes for colour-blind players.

Wrapping up

A drag-to-connect game shows how far plain SwiftUI goes. Canvas draws the board, TimelineView ticks it, DragGesture drives it, and nothing needs a game engine. Game Center is the part that keeps evolving. Use the iOS 14 GKLeaderboard APIs, adopt the iOS 18 access-point trigger, and plan for the iOS 26 deprecation of the old dashboard controller.

Play the game, or explore my other work:

Speck Match (iOS): https://apps.apple.com/us/app/speck-match/id1600688336
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

Think you can top the leaderboard? Let me know your score in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/drag-to-connect-and-game-center-leaderboards-in-a-swiftui-puzzle-game/

Tic Tac Toe in SwiftUI, Done Properly: Game State, Win Detection and Minimax AI

Fri, 23 Oct 2026 12:02:18 +0000

Originally published at https://bestlatestapps.com/blog/tic-tac-toe-in-swiftui-done-properly/

The smallest game worth architecting: an immutable board, testable rules, a view that just renders state, and the classic AI you can bolt on in 40 lines

Tic tac toe is the "hello world" of game development, which is exactly why it's worth doing properly. It's small enough to hold in your head, but it still has every piece a real game needs: state, rules, turns, an end condition, a UI that reflects state, and, if you want it, an opponent that thinks.

One of my earliest App Store apps is Tic Tac Toe : Time Pass, published in April 2020. Its listing is as short as the game: "Put away your pencil and paper", with one-player and two-player modes, so you can play against another person or against yourself.

This article uses tic tac toe to show an architecture I'd use for any turn-based game: a value-type model that owns all the rules, a SwiftUI view that only renders state and forwards taps, unit tests for the rules, and a minimax opponent as an optional extension. To be clear: the listing doesn't say the app has a computer opponent. The minimax section is the approach I'd add, not a description of the app. API names are checked against Apple's documentation.

1. Why architecture matters even here

The quick version of tic tac toe puts nine @State strings in a view and checks for a winner inside the button action. It works for an afternoon. Then you want an undo button, a computer player, a "new game" animation, a stats screen and tests, and every one of those features has to reach into the view.

Instead, split it like this:

Game (struct)      ← all rules: whose turn, legal moves, winner, draw
   ▲     │
   │     ▼
GameViewModel      ← owns a Game, applies moves, triggers AI, publishes state
   ▲     │
   │     ▼
GameView (SwiftUI) ← renders state, sends taps; no rules at all

The model is a plain struct with no UIKit, SwiftUI or timers, which means you can test it, copy it (undo is free), and hand a copy to an AI to explore future moves without touching the real game.

2. The model: a board that can't be wrong

enum Player: String, CaseIterable {
    case x = "X", o = "O"
    var opponent: Player { self == .x ? .o : .x }
}

enum Outcome: Equatable {
    case inProgress
    case win(Player, line: [Int])
    case draw
}

struct Game: Equatable {
    private(set) var cells: [Player?] = Array(repeating: nil, count: 9)
    private(set) var current: Player = .x
    private(set) var moves: [Int] = []          // history, for undo and replays

    static let lines: [[Int]] = [
        [0, 1, 2], [3, 4, 5], [6, 7, 8],         // rows
        [0, 3, 6], [1, 4, 7], [2, 5, 8],         // columns
        [0, 4, 8], [2, 4, 6]                     // diagonals
    ]

    var outcome: Outcome {
        for line in Self.lines {
            if let p = cells[line[0]], cells[line[1]] == p, cells[line[2]] == p {
                return .win(p, line: line)
            }
        }
        return cells.allSatisfy { $0 != nil } ? .draw : .inProgress
    }

    var legalMoves: [Int] {
        guard outcome == .inProgress else { return [] }
        return cells.indices.filter { cells[$0] == nil }
    }

    /// Returns a new game with the move applied, or nil if the move is illegal.
    func playing(_ index: Int) -> Game? {
        guard legalMoves.contains(index) else { return nil }
        var next = self
        next.cells[index] = current
        next.moves.append(index)
        next.current = current.opponent
        return next
    }

    func undoing() -> Game {
        guard let last = moves.last else { return self }
        var previous = self
        previous.cells[last] = nil
        previous.moves.removeLast()
        previous.current = current.opponent
        return previous
    }
}

A few deliberate choices:

private(set) everywhere. Nothing outside the model can put an X in an occupied square or skip a turn. The only way to change the game is playing(_:), and it validates.
playing(_:) returns a new value instead of mutating. That makes the AI trivial, because it explores copies, and it makes "what if?" previews free.
Eight hard-coded lines beat a clever loop. For a 3×3 board, a literal table is the most readable rules engine possible. (For an N×N variant, you'd generate the lines instead.)

3. Testing the rules

Because the model is pure, the tests read like the rules of the game:

import XCTest

final class GameTests: XCTestCase {

    private func play(_ moves: [Int]) -> Game {
        moves.reduce(Game()) { game, move in
            guard let next = game.playing(move) else {
                XCTFail("Illegal move \(move)"); return game
            }
            return next
        }
    }

    func testRowWin() {
        // X: 0, 1, 2   O: 3, 4
        XCTAssertEqual(play([0, 3, 1, 4, 2]).outcome, .win(.x, line: [0, 1, 2]))
    }

    func testDiagonalWinForO() {
        // X: 0, 1, 5   O: 2, 4, 6
        XCTAssertEqual(play([0, 2, 1, 4, 5, 6]).outcome, .win(.o, line: [2, 4, 6]))
    }

    func testDraw() {
        // X O X / X O O / O X X
        XCTAssertEqual(play([0, 1, 2, 4, 3, 5, 7, 6, 8]).outcome, .draw)
    }

    func testCannotPlayOccupiedSquareOrAfterWin() {
        let game = play([0, 3, 1, 4, 2])          // X has won
        XCTAssertNil(Game().playing(0)?.playing(0))
        XCTAssertNil(game.playing(8))
    }

    func testUndoRestoresTurn() {
        let game = play([4]).undoing()
        XCTAssertEqual(game, Game())
    }
}

These run in milliseconds, with no simulator UI. When you later add an AI or a new mode, they're your safety net.

4. The view: render state, forward taps

The view model holds the game and the mode. The view is a grid:

import SwiftUI

@MainActor
final class GameViewModel: ObservableObject {
    enum Mode { case twoPlayer, onePlayer(computer: Player) }

    @Published private(set) var game = Game()
    @Published var mode: Mode = .twoPlayer
    @Published private(set) var isThinking = false

    func tap(_ index: Int) {
        if case .onePlayer(let computer) = mode, game.current == computer { return }
        guard let next = game.playing(index) else { return }
        game = next
        computerMoveIfNeeded()
    }

    func undo() { game = game.undoing() }
    func reset() { game = Game(); computerMoveIfNeeded() }

    private func computerMoveIfNeeded() {
        guard case .onePlayer(let computer) = mode,
              game.current == computer, game.outcome == .inProgress else { return }
        isThinking = true
        let snapshot = game
        Task {
            try? await Task.sleep(for: .milliseconds(350))   // feels less robotic
            let move = Minimax.bestMove(in: snapshot)
            if let move, let next = game.playing(move) { game = next }
            isThinking = false
        }
    }
}

struct GameView: View {
    @StateObject private var model = GameViewModel()
    private let columns = Array(repeating: GridItem(.flexible(), spacing: 8), count: 3)

    var body: some View {
        VStack(spacing: 20) {
            Text(status).font(.title2.bold())

            LazyVGrid(columns: columns, spacing: 8) {
                ForEach(0..<9, id: \.self) { index in
                    let mark = model.game.cells[index]
                    Button { model.tap(index) } label: {
                        Text(mark?.rawValue ?? " ")
                            .font(.system(size: 56, weight: .heavy, design: .rounded))
                            .frame(maxWidth: .infinity, minHeight: 96)
                            .background(background(for: index),
                                        in: RoundedRectangle(cornerRadius: 12))
                    }
                    .buttonStyle(.plain)
                    .disabled(mark != nil || model.game.outcome != .inProgress)
                    .accessibilityLabel(label(for: index, mark: mark))
                }
            }
            .padding(.horizontal)

            HStack {
                Button("Undo", action: model.undo).disabled(model.game.moves.isEmpty)
                Spacer()
                Button("New Game", action: model.reset)
            }
            .padding(.horizontal)
        }
        .animation(.easeOut(duration: 0.2), value: model.game)
        .sensoryFeedback(.selection, trigger: model.game.moves.count)   // iOS 17+
    }

    private var status: String {
        switch model.game.outcome {
        case .inProgress: return model.isThinking ? "Thinking…" : "\(model.game.current.rawValue) to play"
        case .win(let p, _): return "\(p.rawValue) wins!"
        case .draw: return "It's a draw"
        }
    }

    private func background(for index: Int) -> Color {
        if case .win(_, let line) = model.game.outcome, line.contains(index) {
            return .green.opacity(0.3)
        }
        return Color(.secondarySystemBackground)
    }

    private func label(for index: Int, mark: Player?) -> String {
        let row = index / 3 + 1, column = index % 3 + 1
        return "Row \(row), column \(column), \(mark.map { $0.rawValue } ?? "empty")"
    }
}

Notice what the view doesn't do: it never decides who won or whether a move is legal. Even the disabled state just reads the model.

Version notes, since the app supports iOS 12: LazyVGrid is iOS 14+, .sensoryFeedback is iOS 17+, and Task.sleep(for:) is iOS 16+. On an older target, use nested HStacks, UIImpactFeedbackGenerator and Task.sleep(nanoseconds:), or build the same view model behind a UIKit grid. SwiftUI itself starts at iOS 13, so a genuinely iOS 12-compatible app is UIKit. The architecture doesn't change; only the view layer does.

5. Adding a computer opponent: minimax

Tic tac toe is small enough to search completely. Minimax explores every possible continuation and assumes both players play perfectly: the computer picks the move with the best guaranteed outcome, and assumes you'll pick the one that's worst for it.

enum Minimax {
    /// Best move for `game.current`, or nil if the game is over.
    static func bestMove(in game: Game) -> Int? {
        let me = game.current
        var best: (move: Int, score: Int)?
        for move in game.legalMoves {
            guard let next = game.playing(move) else { continue }
            let score = minimax(next, maximizing: false, me: me, depth: 1,
                                alpha: Int.min, beta: Int.max)
            if best == nil || score > best!.score { best = (move, score) }
        }
        return best?.move
    }

    private static func minimax(_ game: Game, maximizing: Bool, me: Player,
                                depth: Int, alpha: Int, beta: Int) -> Int {
        switch game.outcome {
        case .win(let p, _): return p == me ? 10 - depth : depth - 10   // win sooner, lose later
        case .draw: return 0
        case .inProgress: break
        }
        var alpha = alpha, beta = beta
        var best = maximizing ? Int.min : Int.max
        for move in game.legalMoves {
            guard let next = game.playing(move) else { continue }
            let score = minimax(next, maximizing: !maximizing, me: me,
                                depth: depth + 1, alpha: alpha, beta: beta)
            if maximizing {
                best = max(best, score); alpha = max(alpha, best)
            } else {
                best = min(best, score); beta = min(beta, best)
            }
            if beta <= alpha { break }      // alpha-beta pruning: this branch can't matter
        }
        return best
    }
}

Two details make this feel right:

Depth in the score. 10 - depth makes the AI prefer winning now over winning later, and losing later over losing now. Without it, a perfect AI sometimes "plays with its food" and looks broken.
Alpha-beta pruning skips branches that can't change the result. The full game tree is only a few hundred thousand positions, so the AI is instant either way, but pruning is a habit worth building for bigger games.

Making it beatable

A perfect tic tac toe opponent never loses, which makes it boring quickly. A simple difficulty dial:

extension Minimax {
    /// skill 0.0 = random, 1.0 = perfect
    static func move(in game: Game, skill: Double) -> Int? {
        if Double.random(in: 0..<1) > skill { return game.legalMoves.randomElement() }
        return bestMove(in: game)
    }
}

"Easy" around 0.3, "medium" around 0.7 and "hard" at 1.0 gives three genuinely different games from one function.

6. Real-world example: Tic Tac Toe : Time Pass

The patterns above are how I'd structure Tic Tac Toe : Time Pass today, or any small turn-based game.

At the time of writing, its App Store listing shows:

Free, in Games (Strategy, Casual) and Entertainment
First released in April 2020
13 ratings in the US store, averaging about 3.9 stars
Supports iOS 12.0 and later

The listing says: "Tic Tac Toe supports one player and two player gameplay, so you can play against another human or against yourself."

What the listing says	Where it's covered
"Put away your pencil and paper"	A value-type `Game` model that enforces the rules (section 2)
"Two player gameplay… against another human"	`.twoPlayer` mode: one device, alternating turns (section 4)
"One player… against yourself"	`.onePlayer` mode; minimax is the extension I'd add for a computer opponent (section 5)
iOS 12.0 and later	UIKit is required below iOS 13; the model is identical either way (section 4)

A 3.9 average on a game this simple tells me something too. Casual players expect polish even from "time pass" games: clear win highlighting, a satisfying tap, an easy rematch. The architecture above is what makes that polish cheap to add.

7. Before you ship a small game: a checklist

Rules live in one pure model, with no UI framework imports.
Illegal states are impossible: private(set) state, and validated moves that return new values.
Every rule has a test: each kind of win, a draw, illegal moves, moves after a win, and undo.
The view only renders and forwards. If a view contains if winner… logic, move it.
The AI works on copies and never on the live game. It's tested too: it should never lose from any position where a draw is possible.
Difficulty is a dial, not three AIs.
Accessibility: every cell has a spoken label with row, column and contents, and the result is announced.
Rematch is one tap. The fastest way to a better rating in a casual game.

Wrapping up

Tic tac toe is small, but the lessons scale. Put the rules in a value type that can't be put into an illegal state, test it like a spec, keep the view dumb, and treat the AI as just another consumer of the model, one that explores copies. The same shape works for chess, card games and anything else turn-based.

Play it, or explore my other apps:

Tic Tac Toe : Time Pass (iOS): https://apps.apple.com/us/app/tic-tac-toe-time-pass/id1509555889
All of my free iOS apps: https://apps.apple.com/us/developer/alok-singh/id1508795536
My portfolio: https://bestlatestapps.com/alok/

What's your favourite "tiny game, big lesson" project? Tell me in the comments.

— Alok Kumar Singh

Originally published at https://bestlatestapps.com/blog/tic-tac-toe-in-swiftui-done-properly/

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Sun, 09 Aug 2026 04:53:28 +0000

A desktop SSH client can keep the remote connection alive and still give the user the impression that the terminal was reset. The failure often sits one layer above SSH: the UI destroys and rebuilds the terminal surface when the user switches to another section.

That distinction matters when a macOS app embeds xterm.js in WKWebView. The SSH process, terminal model, WebKit process, DOM, scrollback, focus chain, and visible geometry all have different lifetimes. Treating them as one SwiftUI view makes normal navigation surprisingly destructive.

This article describes the design rules we ended up using in a native macOS SSH client.

Why rebuilding is not a harmless refresh

A straightforward SwiftUI implementation conditionally creates the selected section:

if selectedSection == .terminal {
    TerminalSurface()
} else {
    FilesView()
}

When the condition changes, SwiftUI is free to dismantle the terminal subtree. If that subtree owns a WKWebView, the app can lose much more than a view object:

the WebContent process and xterm.js DOM may be destroyed;
scrollback stored only in the browser process disappears;
alternate-screen applications such as vim, nano, or top cannot be reconstructed from plain text;
restoring a bounded output snapshot may omit older history;
WebKit initialization and snapshot replay add visible latency;
focus and resize events can arrive in a different order after reconstruction.

Keeping the SSH handle alive does not solve any of these UI-state losses. The remote PTY may still be healthy while the local terminal surface has forgotten how to represent it.

Separate four lifetimes

The useful mental model is to separate at least four things:

Logical session: the tab, server identity, name, working directory, and user-facing state.
Transport session: the SSH handle and remote PTY that carry input and output.
Terminal renderer: the WKWebView, xterm.js DOM, parser state, and scrollback.
Visible attachment: whether that renderer currently participates in the AppKit view hierarchy and responder chain.

Navigation should normally change only the fourth lifetime. Closing a tab can end all four. A network failure may replace the transport while retaining the logical tab and renderer. Conflating those transitions is where most of the surprising behavior begins.

Mount once, then deactivate

After the terminal section is opened for the first time, keep its SwiftUI subtree mounted. Other sections can still be created normally, while the terminal surface changes visibility and interaction state:

if terminalHasLoaded || selectedSection == .terminal {
    TerminalSurface(isActive: selectedSection == .terminal)
        .opacity(selectedSection == .terminal ? 1 : 0)
        .allowsHitTesting(selectedSection == .terminal)
}

This preserves the representable and its coordinator instead of asking SwiftUI to rebuild them on every sidebar click. The isActive value also gives terminal-specific shortcuts, toolbars, and event monitors an explicit lifecycle. Hidden terminal controls should not continue handling keyboard shortcuts while the user is working in Files or Settings.

Opacity alone, however, is not sufficient for a WebKit-backed terminal.

Preserve the WKWebView object, not necessarily its attachment

On macOS, an embedded WKWebView participates in AppKit focus, drag registration, and window behavior. Keeping it attached but transparent can leave side effects in sections that should have nothing to do with the terminal.

A more reliable arrangement is:

let NSViewRepresentable return a lightweight container;
let its coordinator hold a strong reference to the WKWebView;
attach the web view to the container only while the terminal section is active;
remove it from the hierarchy while inactive, without releasing the object;
attach the same object again when the user returns.

The WebKit object, WebContent process, xterm.js DOM, parser state, and scrollback stay alive even while the view is temporarily detached. The rest of the app no longer has an invisible WebKit view interfering with hit testing or drag sessions.

This is different from serializing terminal text and creating a new renderer. It preserves the renderer itself.

Hand focus back before detaching

Focus is a correctness issue for terminals, not just polish. If the window's first responder remains inside the web view during a section switch, later keystrokes can be delivered somewhere the user cannot see. In the worst case, a stray character is interpreted by the remote shell.

Before detaching an active terminal web view:

Check whether the window's first responder is the web view or one of its descendants.
Explicitly clear or move the first responder.
Remove the web view from its container.
Disable terminal-only keyboard monitors and shortcut controls.

When reattaching, restore focus deliberately after the container is visible. Avoid assuming that SwiftUI's appearance callback and AppKit's responder-chain update happen in the same frame.

Freeze hidden geometry

A hidden but mounted view can still receive geometry changes. If its width follows every animation in the visible section, xterm.js may repeatedly run fit(), and each result may resize the remote PTY.

That creates a subtle class of bugs: opening a file-transfer panel or animating another page changes the dimensions of a terminal the user is not looking at. Full-screen terminal programs then redraw against "ghost" sizes.

Record the terminal's last active width and freeze the inactive container at that width. On reattachment:

align the web view to the visible container once;
let the renderer's resize observer compute the new rows and columns;
send one meaningful PTY resize instead of a frame-by-frame storm.

The same rule applies to side panels: reserve their width only in the section that owns them, not at a shared ancestor that also sizes the hidden terminal.

Keep output flowing without flooding the UI

Detaching the renderer should not pause the SSH transport. Output can continue updating the logical session and renderer while the user visits another section.

High-volume PTY output needs its own boundary. Read callbacks can arrive hundreds of times per second, while sending every chunk through the main thread and WebKit IPC creates unnecessary contention. A practical policy is:

deliver sparse output immediately so typing echo feels instant;
merge continuous bursts into roughly one flush per display frame;
update the bounded recovery buffer before notifying the renderer;
keep session logs on a separate path from visual replay.

The recovery buffer remains useful if WebKit really crashes, but it is no longer the normal navigation mechanism.

Test transitions, not just steady states

The most valuable tests are sequences:

start top, switch to Files, resize the window, and return;
scroll far back, visit Settings, and confirm the same scrollback remains;
focus the terminal, switch sections, type immediately, and verify nothing reaches SSH;
open and close a side panel while the terminal is hidden;
disconnect while hidden, then return and exercise the reconnect path;
close a terminal tab while its web view is detached and confirm observers and script handlers are removed.

These tests cross SwiftUI, AppKit, WebKit, and SSH boundaries. A unit test around one layer will not reveal the ordering failures between them.

The broader rule

View visibility and resource lifetime are not the same thing. A terminal is a long-lived interactive resource with a UI surface, not a disposable page. Once the logical session, transport, renderer, and visible attachment have separate ownership, navigation becomes predictable: switching sections changes what the user sees without quietly rebuilding the tool they were using.

Developer disclosure: I work on Nexus Shell, a native macOS SSH workspace. This article is based on implementation and debugging lessons from that work, not a benchmark against other clients.

Editorial note: This draft was prepared with AI assistance and reviewed against the current SwiftUI, AppKit, WebKit, and SSH implementation before publication.

Eunify: Bridging the Continuity Gap Between Mac and Android

Fri, 22 May 2026 17:24:01 +0000

If you’ve ever lived deep within the Apple ecosystem, you know the magic of Continuity. The ability to copy a link on your iPhone and instantly paste it on your Mac, or use your phone’s camera as a wireless webcam, feels like living in the future. Apple built these features seamlessly into their OS, giving their users a cohesive multi-device experience.

But what if you love your Mac, but prefer an Android phone? Out of the box, you get nothing. The wall around Apple's garden is tall, and cross-platform continuity has historically been clunky, relying on a patchwork of third-party apps that drain battery and feel decidedly un-magical.

Eunify (https://github.com/FredrickOdondi/eunify) changes that.

What is Eunify?
Eunify is an open-source "Continuity Bridge" designed specifically for users who split their digital lives between macOS and Android. It consists of a native macOS host app (built with Swift and SwiftUI) and an Android client (built with Flutter), tied together by a clever cloud relay system.

The goal? To give Android users the exact same seamless, real-time continuity features that were previously exclusive to the Apple ecosystem.

Bringing Apple Magic to Android
Eunify doesn't just mimic one or two features; it aims to replicate the entire Continuity suite:

Universal Clipboard: Copy text or a block of code on your Mac, and it instantly lands in your Android clipboard.
Tab & URL Push: Drag a Chrome or Safari tab onto the Eunify Mac app, and it opens instantly on your phone. You can also send links in reverse, from your Android back to your Mac browser.
Notification Mirroring: See your Android push notifications appear on your Mac in real-time, complete with actionable quick replies.
File Transfer: Drag any file onto the Mac app to send it directly to your Android device via high-speed P2P WebRTC.
Continuity Camera: Stream your Android phone's camera feed directly to your Mac to use as a wireless webcam.
Biometric Mac Unlock: Tap your fingerprint on your Android phone to unlock your Mac remotely.
Media Sync: See what's playing on your Android and control it right from your Mac desktop.
How It Works Under the Hood
Achieving this level of synergy across fundamentally different operating systems requires a robust technical foundation.

The Handshake: It starts with a simple QR code. The macOS app generates a QR code encoding a unique room ID. Scanning this with the Android app connects both devices to the same Supabase Realtime (WebSocket) channel.
Signaling: Standard events—like URL pushes, clipboard syncs, and notification mirroring—are securely transmitted as structured JSON payloads over the Supabase cloud relay.
Peer-to-Peer Streaming: For heavy lifting (binary data like files and live camera frames), the WebSocket channel is used to negotiate a direct WebRTC DataChannel. This ensures fast, secure, peer-to-peer data streaming without routing massive payloads through a cloud server.
Conquering Android Background Restrictions
One of the biggest hurdles for an app like this is keeping the connection alive while the mobile app is in the background. Modern Android is notoriously aggressive about killing background processes to save battery.

Eunify solves this with a two-layer approach:

A Foreground Service keeps the Supabase WebSocket connection alive with a WakeLock.
A separate Background Isolate written in Dart re-initializes the connection independently, handling message delivery even if the main UI is completely killed by the OS.
(It even employs clever workarounds, like using FlutterForegroundTask to briefly trampoline the app to the foreground on Android 10+ just to bypass background clipboard-writing restrictions.)

Get Started
If you're tired of emailing yourself links and want to bring your Android device into your Mac's ecosystem, Eunify is open source and ready to try.

Check out the code, read the full protocol design, and download the latest releases directly from the GitHub repository:

Explore Eunify on GitHub: https://github.com/FredrickOdondi/eunify

https://apkpure.com/eunify/com.eunify.client

Built with Swift, SwiftUI, Flutter, Dart, and Supabase.

I open-sourced 5 tiny SwiftUI utilities I use in every project

Mon, 23 Mar 2026 14:37:01 +0000

Sharing 5 lightweight SwiftUI packages I built — keyboard avoider, scroll offset tracker, shimmer effect, flow layout, and App Store review link

Hey everyone! I've been building iOS apps for a while and kept copying the same utilities across projects, so I finally packaged them up as SPM libraries.

1. swiftui-keyboard-avoider

One-line modifier that moves your view when the keyboard appears.

TextField("Email", text: $email)
  .keyboardAvoider()

2. swiftui-scroll-offset

Track ScrollView offset — great for collapsing headers.

OffsetTrackingScrollView { offset in
  print(offset.y)
} content: {
  // your content
}

3. swiftui-shimmer-loading

Shimmer / skeleton loading effect for any view.

Text("Loading...")
  .shimmer()

4. swiftui-flow-layout

Wrapping HStack for tags and chips. Uses the Layout protocol.

FlowLayout(spacing: 8) {
  ForEach(tags, id: \.self) { Text($0) }
}

5. ios-appstore-review-link

Open App Store review page with one line.

AppStoreReview.open(appID: "123456789")

Or grab them all at once: SwiftUI Essentials

All MIT licensed, zero dependencies. Would love any feedback or suggestions!

Your App Goes Offline. Does It Panic, Lie, or Handle It Gracefully?

Mon, 23 Feb 2026 09:10:00 +0000

Most developers think about offline mode last - when the app is already done, designs are signed off, and the PM is breathing down your neck about the deadline. The result? Users see a white screen, a frozen spinner, or worse - silently lost data. This article is about building honest UX for no-network states: from the psychology of anxiety to exponential backoff code, from visual error language to conflict resolution strategies. All of it applies to any mobile or web app that operates under unstable connectivity - which is most of them.

The Psychology of Offline States

There's a pattern I've seen in usability tests over and over: a user taps "Send," nothing happens, they tap again - and again. Ten seconds later they either close the app or start getting angry. That's not a network problem. That's an uncertainty problem.

Uncertainty breeds anxiety. Anxiety breeds avoidance. The user doesn't know whether their message went through, whether the document saved, whether the transaction completed. The brain interprets the system's silence as a threat: "Something went wrong, and I have no idea what." That's exactly why well-designed offline UX isn't a technical problem - it's an anxiety management problem.

There are three states worth distinguishing: the system is working normally, the system is slow or unstable, the system is fully offline. Each one needs its own visual response. Conflate them and you confuse the user even further. If you show the same indicator for a slow connection as for no connection at all, the user has no idea whether to keep waiting or give up.

One more thing that often gets overlooked: people tolerate waiting much better when they understand why and have a rough sense of how long. This is well-established in queue research and loading UX. Offline is no different. "No internet" is already better than a blank screen. "No internet - your data is saved locally and will sync when the connection is restored" - that's trust.

Visual Language for Offline States

Rule one: don't hide things. I've seen interfaces that simply disabled buttons when there was no network and offered zero explanation. The user stares at a grayed-out button and thinks: is this a feature? A bug? Why now?

The offline state needs to be explicit. A banner at the top of the screen in a neutral color - not red; red signals an error, not an environmental condition - a status bar indicator, a subtle UI change - all of these work. The core rule: UI elements that are unavailable because of missing connectivity should be visible but clearly disabled, with an explanation. Not hidden - disabled, with a tooltip or inline message.

A solid practice for mobile apps is showing connection state in the toolbar or navigation bar. On iOS you can observe NWPathMonitor and update the UI reactively:

import Network

final class NetworkMonitor: ObservableObject {
    private let monitor = NWPathMonitor()
    private let queue = DispatchQueue(label: "NetworkMonitor")

    @Published var isConnected: Bool = true

    init() {
        monitor.pathUpdateHandler = { [weak self] path in
            DispatchQueue.main.async {
                self?.isConnected = path.status == .satisfied
            }
        }
        monitor.start(queue: queue)
    }
}

In SwiftUI this plugs in trivially via @EnvironmentObject, letting any screen react to connectivity changes without tight coupling.

On the iconography front: I prefer the SF Symbol wifi.slash on iOS - users read it instantly. On the web, the same idea applies with SVG icons, but don't overdo animation. A pulsing offline icon gets annoying within thirty seconds. A static one just informs.

Queueing Actions for Later Sync

This is where the real engineering begins. When a user does something offline - likes a post, creates a task, edits a document - that action needs to be stored somewhere and executed later. A simple in-memory array won't survive an app restart. You need a persistent store: Core Data, SQLite, or at minimum UserDefaults for simple cases.

But persistence is only half the problem. The other half is idempotency.

Idempotency means that executing the same operation multiple times produces the same result. This is critical for a sync queue, because we never actually know whether the request reached the server before the connection dropped. If an operation isn't idempotent, retrying it might create duplicates or corrupt data.

In practice, this is solved two ways. First - assign a client-generated UUID to each operation and send it in the Idempotency-Key header. The server stores this key and on a duplicate request returns the same response without re-executing the operation. Second - design operations as PATCH with specific fields rather than POST with a full object, or use event sourcing on the server side.

Conflicts are their own story. If a user edited a document offline while another user changed the same document on the server, you have a conflict. The resolution strategies break down like this.

Last Write Wins is the simplest approach and often the wrong one. One side's changes get thrown away. Fine for non-critical data like settings, not fine for much else.

Merge - for structured data like text or lists, you can apply a three-way merge: base, client version, server version. This is exactly how Git works. CRDT (Conflict-free Replicated Data Types) is the more powerful variant, used by Figma and Linear for collaborative editing.

Ask the User - when automatic merging isn't possible, show both versions and let the user decide. Bad if it happens constantly, but sometimes it's the only honest option.

I try to design the queue as a state machine: each action has a status of pending, syncing, synced, or failed. This simplifies both the UI state display and the retry logic considerably.

Showing "Pending" vs "Failed" - Different States Deserve Different Treatment

This distinction gets ignored surprisingly often. "Waiting to send" and "failed to send" are fundamentally different situations from the user's perspective. The first requires no action. The second requires a decision.

For pending, a subtle indicator works fine: a gray checkmark, a clock icon, a small badge. The user needs to understand that their action was recorded but hasn't synced yet. No need to shout about it - a quiet signal is enough.

For failed, you need explicit feedback. A red icon, an inline error message, and - critically - the ability to cancel. If a user sent a message, it didn't go through, and they see a failed status, they need a "Cancel" or "Try Again" button right there. Without it they're stuck: the action appears to have happened, but it hasn't.

Undo for failed states works on the principle of "soft deletion": the action stays in the queue but gets marked as cancelled. That's simpler than rolling back state. For chats and feeds - show failed messages in gray with an error icon and a retry button next to them. This is a pattern users already know from WhatsApp and Telegram. No need to reinvent it.

Auto-Retry with Exponential Backoff

The naive retry implementation is a loop with a fixed interval. The problem: if a thousand clients lose connectivity simultaneously - say, the office WiFi goes down - they all come back online and hammer the server in sync. That's a thundering herd, and it can take a backend down.

Exponential backoff with jitter solves this. Each subsequent attempt waits twice as long as the previous one, and random jitter spreads the requests across time. Here's an implementation in Swift using async/await:

enum RetryError: Error {
    case maxAttemptsReached
    case cancelled
}

func withExponentialBackoff<T>(
    maxAttempts: Int = 5,
    baseDelay: TimeInterval = 1.0,
    operation: @escaping () async throws -> T
) async throws -> T {
    var attempt = 0

    while attempt < maxAttempts {
        do {
            return try await operation()
        } catch {
            attempt += 1
            guard attempt < maxAttempts else {
                throw RetryError.maxAttemptsReached
            }

            let delay = baseDelay * pow(2.0, Double(attempt - 1))
            let jitter = TimeInterval.random(in: 0...delay * 0.3)
            try await Task.sleep(nanoseconds: UInt64((delay + jitter) * 1_000_000_000))
        }
    }

    throw RetryError.maxAttemptsReached
}

Usage:

let result = try await withExponentialBackoff {
    try await apiClient.syncPendingActions()
}

For the Combine stack this looks different, but the idea is the same - .retry() in Combine doesn't support delays out of the box, so you need a custom operator or a flatMap with Deferred + Future and DispatchQueue.asyncAfter.

One important detail: retries need to stop when the user explicitly cancels an action, or when the app goes to background. Otherwise you're burning battery and burning data for nothing. I usually tie the retry lifecycle to the task's lifetime in the queue and cancel the Task on controller or view model deinitialization.

The maximum number of attempts is a product policy question. For critical transactions - payments, medical data - more attempts and an explicit notification when they're exhausted. For non-critical stuff - analytics, logs - fewer attempts and a silent fail.

Testing Offline Scenarios

This is where most teams cut corners, and it shows in production. Testing offline isn't "turn off WiFi and see what happens." It's a systematic check of every state transition.

On iOS there's Network Link Conditioner - a tool in [Additional Tools for Xcode](https://developer.apple.com/download/all/?q=Additional Tools). It lets you simulate different network qualities: 100% packet loss, high latency, unstable connectivity. Installs as a system extension on Mac or directly on a device via Settings for real hardware. I use the "100% Loss" profile for full offline testing and "Very Bad Network" for degraded connectivity - these are genuinely different UX situations.

On Android the equivalent is adb shell with network state commands:

# Disable mobile data
adb shell svc data disable

# Disable WiFi
adb shell svc wifi disable

# Turn them back on
adb shell svc data enable
adb shell svc wifi enable

For web - Chrome DevTools, Network tab, throttle to "Offline" or set up a custom profile.

But beyond tooling, methodology matters. You need to test specific scenarios: what happens if connectivity drops mid-load? Mid-form submission? What if the user closed the app while a pending action was sitting in the queue, then reopened it? What if the auth token expired during the offline period?

That last one is particularly nasty. The user comes back online, the queue starts syncing, gets a 401 Unauthorized, and now there's a conflict between "need to retry" and "need to refresh the token first." This needs to be tested explicitly and handled explicitly in code. I'd genuinely love to hear how others approach this one in the comments.

Unit tests for queue logic are worth writing against a mock network layer that lets you control success and failure. XCTest makes this straightforward through protocols and dependency injection - no URLSession directly in production code.

When to Warn Users About Data Loss

This is the most painful scenario, and it demands honesty. If data might be lost - warn the user. Before it happens, not after.

Two typical cases. First: a user tries to exit an unsaved document while offline. The classic "Save / Don't Save / Cancel" dialog isn't enough here - you need to say explicitly: "You have unsaved changes. They can't be synced right now and will only be stored locally." That's more honest.

Second: when the sync queue has grown large enough that you can't guarantee all data will survive a cache clear or app update. This calls for a proactive notification - not necessarily a push, but at least an in-app banner on the next launch.

A separate case is critical data that simply shouldn't be stored locally at all: medical records, financial transactions, legally binding signatures. My view is that for these, the right UX is to block the action entirely when there's no network, and explain clearly why. Yes, it's inconvenient. But a lost transaction or a missynced medical record is incomparably worse.

The general principle I work by: users should have the ability to make an informed decision. If we can't guarantee data integrity - say so explicitly and give them a choice: wait for connectivity, save a local copy at their own risk, or cancel the action. Silence here isn't neutral. It's a lie.

A well-implemented offline mode is one of those places where an app either earns long-term user trust or loses it for good. A lost message, a forgotten form, a silent interface on the subway - it all accumulates. The investment in offline UX pays off not in metrics but in reputation.

SwiftUI vs UIKit in 2026: When to Use What

Sat, 24 Jan 2026 16:38:16 +0000

The Myth That SwiftUI Will Replace UIKit

Let's get this straight right away: if someone tells you SwiftUI is the future and UIKit is legacy, don't believe them. Apple itself continues writing critical parts of its apps in UIKit. Open Settings on your iPhone - that's UIKit. Music? UIKit with sprinkles of SwiftUI. Photos? Same story.

Why is this happening? Because SwiftUI, despite all its advantages, can't handle certain tasks as efficiently as UIKit. I've seen projects where teams tried to write everything in SwiftUI "because it's trendy," then spent three months fighting navigation bugs and ended up rewriting in UIKit.

Over the past few years, SwiftUI has grown significantly. The Navigation API got better with NavigationStack and NavigationSplitView. We got proper scroll position tracking support. But the fundamental limitations haven't gone anywhere. When you need pixel-perfect control over layout or complex animation with precise synchronization between elements, SwiftUI starts struggling.

The truth is that in 2026, both frameworks have a right to exist. The question isn't what to choose, but when to use what. And most importantly - do you even need to pick just one?

Where SwiftUI Really Wins

SwiftUI shines when you need to quickly assemble UI from standard components. Declarative syntax isn't just pretty marketing words from Apple, it actually works.

Compare:

// UIKit
let label = UILabel()
label.text = "Hello"
label.textColor = .systemBlue
label.font = .systemFont(ofSize: 16, weight: .bold)
view.addSubview(label)
label.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
    label.centerYAnchor.constraint(equalTo: view.centerYAnchor)
])
// SwiftUI
Text("Hello")
    .font(.system(size: 16, weight: .bold))
    .foregroundColor(.blue)

The difference is obvious. But it's not just about lines of code.

Live previews in SwiftUI - that's what made me actually fall in love with this framework. When you're writing a registration form and see changes in real-time without rebuilding the project, that saves hours. In UIKit you either launch the simulator every time or struggle with Interface Builder, which periodically breaks storyboards.

Yes, previews crash sometimes. Yes, after an Xcode update they might stop working for a couple days. But when everything works - it's incredibly convenient. You can set up multiple preview configurations with different data, screen sizes, dark/light mode simultaneously. Try doing the same in UIKit - you'll have to either write a playground or create separate view controllers for each case.

Cross-platform development - another SwiftUI ace. The same code works on iOS, macOS, watchOS, and - importantly in 2026 - visionOS. Apple is clearly betting on Vision Pro, and if you want to port your app there without a complete rewrite, SwiftUI gives you a head start.

Real-world example: I made a habit tracking app. The main screen was a list with checkboxes and statistics. Wrote the entire UI in SwiftUI in one day. Then the client asked for a macOS version. Added a couple #if os(macOS) checks to adapt the menu, and done. If this were UIKit, I'd have to write the entire macOS interface from scratch using AppKit.

Here's another point many people miss: state management in SwiftUI is built into the framework. @State, @Binding, @ObservableObject - these aren't just property wrappers, they're a whole philosophy of data management. In UIKit you have to build architecture yourself: MVVM, VIPER, Coordinator pattern. In SwiftUI basic cases work out of the box.

struct CounterView: View {
    @State private var count = 0
    
    var body: some View {
        VStack {
            Text("Count: \(count)")
            Button("Increment") {
                count += 1
            }
        }
    }
}

This code just works. No delegates, target-action, KVO, or notification center. Pressed button - state updated - UI redrawn. In UIKit the same task requires more code and explicit update management.

Personally, I use SwiftUI for:

App settings (forms with toggles, sliders)
Onboarding (five screens with animations between them)
Simple forms (registration, login)
Prototypes that need to be shown to clients in a couple days
Dashboards with charts and statistics
Any new features in existing apps where there are no strict performance requirements

When UIKit Is Still Irreplaceable

UIKit is older, which means more stable. There are no unexpected surprises that SwiftUI loves to deliver in every Xcode release.

Take gestures. SwiftUI has .gesture(), but try doing something more complex than a simple tap - for example, simultaneous pan and pinch recognition with different priorities. In UIKit it's UIPanGestureRecognizer + UIPinchGestureRecognizer with delegates, everything's clear and works predictably. In SwiftUI you'll have to build workarounds through UIViewRepresentable.

I had a project with a custom image editor. Users could zoom photos, rotate them, apply filters in real-time. On SwiftUI this turned into a nightmare. Gesture modifiers conflicted with each other, priorities didn't always trigger correctly. Rewrote it in UIKit in two days, and everything worked like clockwork.

Libraries. Almost the entire powerful iOS ecosystem is written for UIKit. Want to integrate a cool charting library like Charts (not Apple Charts, but third-party)? Most likely it's UIKit. Yes, you can wrap it through representable, but that's an additional layer of abstraction and potential lifecycle problems.

Performance control. In UIKit you know exactly when layout happens, when a view renders, you can optimize layoutSubviews, use drawRect for custom drawing. In SwiftUI the framework decides when to redraw something, and sometimes does it too often.

I encountered a situation where a complex SwiftUI view was redrawing 60 times per second for no visible reason. Profiling showed the problem was implicit state changes - somewhere deep in the hierarchy a @State was updating, and the entire subtree was redrawing. Debugging that was quite the quest. In UIKit this doesn't happen: if a view updates, someone explicitly called setNeedsDisplay or setNeedsLayout.

Another point: memory management. In SwiftUI it's very easy to catch a retain cycle through capturing self in closures. All those @StateObject and @ObservedObject add magic that sometimes doesn't work as you expect. In UIKit everything's explicit: there's weak, unowned, and you know exactly who's holding whom.

Collection views with custom layout. UICollectionView with custom UICollectionViewLayout is an incredibly powerful tool. You can do Pinterest-style masonry grids, circular layouts, complex transition animations between cells. SwiftUI has LazyVGrid and LazyHGrid, but they only cover basic cases. As soon as you need something non-standard - back to UIKit.

Accessibility. Strangely enough, in UIKit the accessibility API is more mature and predictable. In SwiftUI modifiers like .accessibilityLabel() work, but when you start doing something more complex - custom rotor actions, adjustable traits, grouped elements - UIKit gives more control.

I choose UIKit for:

Custom controls with non-standard behavior (slider with non-uniform scale, circular progress with animations)
Apps where every millisecond matters (video editors, games)
Projects with minimum iOS 13-14 (SwiftUI there is too raw)
Complex animations with CALayer and Core Animation
Working with large tables (thousands of rows with good performance)
Integration with complex third-party SDKs

Hybrid Approach: Best of Both Worlds

The most reasonable solution - combine them. Apple itself does this, why shouldn't we? A hybrid approach lets you use SwiftUI where it's convenient and UIKit where it's necessary.

UIKit in SwiftUI via UIViewRepresentable

Say you need a rich text editor in a SwiftUI app. The standard TextEditor is too simple - no formatting, can't change fonts or colors. Ready-made SwiftUI solutions either don't exist or cost money. Take the proven UITextView and wrap it:

struct RichTextEditor: UIViewRepresentable {
    @Binding var text: NSAttributedString
    var placeholder: String
    
    func makeUIView(context: Context) -> UITextView {
        let textView = UITextView()
        textView.delegate = context.coordinator
        textView.font = .systemFont(ofSize: 16)
        textView.backgroundColor = .clear
        textView.textContainerInset = UIEdgeInsets(top: 8, left: 8, bottom: 8, right: 8)
        return textView
    }
    
    func updateUIView(_ uiView: UITextView, context: Context) {
        // Important: only update if text actually changed
        if uiView.attributedText != text {
            let selectedRange = uiView.selectedRange
            uiView.attributedText = text
            // Preserve cursor position
            uiView.selectedRange = selectedRange
        }
    }
    
    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
    
    class Coordinator: NSObject, UITextViewDelegate {
        var parent: RichTextEditor
        
        init(_ parent: RichTextEditor) {
            self.parent = parent
        }
        
        func textViewDidChange(_ textView: UITextView) {
            // Update binding only when text changes
            parent.text = textView.attributedText
        }
        
        func textViewDidBeginEditing(_ textView: UITextView) {
            if textView.text == parent.placeholder {
                textView.text = ""
            }
        }
    }
}

It works. But there are nuances. The most important - state synchronization between SwiftUI and UIKit can be painful. Make sure not to create unnecessary updates in updateUIView, otherwise you'll get an infinite redraw loop or lose focus in text fields.

Another example - custom map view with annotations. MKMapView from MapKit works great, but natively it's a UIKit component. Wrap it:

struct MapView: UIViewRepresentable {
    @Binding var region: MKCoordinateRegion
    var annotations: [MKPointAnnotation]
    
    func makeUIView(context: Context) -> MKMapView {
        let mapView = MKMapView()
        mapView.delegate = context.coordinator
        return mapView
    }
    
    func updateUIView(_ mapView: MKMapView, context: Context) {
        mapView.setRegion(region, animated: true)
        
        // Update annotations only if changed
        if mapView.annotations.count != annotations.count {
            mapView.removeAnnotations(mapView.annotations)
            mapView.addAnnotations(annotations)
        }
    }
    
    func makeCoordinator() -> Coordinator {
        Coordinator(self)
    }
    
    class Coordinator: NSObject, MKMapViewDelegate {
        var parent: MapView
        
        init(_ parent: MapView) {
            self.parent = parent
        }
        
        func mapView(_ mapView: MKMapView, regionDidChangeAnimated animated: Bool) {
            parent.region = mapView.region
        }
    }
}

SwiftUI in UIKit via UIHostingController

Reverse task: you have a large UIKit app, but a new settings screen is easier to write in SwiftUI. Or you need to add a beautiful dashboard with charts, and doing it in UIKit is pure hell.

class MainViewController: UIViewController {
    
    func showSettings() {
        let settingsView = SettingsView(onDismiss: { [weak self] in
            self?.dismiss(animated: true)
        })
        
        let hostingController = UIHostingController(rootView: settingsView)
        hostingController.modalPresentationStyle = .formSheet
        
        present(hostingController, animated: true)
    }
}

struct SettingsView: View {
    @AppStorage("notifications") private var notifications = true
    @AppStorage("darkMode") private var darkMode = false
    var onDismiss: () -> Void
    
    var body: some View {
        NavigationView {
            Form {
                Section("Preferences") {
                    Toggle("Enable Notifications", isOn: $notifications)
                    Toggle("Dark Mode", isOn: $darkMode)
                }
            }
            .navigationTitle("Settings")
            .toolbar {
                Button("Done", action: onDismiss)
            }
        }
    }
}

This is simpler than UIViewRepresentable. Main thing - properly handle lifecycle to avoid memory leaks. SwiftUI view inside hosting controller holds strong references to all its @ObservedObject and @StateObject, so be careful with closures.

Another important point: sizing. UIHostingController doesn't always correctly determine its size. If adding a SwiftUI view as a child view controller, explicitly set frame or constraints:

let hostingController = UIHostingController(rootView: mySwiftUIView)
addChild(hostingController)
view.addSubview(hostingController.view)

hostingController.view.translatesAutoresizingMaskIntoConstraints = false
NSLayoutConstraint.activate([
    hostingController.view.topAnchor.constraint(equalTo: view.topAnchor),
    hostingController.view.leadingAnchor.constraint(equalTo: view.leadingAnchor),
    hostingController.view.trailingAnchor.constraint(equalTo: view.trailingAnchor),
    hostingController.view.heightAnchor.constraint(equalToConstant: 300)
])

hostingController.didMove(toParent: self)

I use a hybrid approach in most projects. The main architecture can be UIKit, but individual screens - SwiftUI. Or vice versa: SwiftUI base, but custom controls through UIViewRepresentable. Main thing - don't obsess over one technology and choose the right tool for the job.

Performance: Numbers, Not Myths

I ran tests on iPhone 15 Pro, iPhone 12 mini, and iPhone SE 2020. Here's what I got.

Startup time:

SwiftUI app (clean project): ~180ms
UIKit app (clean project): ~140ms

SwiftUI is slightly slower on startup due to additional runtime and framework initialization. On new devices the difference is imperceptible, on old ones - you feel it. If your app needs to launch instantly (camera, calculator), every millisecond matters.

Memory footprint: When displaying a list of 1000 elements with images:

SwiftUI List: ~45MB
UIKit UITableView: ~38MB

Again SwiftUI loses, but not critically. The 7MB difference for modern devices with 6-8GB RAM is insignificant. But if you're making an app for emerging markets where users are on old iPhones, those megabytes can become a problem.

Scroll performance: Here it gets more interesting. Complex list with images, text, and buttons:

SwiftUI on iPhone 15 Pro: stable 60 FPS (120 on ProMotion)
SwiftUI on iPhone 12 mini: drops to 45-50 FPS during fast scrolling
SwiftUI on iPhone SE 2020: drops to 40 FPS
UIKit on all devices: stable 60 FPS

SwiftUI works better on new hardware, but if your audience is on old iPhones, UIKit gives more predictable results. The difference is especially noticeable when cells have asynchronous image loading or complex calculations.

Navigation stacks: Deep navigation (7-8 screens) in SwiftUI sometimes glitches - screens don't dismiss correctly, especially with custom transitions or when combining sheets, fullScreenCover, and NavigationStack. In UIKit navigation controller works like a Swiss watch for 15 years already.

Animations: Simple animations (fade, scale, rotation) in SwiftUI are written in seconds and work smoothly:

@State private var isAnimating = false

Circle()
    .scaleEffect(isAnimating ? 1.5 : 1.0)
    .animation(.spring(response: 0.5), value: isAnimating)

Beautiful, simple, works. But try making a complex sequence of animations with dependencies - for example, element A moves, then element B fades in, then both rotate. In SwiftUI you'll have to use withAnimation, DispatchQueue.asyncAfter and pray the timings align.

In UIKit through UIView.animate or CAAnimation you have full control. You can set exact curves, completion handlers, group animations. For simple cases SwiftUI is more convenient, for complex ones - UIKit is more reliable.

Concrete case: Instagram-like feed Made a test: feed with posts (image, author name, likes, comments). 500 posts, scroll through the entire list.

SwiftUI version:

Memory: 65MB
Frame drops: 15-20% on iPhone 12
Code: ~150 lines

UIKit version:

Memory: 52MB
Frame drops: 2-3% on iPhone 12
Code: ~300 lines

UIKit wins on performance but requires twice as much code. What to choose? Depends on priorities. If development speed matters more than the last few percent of performance - SwiftUI. If the app needs to fly even on old hardware - UIKit.

Decision-Making Checklist

Here's how I make decisions for each new feature or project:

Use SwiftUI if:

Minimum iOS version of the project is 15+ (better 16+)
Need a quick prototype or MVP
UI consists of standard components (buttons, text, lists, forms)
Planning to support visionOS, macOS, or watchOS
Team is ready to deal with bugs and unstable API
Performance on old devices isn't critical
No dependency on complex UIKit libraries
Project is new or you can isolate the feature into a separate module

Use UIKit if:

Need to support iOS 13-14 (or even older)
Performance on old devices is critical
Complex custom gestures or animations required
Strong dependency on third-party UIKit libraries
No time for experiments with unstable API
Need pixel-perfect control over layout
Working with large data volumes (thousands of elements)
App needs to be maximally stable (fintech, medicine)

Use hybrid approach if:

Migrating from UIKit to SwiftUI gradually
Have legacy code that works and you're scared to touch it
Different screens have different requirements
Want new features in SwiftUI but base in UIKit
Need custom UIKit components in SwiftUI app
Team knows both frameworks

Red flags for SwiftUI:

Client requires iOS 13 support
App lags even on new devices
Xcode previews haven't worked for a week
Spending more time fighting the framework than on features
Need to integrate 10+ UIKit libraries

Red flags for UIKit:

Writing 500 lines of code for a simple form
Spending an hour on layout constraints for one screen
Junior developer can't figure out storyboards
Every UI change requires full rebuild

Conclusion: It's About Trade-offs, Not Trends

I manage several projects simultaneously. In one - pure SwiftUI, because it's an internal team tool with minimal performance requirements. In another - UIKit with small SwiftUI inclusions for simple screens like settings or onboarding. In the third - pure UIKit, because the client requires iOS 14 support and performance on old devices is critical.

Choosing a framework is about context, not hype. SwiftUI is a great tool for certain tasks. But it's not a silver bullet. UIKit isn't going anywhere for a very long time, and that's okay.

If SwiftUI solves your problem faster and more reliably - use it. If not - don't hesitate to write in UIKit. If you need both - combine them. Your job is to deliver a product that works, not follow trends from conferences.

Final advice: learn both frameworks. Even if you're a SwiftUI fanatic, knowing UIKit will make you a better developer. And vice versa. Understanding how UIKit works under the hood helps write more efficient SwiftUI code. And knowing SwiftUI patterns can improve your UIKit architecture.

In 2026, the best iOS developer isn't the one who only knows SwiftUI or only UIKit. It's the one who knows both and can choose the right tool for the specific task.

Why most apps feel broken (and why justRead is different)

Thu, 22 Jan 2026 12:00:54 +0000

Development of justRead app in six parts; part four.

The elephant in the room

You’ve probably felt it. That moment when you download an app that looks beautiful but feels wrong. The onboarding is confusing. Navigation is buried three taps deep. Performance stutters when you expect smoothness. The developer clearly built the app for themselves, not for you.

According to research, 68% of users will switch to a competitor after just one poor experience.
Another study found 88% of users abandon apps due to bad UX alone — not because they lack features, but because they feel poorly made.

What’s striking is that this isn’t accidental. It’s a symptom of how most apps are built: from the inside out. Developers ship features without asking if users actually want them. They guess at what “polish” means instead of asking or following guidelines. They update mysteriously, leaving users confused about what changed or why.

Most apps are made at users, not for them. And users notice.

The 15-year perspective

I’ve spent 15 years building software, and the last decade focusing obsessively on user experience. I’ve watched talented developers ship broken apps. Not technically broken — but broken in the ways that matter: confusing navigation, invisible affordances, missing the small details that make something feel intentional versus accidental — ever experienced misaligned icons?

And the worst part? Many developers don’t ask what’s broken and what the app needs. They release updates in silence. Users guess why something changed. Features land that nobody wanted. Features people asked for never ship.

Meanwhile, I’m also a lifetime reader. I’ve used every EPUB reader on iOS. I’ve felt the frustration — smooth scrolling that isn’t, fonts that don’t render properly, library management that feels like an afterthought, features that exist but feel bolted on.

It became clear: the apps that survive are built by people who deeply understand both craft and empathy.

The problem: apps without voices

Here’s what most apps do wrong: they assume users can read minds.

You download an app. It’s pretty. But then:
You have an idea for a feature
You email support (if there even is one)
You never hear back
Months later, a mysterious update arrives
You have no idea if it addressed your feedback or ignored it
You uninstall

This happens because there’s no conversation. The developer is building in a vacuum. Users are waiting in the dark.

72% of users say they expect regular feature updates as extremely important or very important. But most apps provide zero visibility into what’s coming next. Not a roadmap. Not a hint. Just silence, then surprise.

This erodes trust. And once trust is gone, so are you.

The better way: an in-app roadmap where users vote

This is where justRead is different.

Right in the app, you’ll find the Feature Roadmap — a living, breathing board where you can:

Vote on features you want to see built next
See exactly what’s in progress (because transparency matters)
Track completed features and know your voice shaped them
Comment and discuss ideas before they’re implemented
Understand the “why” behind development decisions

This isn’t performative transparency. It’s not a gesture. It’s the actual mechanism by which justRead is built — using VoteFirst, a platform designed specifically for this purpose. Your votes influence what gets built. Your feedback shapes how it gets built. The roadmap updates live — you see progress in real time.

Why does this matter?

When users can see and influence the roadmap, something shifts: they go from being customers to being partners. Research shows users who participate in voting are significantly more likely to appreciate updates when they ship — not because the features are better, but because they see themselves in the product.
They feel heard. And when users feel heard, they stay.

Proof that polish matters

I didn’t enter indie app development to build a mediocre reading app. I built justRead because I wanted to create something that feels intentional in every interaction.

That means:

Smooth scrolling that doesn’t stutter
Thoughtful font rendering that respects typography
Micro-interactions that feel responsive, not delayed
Consistent design language throughout (not features that feel bolted on)
Performance optimization so the app doesn’t drain your battery
Respecting Apple design guidelines

This is tedious work. No user notices these things consciously. But they feel them. An app that’s been polished feels different — lighter, faster, more trustworthy. An app that hasn’t feels like extra work.

This isn’t vanity. Research shows that app performance and stability directly impact how users perceive your entire brand. One laggy app, and users assume you’re careless everywhere. One smooth app, and they assume you care about details that matter.

The message to users

If you’re a reader considering justRead, here’s what we’re offering: an app built by someone who reads, who understands what makes apps feel good, and who believes you should have a voice in what gets built.

You’re not downloading software. You’re joining a community where your vote matters and your feedback shapes what comes next. Features land because you asked for them, not because a product manager guessed.

That’s a different kind of relationship. One where the developer is visibly, consistently working for you.

Join the waitlist at justread.app and be part of this process. See the roadmap for yourself. Vote on features. Help us prove that apps can be built for readers, not at them.

The message to developers

If you’re a developer reading this, consider what justRead is doing: creating an in-app feature roadmap with user voting.

Why is this a differentiator? Because most apps don’t do it. Most developers hide their roadmap (if they have one). Most users have no idea what’s being built or if their feedback matters.

But users crave this transparency. It’s low-cost to build — a GitHub Project, a Notion board, or a dedicated platform like Frill, Changelogfy, or VoteFirst. The hard part isn’t the tool. It’s the commitment: showing your users you’re willing to be transparent about progress, priorities, and constraints.

When users see your roadmap, they understand:

What you’re working on right now
What’s coming next (and when)
Why some features get prioritized over others
That you’re actively listening
This builds trust in ways that polished marketing can’t touch.

It’s also a recruiting tool. Developers and designers are attracted to projects that care about users. Transparency says: “We’re not hiding anything. Come build with us.”

The unspoken competition

The competition for user attention isn’t just between EPUB readers. It’s between apps that feel like they want to work for you and apps that feel like they’re tolerating your existence.

Most apps fall into the latter category. They’re technically functional but emotionally cold. No voice. No relationship. No sense that a human being made thoughtful choices about every detail.

The apps that win — and I mean truly win, with loyal users who evangelize them — are the ones that feel personal. That feel like someone cared enough to polish every interaction. That feel like the developer is sitting across from you, listening to what you need.

That’s not a coincidence. That’s design.

What’s next

justRead launches with a public, in-app roadmap where you can see every feature in progress and vote on what comes next. This isn’t a “maybe someday” feature. It’s core to how we build.

If you’re a reader, that means your voice matters from day one.

If you’re a developer, consider: What if your users didn’t have to wonder what you’re building? What if they could see, vote, and feel ownership over your product’s direction?

The difference between an app that works and an app that matters is smaller than you think. It starts with listening. It continues with transparency. And it compounds when users feel like partners instead of customers.

Most apps miss this. They release in silence. They update mysteriously. They hope users stay.

justRead is built differently.

Your vote. Your voice. Your app.

Ready to join?

If you want to be part of shaping justRead’s future — and you’ve been waiting to see what makes this app different — your moment is coming.
→ Join the waitlist at justread.app

Watch the roadmap. Vote on features. See your feedback become reality. Help us prove that apps can be built forreaders, not at them.

P.S. If you’re a developer interested in implementing feature voting in your own app, check out VoteFirst — that’s what powers justRead’s roadmap. Transparency and user collaboration should be standard practice, not an afterthought.

Peter
Reader, Developer, justRead Creator

Modern Networking in iOS with URLSession and async/await: A Practical Guide

Mon, 15 Dec 2025 19:28:11 +0000

Networking is at the core of most iOS apps. Almost every modern application needs to talk to remote services, fetch or send data, and present fetched information in real time. This makes it essential to have a reliable, safe, and maintainable approach to performing HTTP requests.

Apple provides URLSession as the standard way to handle network communication in iOS. It's robust, battle-tested, and highly configurable. Whether you need to fetch JSON, download files, or upload data, URLSession is the foundation you'll build on. In the past, developers relied on completion handlers or Combine to manage these asynchronous calls. While functional, those methods introduced complexity and verbosity.

Enter async/await, introduced in Swift 5.5. This modern concurrency model transforms asynchronous code into something that reads and behaves like synchronous code. With async/await, networking becomes:

Easier to read and maintain
Safer and less error-prone
More Swift-native and familiar

This tutorial will walk you through building a modern, fully async network layer using URLSession and async/await and display the fetched data in a SwiftUI list.

The APIs We’ll Use

The following public testing APIs will be used

GET https://jsonplaceholder.typicode.com/users
GET https://jsonplaceholder.typicode.com/posts
GET https://jsonplaceholder.typicode.com/comments

They return dummy data, which we will use to display lists of users, posts and comments

Step 1: Create the Models

Before we can decode any JSON, we need to define some models that mirror the structure of the API responses. In Swift, we use the Codable protocol to enable easy JSON parsing and Identifiable to make integration with SwiftUI lists seamless.

Codable allows us to convert between JSON data and Swift structs automatically.
Identifiable is required for SwiftUI's List view to uniquely identify each element in a collection.

struct User: Codable, Identifiable {
    let id: Int
    let name: String
    let username: String
    let email: String
}

struct Post: Codable, Identifiable {
    let id: Int
    let userId: Int
    let title: String
    let body: String
}

struct Comment: Codable, Identifiable {
    let id: Int
    let postId: Int
    let name: String
    let email: String
    let body: String
}

Step 2: Create the Networking Layer

We use two powerful Swift features: enums and generics to create a scalable and maintainable networking layer.

enum Endpoint

The Endpoint enum encapsulates all supported API paths in a single type-safe structure.
Each case in the enum maps to a specific endpoint (e.g. .users, .comments(postId:)), avoiding stringly-typed URLs scattered throughout your code.
It helps centralize logic like HTTP method selection and URL path construction.

enum Endpoint {
    case users
    case posts
    case comments(postId: Int)

    var path: String {
        switch self {
        case .users: return "/users"
        case .posts: return "/posts"
        case .comments(let postId): return "/posts/\(postId)/comments"
        }
    }

    var method: HTTPMethod {
        switch self {
        case .users, .posts, .comments: return .GET
        }
    }
}

enum NetworkError

Structured error handling: Clearly categorizes different failure scenarios such as URL construction issues, server errors, and decoding problems.
Better debugging: By distinguishing error types, you can display user-friendly messages or handle specific issues differently (e.g., retry on .serverError).
Swift-native: Conforms to Swift’s Error protocol and integrates seamlessly with try/catch.

enum NetworkError: Error {
    case invalidURL
    case decodingError
    case serverError(statusCode: Int)
    case unknown(Error)
}

enum HTTPMethod

enum HTTPMethod: String {
    case GET, POST, PUT, DELETE
}

Clarity: This enum defines common HTTP methods as strongly-typed cases instead of using raw strings like "GET" or "POST" throughout your code.
Safety: Prevents typos and allows the compiler to catch invalid method usage.
Scalability: Easy to extend by adding methods like .PATCH or .HEAD later.

protocol APIRequest

protocol APIRequest {
    associatedtype Response: Decodable
    var endpoint: Endpoint { get }
}

extension APIRequest {
    var url: URL? {
        var components = URLComponents()
        components.scheme = "https"
        components.host = "jsonplaceholder.typicode.com"
        components.path = endpoint.path
        return components.url
    }
}

struct GetUserRequest: APIRequest {
    typealias Response = [User]
    let endpoint: Endpoint = .users
}

struct GetPostsRequest: APIRequest {
    typealias Response = [Post]
    let endpoint: Endpoint = .posts
}

struct GetCommentsRequest: APIRequest {
    typealias Response = [Comment]
    let endpoint: Endpoint = .users
}

Generic Request Definition: This protocol defines the structure for any type of API request.
associatedtype Response: This allows each request to specify the exact data type it expects to receive. For example, one request might return [User], another might return [Post].
Decodable constraint: Ensures the response can be parsed from JSON using Swift’s Decodable system.
Extensibility: By conforming to this protocol, you can add any number of request types (GetPostsRequest, GetCommentsRequest, etc.) without modifying the networking logic.
Extension with default URL construction: Instead of requiring every request to build its own URL, we use a protocol extension to provide a shared implementation.
Encapsulation of base URL logic: Centralizes the host and scheme configuration (e.g. "https://jsonplaceholder.typicode.com"), keeping the logic DRY (Don't Repeat Yourself).
Reusability: Any request that conforms to APIRequest gets this default URL computation for free.

func send

This is a generic function that works with any type conforming to APIRequest, as long as it defines what type of response it expects.
Using generics allows the networking client to remain decoupled from specific model types like User, Post, or Comment.
This makes the network layer reusable and extensible: just create new request types for different endpoints and the same send function will work with them.
async: Indicates this function performs asynchronous work.
throws: Indicates this function can fail and will throw errors you need to handle.
Returns: The decoded result of the API call, e.g., [User] or [Post].

code:

final class NetworkClient {
    func send<T: APIRequest>(_ request: T) async throws -> T.Response {
        guard let url = request.url else {
            throw NetworkError.invalidURL
        }
        var urlRequest = URLRequest(url: url)
        urlRequest.httpMethod = request.endpoint.method.rawValue

        let (data, response): (Data, URLResponse)
        do {
            (data, response) = try await URLSession.shared.data(for: urlRequest)
        } catch {
            throw NetworkError.unknown(error)
        }

        guard let httpResponse = response as? HTTPURLResponse else {
            throw NetworkError.unknown(NSError(domain: "Invalid response", code: 0))
        }

        guard (200..<300).contains(httpResponse.statusCode) else {
            throw NetworkError.serverError(statusCode: httpResponse.statusCode)
        }

        do {
            return try JSONDecoder().decode(T.Response.self, from: data)
        } catch {
            throw NetworkError.decodingError
        }
    }
}

In the above snippet, note the:

(data, response) = try await URLSession.shared.data(for: urlRequest)

The call is made asynchronously (as promised by async) thanks to await.
It suspends execution until the response is received, meaning the next line in the code won't run until await is done.
If any network error occurs (e.g. no connection, timeout), it throws — and we catch it below. Wrapping the error into our custom .unknown error case, preserving the original error for context.

code:

 } catch {
     throw NetworkError.unknown(error)
 }

Next, we validate the response:

guard let httpResponse = response as? HTTPURLResponse else {
    throw NetworkError.unknown(NSError(domain: "Invalid response", code: 0))
}

guard (200..<300).contains(httpResponse.statusCode) else {
    throw NetworkError.serverError(statusCode: httpResponse.statusCode)
}

First checks if the response is an HTTP response.
Then ensures the HTTP status code is in the success range (200–299).
If not, throws a .serverError(statusCode:), making it easier to handle in UI or logs later.

After validation, we are trying to decode the response:

return try JSONDecoder().decode(T.Response.self, from: data)

Tries to decode the received Data into the expected response type (T.Response) using Swift’s Decodable.
If decoding fails, it’s caught and rethrown as our custom .decodingError.

code:

} catch {
    throw NetworkError.decodingError
}

Step 3: Integrating with SwiftUI

ViewModel

import SwiftUI

@MainActor
class UsersViewModel: ObservableObject {
    @Published var users: [User] = []
    @Published var isLoading = false
    @Published var errorMessage: String?

    private let client = NetworkClient()

    func loadUsers() async {
        isLoading = true
        errorMessage = nil

        do {
            let users = try await client.send(GetUsersRequest())
            self.users = users
        } catch {
            errorMessage = "Failed to load users: \(error.localizedDescription)"
        }

        isLoading = false
    }
}

View

import SwiftUI

struct UsersView: View {
    @StateObject private var viewModel = UsersViewModel()

    var body: some View {
        NavigationView {
            Group {
                if viewModel.isLoading {
                    ProgressView("Loading...")
                } else if let error = viewModel.errorMessage {
                    Text(error).foregroundColor(.red)
                } else {
                    List(viewModel.users) { user in
                        VStack(alignment: .leading) {
                            Text(user.name).bold()
                            Text(user.email).font(.subheadline).foregroundColor(.gray)
                        }
                    }
                }
            }
            .navigationTitle("Users")
            .task {
                await viewModel.loadUsers()
            }
        }
    }
}

And we are done!

You can checkout the full project on GitHub.

You can read part II of this subject - dealing with auth tokens here:
https://coderlegion.com/8902/modern-networking-in-ios-with-urlsession-and-async-await-part-2

UIKit v/s SwiftUI in 2025

Wed, 22 Jan 2025 21:27:46 +0000

Choosing Between UIKit and SwiftUI in 2025: A Practical Guide

If you’re an iOS developer, chances are you’ve wondered whether to use UIKit or SwiftUI for your next project. With SwiftUI gaining traction and UIKit remaining a tried-and-true framework, the decision isn’t always straightforward. In 2025, the choice comes down to your app’s needs, your team’s skills, and where you see your project heading. Let us break it down.

UIKit: The Veteran Framework

UIKit has been around since 2008, forming the backbone of iOS app development for years. It is incredibly reliable and offers all the tools you need to build complex, high-performance apps. However, it does come with a steeper learning curve and requires more manual work.

When to Go with UIKit

Complex UIs: If your app needs intricate layouts, custom animations, or highly specific designs, UIKit’s flexibility is hard to beat.
Older iOS Support: For apps targeting users on older devices, UIKit is the safer choice.
Working with Legacy Code: Updating or extending an existing UIKit-based app? Sticking with UIKit simplifies the process.
Precision Animations: UIKit shines when you need precise control over animations or custom graphics.

Pros

Time-tested and stable.
Extensive documentation and community support.
Advanced debugging tools.
Handles complex UI designs effectively.

Cons

More boilerplate code.
Can feel outdated compared to modern approaches.
Slower development for simple tasks.

SwiftUI: The Future of Apple Development

SwiftUI, introduced in 2019, takes a fresh, declarative approach to building UIs. It simplifies code, integrates smoothly with Combine for reactive programming, and works across all Apple platforms. By now, it is a mature and capable framework, though some advanced use cases might still require UIKit.

When to Choose SwiftUI

Modern App Development: Starting fresh? SwiftUI’s faster development cycle and clean syntax are major advantages.

Prototypes and MVPs: Its simplicity makes SwiftUI perfect for quick prototypes or Minimum Viable Products.
Cross-Platform Apps: If you want to target macOS, watchOS, or tvOS alongside iOS, SwiftUI’s shared APIs are a huge plus.
Future-Proofing: SwiftUI is where Apple’s focus lies, making it a solid bet for the long term.

Pros

Cleaner, more readable code.
Faster development cycles.
Built-in support for responsive and dynamic UIs.
Unified development for multiple platforms.

Cons

Doesn’t support iOS versions below 13.
Some advanced features still need UIKit.
Smaller knowledge base compared to UIKit.
API changes as the framework evolves.

Performance: UIKit vs. SwiftUI

Both frameworks offer excellent performance, but UIKit gives you finer control over details, making it better for demanding tasks like custom graphics. On the other hand, SwiftUI’s declarative nature excels in apps with dynamic data and reactive flows. For mixed projects, combining both frameworks can give you the best of both worlds.

What About Your Team and Goals?

Team Expertise

If your team has a deep UIKit background, you might want to stick with it for complex projects.
Teams already comfortable with Swift and declarative programming will find SwiftUI more intuitive.

Project Goals

If your app needs to support older devices, UIKit is the way to go.
For quick turnaround and future-proof designs, SwiftUI is a better fit.

A Hybrid Approach

In practice, many developers use a mix of UIKit and SwiftUI. SwiftUI views can embed into UIKit projects, and UIKit components can integrate into SwiftUI apps. This flexibility makes it easier to choose the right tool for each part of your app.

Example

Imagine you’re building a modern app with a highly customized camera feature. You could use UIKit for the camera interface while developing the rest of the app in SwiftUI to save time.

Final Thoughts

In 2025, deciding between UIKit and SwiftUI depends on your app’s needs. UIKit remains a workhorse for complex or legacy projects, while SwiftUI is ideal for modern, future-ready apps. Evaluate your requirements, your team’s expertise, and the project’s timeline to make the best choice.

For most new apps, SwiftUI is the way forward. But UIKit isn’t going anywhere, and its reliability makes it a solid choice for many situations. Sometimes, the best approach is combining both frameworks to leverage their strengths.

Whichever you choose, focus on building great apps. The tools are just a means to that end.

Coder Legion - Recent posts tagged swiftui

Tap-to-Match Marble Game in SpriteKit and SwiftUI: Physics, Cluster Matching, Lives and Power-Ups

1. Why SpriteKit, and how it fits with SwiftUI

2. A playfield of marbles that settle under physics

3. Tap-to-match: finding the touching cluster

4. Popping with juice

5. A countdown that survives pausing

6. Lives and levels

7. Power-ups: Lightning, Heart and Bomb

8. Real-world example: Marbles Popperz

9. Before you ship a casual game: a checklist

Wrapping up

Offline Quotes App in SwiftUI: 50K-Quote Library, Daily Quote, Streaks and Share-as-Image

1. Ship the library in the bundle, import it once

2. A quote of the day with no server

3. Search across content, author and category, with recent searches

4. Collections and favourites

5. Streaks that survive time zones

6. Share as a beautiful image

7. Light, Dark and Auto, with colour tokens

8. Real-world example: Facts and Quotes

9. Before you ship a content app: a checklist

Wrapping up

Offline eBook Reader for iOS: Downloads, Typography, Reading Progress and Highlights

1. The library model

2. Downloading books, and keeping them out of iCloud backup

3. Preview before downloading

4. A reader with real typography settings

5. Reading progress that survives font changes

6. Bookmarks and highlights, and the iOS 26 text-selection change

7. Reading statistics without surveillance

8. Real-world example: Novels Club

9. Before you ship a reading app: a checklist

Wrapping up

Drag-to-Connect and Game Center Leaderboards in a SwiftUI Puzzle Game, Updated for iOS 26

1. The board as plain data

2. Drawing and ticking with Canvas and TimelineView

3. Drag to connect

4. Scoring speed

5. Signing in to Game Center

6. Submitting scores the modern way

7. Showing leaderboards in iOS 18 and 26

8. Real-world example: Speck Match

9. Before you ship a Game Center game: a checklist

Wrapping up

Tic Tac Toe in SwiftUI, Done Properly: Game State, Win Detection and Minimax AI

1. Why architecture matters even here

2. The model: a board that can't be wrong

3. Testing the rules

4. The view: render state, forward taps

5. Adding a computer opponent: minimax

Making it beatable

6. Real-world example: Tic Tac Toe : Time Pass

7. Before you ship a small game: a checklist

Wrapping up

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Why rebuilding is not a harmless refresh

Separate four lifetimes

Mount once, then deactivate

Preserve the WKWebView object, not necessarily its attachment

Hand focus back before detaching

Freeze hidden geometry

Keep output flowing without flooding the UI

Test transitions, not just steady states

The broader rule

Eunify: Bridging the Continuity Gap Between Mac and Android

I open-sourced 5 tiny SwiftUI utilities I use in every project

1. swiftui-keyboard-avoider

2. swiftui-scroll-offset

3. swiftui-shimmer-loading

4. swiftui-flow-layout

5. ios-appstore-review-link

Your App Goes Offline. Does It Panic, Lie, or Handle It Gracefully?

The Psychology of Offline States

Visual Language for Offline States

Queueing Actions for Later Sync

Showing "Pending" vs "Failed" - Different States Deserve Different Treatment

Auto-Retry with Exponential Backoff

Testing Offline Scenarios

When to Warn Users About Data Loss