Apple Development on entangledDEV

Parsing JSON with Swift

Thu, 23 Oct 2025 03:44:31 +0000

Swift’s Codable APIs make JSON parsing approachable, but real-world payloads often include missing keys, dates, snake_case fields, or constrained enums that deserve stronger typing. This guide captures the patterns I reach for when building production decoders, so future-me has a single reference of best practices and battle-tested examples.

Sample JSON Payload

{
  "id": 42,
  "username": "entangled_dev",
  "display_name": "Entangled Dev",
  "created_at": "2025-10-01T09:42:00Z",
  "is_admin": false,
  "profile": {
    "bio": "Building with Swift and SwiftUI.",
    "website": "https://entangled.dev"
  },
  "favorite_languages": ["Swift", "Rust", "TypeScript"]
}

Create a Codable Model

struct User: Codable {
    let id: Int
    let username: String
    let displayName: String
    let createdAt: Date
    let isAdmin: Bool
    let profile: Profile
    let favoriteLanguages: [String]

    struct Profile: Codable {
        let bio: String
        let website: URL
    }

    enum CodingKeys: String, CodingKey {
        case id
        case username
        case displayName = "display_name"
        case createdAt = "created_at"
        case isAdmin = "is_admin"
        case profile
        case favoriteLanguages = "favorite_languages"
    }
}

CodingKeys let you align Swift’s camelCase with the snake_case keys from the backend, keeping the rest of the code clean.

Decode with JSONDecoder

Assume sampleJSONString is the raw JSON string you received from a network call or fixture.

let jsonData = sampleJSONString.data(using: .utf8)!

let decoder = JSONDecoder()
decoder.keyDecodingStrategy = .convertFromSnakeCase
decoder.dateDecodingStrategy = .iso8601

do {
    let user = try decoder.decode(User.self, from: jsonData)
    print("Loaded user:", user.username)
} catch {
    print("Failed to decode user:", error.localizedDescription)
}

convertFromSnakeCase handles most key conversions automatically. Define explicit CodingKeys when the mapping is more nuanced or when you want control over a single property.

Configure a Shared Decoder

For larger projects, configure JSONDecoder once so the rest of your codebase stays focused on domain logic.

enum Decoders {
    static func api() -> JSONDecoder {
        let decoder = JSONDecoder()
        decoder.keyDecodingStrategy = .convertFromSnakeCase
        decoder.dateDecodingStrategy = .iso8601
        decoder.dataDecodingStrategy = .base64
        decoder.nonConformingFloatDecodingStrategy = .throw
        return decoder
    }
}

Returning a fresh decoder keeps the instance stateless and thread-safe. Keeping the configuration in one place makes it obvious which strategies are in play. If the API delivers milliseconds-since-epoch dates tomorrow, you only have one place to update.

extension JSONDecoder.DateDecodingStrategy {
    static let millisecondsSince1970: JSONDecoder.DateDecodingStrategy = .custom { decoder in
        let container = try decoder.singleValueContainer()
        let milliseconds = try container.decode(Double.self)
        return Date(timeIntervalSince1970: milliseconds / 1000)
    }
}

Swap this strategy in whenever the service moves away from ISO 8601 timestamps.

Handling Optional Data

Use optionals for fields the API might omit and supply sensible defaults.

{
  "id": "F2A0D5C2-3E43-4E58-880E-6BA16AD669E8",
  "title": "Build SwiftUI Layouts Quickly",
  "read_time_minutes": 6
}

struct Article: Codable {
    let id: UUID
    let title: String
    let subtitle: String?
    let readTimeMinutes: Int

    enum CodingKeys: String, CodingKey {
        case id
        case title
        case subtitle
        case readTimeMinutes = "read_time_minutes"
    }
}

let decoder = Decoders.api()
let articleJSON = """
{
  "id": "F2A0D5C2-3E43-4E58-880E-6BA16AD669E8",
  "title": "Build SwiftUI Layouts Quickly",
  "read_time_minutes": 6
}
"""
let data = Data(articleJSON.utf8)
let article = try decoder.decode(Article.self, from: data)
print(article.subtitle ?? "No subtitle provided")

When a key is missing and the property is non-optional, decoding fails. Treat optional values as a contract with the API, annotating properties only when absence is valid.

Supplying Defaults Without Optionals

Sometimes the backend omits a value but you still want a non-optional property. Provide the default inside a custom initializer so callers always receive a fully-formed model.

{
  "enabled": false
}

struct NotificationSettings: Codable {
    let isEnabled: Bool
    let frequency: Frequency

    enum CodingKeys: String, CodingKey {
        case isEnabled = "enabled"
        case frequency
    }

    enum Frequency: String, Codable {
        case immediate, hourly, daily
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        isEnabled = try container.decodeIfPresent(Bool.self, forKey: .isEnabled) ?? true
        frequency = try container.decodeIfPresent(Frequency.self, forKey: .frequency) ?? .daily
    }
}

let settingsJSON = """
{
  "enabled": false
}
"""
let settingsData = Data(settingsJSON.utf8)
let settings = try Decoders.api().decode(NotificationSettings.self, from: settingsData)
print(settings.frequency) // daily

decoder.container(keyedBy:) hands you a keyed view into the JSON object so you can look up multiple fields by CodingKey. Think of it as opening a dictionary-like sub-decoder scoped to the current object. Without grabbing a container, you could only decode a single value at a time, which is fine for simple payloads but breaks down when you need to read several properties and coordinate defaults in one initializer.

Once you have a container, you reach into it with decode(_:forKey:) and decodeIfPresent(_:forKey:). They belong to the container—not JSONDecoder—and are the workhorses for extracting values.

decode(_:forKey:) assumes the value exists and is well-formed, so it either returns the decoded value or throws. Use it when the API contract says “this key is always there.”
decodeIfPresent(_:forKey:) returns nil when the key is missing or explicitly null, letting you fall back to sensible defaults without leaking optionals throughout the call site.

JSONDecoder will automatically assign nil to optional properties when you rely on the synthesized initializer, but only if the property itself is declared optional. In this example frequency is non-optional because the rest of the app expects a real value. Using decodeIfPresent lets you detect a missing key, supply a fallback (.daily), and still keep the property non-optional. If you called decode(_:forKey:) and the key or value was missing, decoding would throw instead of letting you inject a default.

What Happens to `init(from:)`

You never call init(from:) directly. When you ask JSONDecoder to decode a type, it checks whether that type implements init(from:). If it does, the decoder instantiates the Decoder context (containing the key/value containers) and invokes your initializer, passing that context in. If your type has no custom initializer, the compiler synthesizes one automatically. All you do is call decode(_:from:); the Decoder plumbing happens under the hood.

Here is what Decoders.api().decode(NotificationSettings.self, from: settingsData) does behind the scenes:

decode builds a Decoder object with the raw bytes and your global strategies.
The decoder sees NotificationSettings conforms to Decodable, so it calls your init(from:) (or the synthesized one if you didn’t write one).
Inside init(from:), you pull data out of the keyed container and provide defaults.
When the initializer returns, JSONDecoder hands you the fully initialized instance.

So the initializer is “injected,” but only because it’s mandated by the Decodable protocol; the runtime simply honors the implementation you supplied.

Modeling Enumerated Values

APIs often send constrained values that map cleanly to Swift enums. Prefer strongly typed enums over raw String or Int fields so you get compiler guidance and exhaustiveness checking.

1. Direct String Backing

{
  "path": "https://cdn.entangled.dev/images/header.png",
  "type": "png"
}

struct RemoteImage: Codable {
    let path: URL
    let type: ImageType

    enum ImageType: String, Codable {
        case png
        case jpg
        case heic
    }
}

Because ImageType conforms to String and Codable, decoding fails fast when the backend introduces an unexpected value, helping you spot contract changes. When a payload truly allows free-form values, fall back to String or Int; otherwise, rely on enums to keep the domain explicit and safe.

2. Mapping Backend Slugs to Expressive Cases

Sometimes the backend uses values that do not align with Swift naming conventions. When the payload is still a single string, mirror CodingKeys by assigning the raw value directly:

{
  "kind": "profile-picture"
}

enum AvatarKind: String, Codable {
    case profilePicture = "profile-picture"
    case organizationLogo = "organization-logo"
    case systemGenerated = "system-generated"
}

For richer enums that need custom logic during decoding or encoding, map them explicitly while keeping expressive case names.

{
  "path": "https://cdn.entangled.dev/avatars/42.png",
  "kind": "profile-picture"
}

struct Avatar: Codable {
    let path: URL
    let kind: Kind

    enum Kind: Codable {
        case profilePicture
        case organizationLogo
        case systemGenerated

        init(from decoder: Decoder) throws {
            let container = try decoder.singleValueContainer()
            switch try container.decode(String.self) {
            case "profile-picture": self = .profilePicture
            case "organization-logo": self = .organizationLogo
            case "system-generated": self = .systemGenerated
            default: throw DecodingError.dataCorruptedError(in: container, debugDescription: "Unsupported avatar kind")
            }
        }

        func encode(to encoder: Encoder) throws {
            var container = encoder.singleValueContainer()
            switch self {
            case .profilePicture: try container.encode("profile-picture")
            case .organizationLogo: try container.encode("organization-logo")
            case .systemGenerated: try container.encode("system-generated")
            }
        }
    }
}

decoder.singleValueContainer() is what you reach for when the JSON fragment you’re decoding is literally just a single primitive (a string, number, or bool) instead of an object with keys. Without it, you’d be forced to introduce fake CodingKeys or wrap the value in another type just to read it. The single-value container hands you that raw value directly so you can convert it into an enum case (or any other type) in one step. encoder.singleValueContainer() mirrors the idea when writing JSON, ensuring the enum encodes back to the original one-value payload.

Why does this work when the parent JSON (Avatar) also has a path key? JSONDecoder handles the outer object first. It builds a keyed container for Avatar, decodes path, and when it reaches kind it delegates to Kind.init(from:). That delegate initializer receives a nested decoder that already points at the "kind" value, so singleValueContainer() sees only that scalar string—"profile-picture"—instead of the whole object. Containers are scoped, so they never “see” sibling keys; the keyed container for Avatar keeps walking properties one-by-one.

switch try container.decode(String.self) then decodes the underlying string (throwing if it is missing or malformed) and immediately pattern-matches on the result. Each case maps the backend slug to the right Swift case, while the default branch surfaces unsupported values. This syntax keeps the decode + mapping logic tight and ensures the initializer exits once it finds a match.

func encode(to encoder: Encoder) is the flip side of init(from:). Conforming to Codable implicitly means conforming to both Decodable and Encodable; implementing this method lets you control how the enum (or struct) writes back to JSON when you call JSONEncoder().encode(...).

3. Capturing Unknown Cases

If you need to keep the app resilient while still flagging surprises, add an unknown case that stashes the raw value for logging.

enum ImageType: Codable {
    case png
    case jpg
    case heic
    case unknown(String)

    init(from decoder: Decoder) throws {
        let value = try decoder.singleValueContainer().decode(String.self)
        switch value {
        case "png": self = .png
        case "jpg": self = .jpg
        case "heic": self = .heic
        default: self = .unknown(value)
        }
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        switch self {
        case .png: try container.encode("png")
        case .jpg: try container.encode("jpg")
        case .heic: try container.encode("heic")
        case .unknown(let raw): try container.encode(raw)
        }
    }
}

This approach guards you against backends that silently add new types while preserving diagnostics for analytics or crash logs. You can combine it with the explicit mapping technique above by routing the default branch to .unknown(value) instead of throwing.

Custom Decoding Logic

For more complex transformations, implement init(from:).

{
  "accent_color": "FF0080"
}

struct Color: Codable {
    let red: Double
    let green: Double
    let blue: Double

    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let hex = try container.decode(String.self)

        guard let rgb = Int(hex, radix: 16) else {
            throw DecodingError.dataCorruptedError(
                in: container,
                debugDescription: "Expected a hex string like FF0080"
            )
        }

        red = Double((rgb >> 16) & 0xFF) / 255
        green = Double((rgb >> 8) & 0xFF) / 255
        blue = Double(rgb & 0xFF) / 255
    }
}

let colorJSON = """
{
  "accent_color": "FF0080"
}
"""
let accent = try Decoders.api().decode([String: Color].self, from: Data(colorJSON.utf8))
print(accent["accent_color"]?.red ?? 0)

Here the payload is a hex string ("FF0080") and the decoder must convert it into normalized color components. Throwing a DecodingError produces actionable diagnostics during development.

Decoding Polymorphic Payloads

When APIs send unions (one of several shapes under the same key), model them with enums that have associated values.

{
  "attachments": [
    { "type": "image", "url": "https://cdn.entangled.dev/image.png", "width": 640, "height": 480 },
    { "type": "file", "name": "report.pdf", "size_bytes": 10240 },
    { "type": "code", "language": "swift", "snippet": "print(\"Hello\")" }
  ]
}

enum Attachment: Codable {
    case image(Image)
    case file(File)
    case code(Code)

    struct Image: Codable {
        let url: URL
        let width: Int
        let height: Int
    }

    struct File: Codable {
        let name: String
        let sizeBytes: Int
    }

    struct Code: Codable {
        let language: String
        let snippet: String
    }

    private enum CodingKeys: String, CodingKey {
        case type
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let type = try container.decode(String.self, forKey: .type)
        switch type {
        case "image":
            self = .image(try Image(from: decoder))
        case "file":
            self = .file(try File(from: decoder))
        case "code":
            self = .code(try Code(from: decoder))
        default:
            throw DecodingError.dataCorruptedError(
                forKey: .type,
                in: container,
                debugDescription: "Unsupported attachment type: \(type)"
            )
        }
    }
}

Using enums keeps the call site type-safe. A switch on Attachment forces you to handle every variant and lets you opt in to unknown-case strategies where appropriate.

Mapping Nested Collections

When the API wraps arrays under a key, decode them via nested containers.

{
  "data": {
    "articles": [
      { "id": "1", "title": "Swift Strings 101", "read_time_minutes": 4 },
      { "id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7 }
    ]
  }
}

struct FeedResponse: Decodable {
    let articles: [Article]

    enum CodingKeys: String, CodingKey {
        case data
    }

    enum DataKeys: String, CodingKey {
        case articles
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let dataContainer = try container.nestedContainer(keyedBy: DataKeys.self, forKey: .data)
        articles = try dataContainer.decode([Article].self, forKey: .articles)
    }
}

Nested containers keep your models minimal while handling payload structures that mirror database responses or GraphQL-style edges.

If the nested payload carries multiple fields you care about, decode each sibling from the same container.

{
  "data": {
    "articles": [
      { "id": "1", "title": "Swift Strings 101", "read_time_minutes": 4 },
      { "id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7 }
    ],
    "other_property": "some value",
    "featured_article": { "id": "3", "title": "Concurrency Deep Dive", "read_time_minutes": 12 }
  }
}

struct RichFeedResponse: Decodable {
    let articles: [Article]
    let featured: Article?
    let otherProperty: String

    enum CodingKeys: String, CodingKey { case data }

    enum DataKeys: String, CodingKey {
        case articles
        case featuredArticle = "featured_article"
        case otherProperty = "other_property"
    }

    init(from decoder: Decoder) throws {
        let container = try decoder.container(keyedBy: CodingKeys.self)
        let dataContainer = try container.nestedContainer(keyedBy: DataKeys.self, forKey: .data)
        articles = try dataContainer.decode([Article].self, forKey: .articles)
        featured = try dataContainer.decodeIfPresent(Article.self, forKey: .featuredArticle)
        otherProperty = try dataContainer.decode(String.self, forKey: .otherProperty)
    }
}

Nested containers behave like scoped dictionaries; once you have one, read every relevant key—required or optional—before you leave it.

Integrating with Legacy `[String: Any]` Stores

Some codebases funnel network payloads through a store that already parses JSON into [String: Any]. You can still lean on your Codable models instead of hand-casting dictionaries.

let storePayload: [String: Any] = [
    "data": [
        "articles": [
            ["id": "1", "title": "Swift Strings 101", "read_time_minutes": 4],
            ["id": "2", "title": "Macros in Swift 5.9", "read_time_minutes": 7]
        ],
        "other_property": "some value"
    ]
]

func decodeFeed(from payload: [String: Any]) throws -> RichFeedResponse {
    guard JSONSerialization.isValidJSONObject(payload) else {
        throw NSError(domain: "Store", code: 0, userInfo: [NSLocalizedDescriptionKey: "Invalid JSON object"])
    }

    let data = try JSONSerialization.data(withJSONObject: payload)
    return try Decoders.api().decode(RichFeedResponse.self, from: data)
}

Converting back to Data lets you reuse the same decoders and validation logic while keeping the legacy store untouched. If you truly need to stay in dictionary space, encapsulate the nested lookups in a helper so the casting is localized.

func articles(from payload: [String: Any]) throws -> [[String: Any]] {
    guard
        let data = payload["data"] as? [String: Any],
        let articles = data["articles"] as? [[String: Any]]
    else {
        throw NSError(domain: "Store", code: 1, userInfo: [NSLocalizedDescriptionKey: "Articles missing"])
    }
    return articles
}

The dictionary approach works, but it is fragile: missing keys collapse to nil, spelling mistakes slip through, and you duplicate parsing logic everywhere you need the data. Wrapping that plumbing in a helper at least centralizes the risk, but re-encoding to Data and letting Codable handle validation buys you type safety, better diagnostics, and parity with the rest of the codebase. Start with the helper as a stopgap, then migrate callers to the Codable path.

articles ends up as [[String: Any]] because every element of the JSON articles array is a JSON object ({ ... }). When bridged to Swift without a model, each object becomes a [String: Any] dictionary containing the article’s fields ("id", "title", "read_time_minutes", and so on). The surrounding array just preserves the list of those dictionaries until you map them into strong types.

Surface Decoding Errors Clearly

DecodingError carries rich context. Pattern-match on it to log actionable diagnostics instead of generic “data corrupted” messages.

func log(_ error: Error) {
    switch error {
    case DecodingError.keyNotFound(let key, let context):
        print("Missing key \(key.stringValue):", context.debugDescription)
    case DecodingError.typeMismatch(let type, let context):
        print("Type mismatch for \(type):", context.debugDescription)
    case DecodingError.valueNotFound(let type, let context):
        print("Expected value for \(type):", context.debugDescription)
    case DecodingError.dataCorrupted(let context):
        print("Data corrupted:", context.debugDescription)
    default:
        print("Unexpected error:", error.localizedDescription)
    }
}

Attach decoded context, request identifiers, or user IDs to this logging to make server/client contracts easier to debug.

Decoding with Swift Concurrency

func loadUser(from url: URL) async throws -> User {
    let (data, _) = try await URLSession.shared.data(from: url)
    return try Decoders.api().decode(User.self, from: data)
}

By returning the decoded type directly, your async functions stay composable. Propagating thrown errors lets the caller decide whether to retry, show an alert, or load fallback data. Pass the decoder in as an argument when you want to override strategies (e.g., JSON with UNIX timestamps).

Testing Your Decoders

Decode against local fixtures in unit tests to assert that the models match the API contract.

func testUserDecoding() throws {
    let bundle = Bundle.module
    let url = try XCTUnwrap(bundle.url(forResource: "user_fixture", withExtension: "json"))
    let data = try Data(contentsOf: url)
    let decoder = Decoders.api()

    let user = try decoder.decode(User.self, from: data)
    XCTAssertEqual(user.favoriteLanguages.count, 3)
    XCTAssertEqual(user.profile.website.host, "entangled.dev")
}

Testing with captured payloads surfaces breaking changes early and documents assumptions about optional versus required fields.

Wrap Up

Swift’s Codable ecosystem covers the majority of JSON parsing scenarios: adopt Decodable models, configure JSONDecoder centrally, lean on enums for constrained values, and reach for custom initializers when you need defaults or polymorphism. Combine these patterns with targeted logging and fixture-based tests to keep API integrations resilient and easy to reason about.

Handling Touch Gestures in UIKit

Sat, 21 Jun 2025 00:14:26 -0600

Hey everyone! In this post, I want to talk about how we can add and manage different gestures in UIKit. This post will be updated as I explore more gesture interactions. When needed, I’ll also touch on accessibility considerations, especially for VoiceOver.

Long Press Gesture

UIKit handles long press gestures using a class called UILongPressGestureRecognizer. You can attach it to any UIView using the addGestureRecognizer() method.

With UILongPressGestureRecognizer, you can configure:

The action that will be executed (this method must be marked with @objc),
The required duration before the gesture triggers,
And other options, which you can explore through the class’s available properties and methods.

Gesture States

The UILongPressGestureRecognizer can be in one of several states:

.possible: The default state before the gesture has been recognized.
.began: The gesture has met the minimum duration and has started.
.changed: The user’s finger has moved while still pressing.
.ended: The user has lifted their finger, ending the gesture.
.cancelled: The system canceled the gesture (e.g., an interruption).
.failed: The gesture didn’t meet the criteria for recognition.

Example

Here is a simple example of a label with an attached long press gesture recognizer:

import UIKit

class ViewController: UIViewController {
    
    private lazy var label: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Hello, World!"
        label.textAlignment = .center
        label.font = .systemFont(ofSize: 24, weight: .medium)
        label.isUserInteractionEnabled = true // Required to detect gestures on the label
        return label
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        setupUI()
        setupLongPressGesture(for: label)
    }
}

private extension ViewController {
    func setupUI() {
        view.backgroundColor = .systemBackground
        
        view.addSubview(label)
        NSLayoutConstraint.activate([
            label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            label.centerYAnchor.constraint(equalTo: view.centerYAnchor),
        ])
    }
    
    func setupLongPressGesture(for view: UIView) {
        let recognizer = UILongPressGestureRecognizer(target: self, action: #selector(handleLongPress))
        recognizer.minimumPressDuration = 0.5 // Customize duration if needed
        view.addGestureRecognizer(recognizer)
    }
    
    @objc func handleLongPress(_ gesture: UILongPressGestureRecognizer) {
        switch gesture.state {
        case .began:
            label.text = "Long press!"
        case .ended:
            label.text = "Hello, World!"
        default:
            break
        }
    }
}

This is a great starting point for adding more complex gestures or chaining interactions. In future updates, I’ll cover tap gestures, swipes, and how to handle VoiceOver interactions effectively.

Thanks for reading!

State Driven Enum Navigation

Sun, 06 Apr 2025 07:43:36 -0600

Navigating SwiftUI with an Enum Router (Cyclical A → B → C Flow) — A Simple example

Introduction

In this post, we’ll explore a lightweight, type‑safe way to manage navigation in SwiftUI by modelling screens as an enum and driving transitions with closures. We’ll illustrate a simple cyclical flow through three views—A → B → C → A—and then dive into the pros and cons of this approach.

1. Defining the Router State

First, we define an enum with three cases—one for each screen. This enum is our “single source of truth” for navigation state:

// Represents each screen in our app.
enum AppScreen {
    case viewA
    case viewB(someData: String) // We can pass values to next screens
    case viewC
}

2. The Router Protocol & Default Implementation

Next, we encapsulate navigation logic in a router object. Here’s a minimal protocol and default router using @Observable (iOS 17+), so SwiftUI updates automatically when currentScreen changes:

import Observation

protocol AppRouter {
    var currentScreen: AppScreen { get }
    func navigate(to screen: AppScreen)
}

@Observable
final class DefaultAppRouter: AppRouter {
    private(set) var currentScreen: AppScreen = .viewA
    
    func navigate(to screen: AppScreen) {
        currentScreen = screen
    }
}

We centralise navigation in one SwiftUI container. It switches over router.currentScreen and injects closures into each view to advance the flow cyclically:

import SwiftUI

struct CyclicalNavigationView: View {
    @State private var router = DefaultAppRouter()
    
    var body: some View {
        content
    }
    
    @ViewBuilder
    private var content: some View {
        switch router.currentScreen {
        case .viewA:
            ViewA { receivedData in // We capture the data send by ViewA.
                // We send the data to ViewB using the router.
                router.navigate(to: .viewB(someData: receivedData))
            }
        // We get the data from previous state and inject it when creating ViewB.
        case .viewB(let someData):
            ViewB(dataFromViewA: someData) {
                router.navigate(to: .viewC)
            }
        case .viewC:
            ViewC {
                router.navigate(to: .viewA)
            }
        }
    }
}

4. The Three Views

Each view is oblivious to the overall navigation logic—it simply calls its onNext closure when the user taps a button:

struct ViewA: View {
    let onNext: (String) -> Void // The closure receives tha data we want to pass to the next state.
    
    var body: some View {
        VStack {
            Text("View A")
            Button("Go to B") {
                // We pass data to next state using the closure argument.
                onNext("some Data from screen A")
            }
        }
    }
}

struct ViewB: View {
    // We optionally received some data from the router previous state.
    let dataFromViewA: String?
    let onNext: () -> Void
    
    var body: some View {
        VStack {
            Text("View B")
                .font(.title)
            if let dataFromViewA {
                Text(dataFromViewA)
                    .font(.caption)
            }
            Button("Go to C", action: onNext)
        }
    }
}

struct ViewC: View {
    let onNext: () -> Void
    
    var body: some View {
        VStack {
            Text("View C")
            Button("Go to A", action: onNext)
        }
    }
}

5. How It Works

Initial State The router starts at .viewA, so ViewA is presented.
Advancing Tapping “Go to B” calls router.navigate(to: .viewB), updating currentScreen. SwiftUI recomputes the switch and shows ViewB. Optionally if data must be shared or passed, we can use associated values and closure arguments to pass the data between states.
Cyclical Flow Similarly, B → C and C → A form a loop. There’s no back‑stack—each transition replaces the current screen.

Here is the navigation working:

6. Pros and Cons

Pros:

This enum‑and‑closure router is completely type‑safe and exhaustive—every possible screen must be handled in your switch, so you’ll never accidentally forget a case. All of your navigation state lives in one place, making it easy to reason about where the app is and simple to write unit tests against your navigate(to:) calls. Because each view only knows about its own onNext closure, your views stay decoupled from routing details and remain highly reusable. You can also test the router in isolation—just invoke navigate(to:) and assert that currentScreen changes as expected. Finally, modelling screens as an enum feels very “functional,” with no magic strings or identifiers floating around.

Cons:

On the flip side, there’s no built‑in history or back‑stack: each transition outright replaces the current screen, so if you need “go back” behaviour you’ll have to roll your own stack. You also miss out on SwiftUI’s native push/pop animations and swipe‑back gestures, unless you add transitions manually or switch to NavigationStack. As your app grows, the central switch can become large and repetitive, leading to boilerplate that’s harder to maintain. Supporting deep‑linking or state restoration means you must write custom serialization for your enum state. And finally, this pattern is best suited to single, linear (or cyclical) flows—if you have branching paths, modals or nested stacks, you’ll likely need a more sophisticated coordinator.

7. Conclusion

This enum‑and‑closure router shines for simple, linear or cyclical flows. It’s clear, type‑safe and easy to test. However, if you need: • A back‑stack with swipe‑back animations • Deep‑linking or state‑restoration support • Complex branching or modal flows

you might migrate to SwiftUI’s NavigationStack (iOS 16+) or adopt a more full‑featured coordinator. For many lightweight apps—like our A → B → C cycle—this pattern is both elegant and practical.

SwiftUI Generic Containers

Sun, 06 Apr 2025 05:20:12 -0600

Want to make your SwiftUI views more reusable, composable, and clean?
This post explores how to build your own generic containers using Swift’s type system and SwiftUI’s powerful @ViewBuilder + closure patterns.

Whether you’re building custom layouts, DSL-like preview wrappers, or logic-driven composition — understanding generic containers is a key unlock.

💡 SwiftUI Tip: Wrapping Views with Generics and Closures

I recently hit a situation in SwiftUI that seemed small at first — but led to a mini “aha!” moment about closures, generics, and how SwiftUI composes views.

This is one of those tricks that’s easy to overlook until you need it — but once it clicks, it unlocks a whole new layer of composability.

🚧 The Problem

I wanted to create a wrapper for SwiftUI previews — one that adds common styling like background color and full-frame layout, so I wouldn’t have to repeat this over and over:

#Preview {
    VStack {
        MyCoolView()
    }
    .frame(maxWidth: .infinity, maxHeight: .infinity)
    .appBackground()
}

Simple enough, right?

So I tried to create a wrapper like this:

struct PreviewWrapperView: View {
    let content: some View // ❌ Error!
    
    var body: some View {
        VStack {
            content
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .appBackground()
    }
}

But Swift gave me the error:

“Property declares an opaque return type, but has no initializer expression…”

🔍 The Fix: Use a Generic + Closure

Swift doesn’t allow some View as a stored property type — it only works for return values.

The correct pattern looks like this:

struct PreviewWrapperView<Content>: View where Content: View {
    @ViewBuilder let content: () -> Content

    var body: some View {
        VStack {
            content()
        }
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .appBackground()
    }
}

And then you use it like this:

#Preview {
    PreviewWrapperView {
        MyCoolView(param: 123)
    }
}

🤯 But wait — doesn’t `MyCoolView(param: 123)` need a closure like `(Int) -> some View`?

This was the part that clicked for me.

No.
You’re not passing MyCoolView as a function.
You’re calling it inside the closure, and returning the result.

That means you’re passing a closure like:

() -> MyView

Which matches () -> Content just fine.

🧠 What this unlocked for me

I realized this pattern is everywhere in SwiftUI:

NavigationStack { ... }
Section(header: Text("...")) { ... }
Button { ... } label: { ... }

Once you know how to create your own view wrapper using a generic and a closure, you can build anything from:

DSL-style layout containers
Reusable environment-aware wrappers
Onboarding and modal flows
Themed previews
Stylized layout shells with safe areas, animations, shadows…

🧪 Bonus: Custom Layout Containers

Now that you understand how to use closures and generics to wrap views, here’s a real-world way to apply this pattern for styling and layout reuse.

Let’s say you want a layout that wraps your screen content in consistent padding, background, and spacing — and optionally adds a footer.

At first, you might be tempted to make the footer closure optional, or try to hack it using AnyView or Footer? tricks. But there’s a cleaner, more Swifty way — and it’s the way Apple does it too.

Instead of creating multiple types, Apple defines multiple initializers in the same struct — and we can do the same.

Here is the wrapper using all we have learned today!

struct StyledScreen<Content: View, Footer: View>: View {
    let content: Content
    let footer: Footer?

    init(
        @ViewBuilder content: () -> Content
    ) where Footer == EmptyView {
        self.content = content()
        self.footer = nil
    }

    init(
        @ViewBuilder content: () -> Content,
        @ViewBuilder footer: () -> Footer
    ) {
        self.content = content()
        self.footer = footer()
    }

    var body: some View {
        VStack(spacing: 24) {
            content
                .padding()
                .background(Color.secondary.opacity(0.1))
                .cornerRadius(12)

            if let footer = footer {
                footer
                    .padding(.top, 32)
            }
        }
        .padding()
        .overlay(
            RoundedRectangle(cornerRadius: 16)
                .stroke(.gray.opacity(0.3), style: StrokeStyle(lineWidth: 1, dash: [6]))
        )
        .frame(maxWidth: .infinity, maxHeight: .infinity)
        .background(Color(.systemBackground))
    }
}

📦 Usage

#Preview {
    VStack {
        // With no footer
        StyledScreen {
            Text("No footer")
        }
        
        // With footer
        StyledScreen {
            Text("Has a footer")
        } footer: {
            Button("Continue") { }
        }
    }
}

This version matches Apple’s API design philosophy.

Here is the result:

🤔 What’s up with `where Footer == EmptyView`?

This line:

init(@ViewBuilder content: () -> Content) where Footer == EmptyView

might look strange at first — but it’s key to enabling a clean, SwiftUI-style API.

💡 Why it exists:

Our StyledScreen struct uses two generics:

struct StyledScreen<Content: View, Footer: View>

That means Swift needs to know both types — even if the user doesn’t explicitly pass a footer.

If we don’t specify what Footer is, Swift will throw an error like:

“Cannot infer generic parameter ‘Footer’ without more context”

To fix that, we say:

“If the user only provides content, then assume Footer == EmptyView.”

This satisfies the compiler and lets us write:

StyledScreen {
    Text("Hello")
}

Without needing to manually pass an EmptyView.

This pattern is used inside SwiftUI itself — like in NavigationLink, Button, and Section — to support clean, overloaded initializers while keeping everything fully type-safe.

📦 TL;DR

Use Content: View + () -> Content to pass view content into your wrapper
Use @ViewBuilder if you want to support multiple children
Don’t try to store some View — use a closure instead
This unlocks powerful layout composition in SwiftUI

✨ Hope this helped someone else!
If you’ve used this pattern in an interesting way, or have a cool layout abstraction — let me know! I’d love to see what you’re building.

Working With Collections

Sun, 09 Jun 2024 12:17:07 +0000

Welcome to another installment of UIKit Learning! Today, we will dive into UICollectionView and explore how to use it effectively in your iOS apps.

A UICollectionView is a versatile and powerful component in UIKit that allows you to present a grid or list of items in a highly customizable layout. Whether you need a simple grid of images, a complex layout with multiple sections and headers, or dynamic, animated updates, UICollectionView provides the flexibility to create engaging user interfaces.

We’ll start with a minimal example and gradually build up to more complex scenarios, using the latest best practices and features, including diffable data sources (a favorite of mine).

Setting Up a Minimal UICollectionView

Creating the base view controller

As usual, we’re going to approach our development programmatically, so you can refer to my post on setting up a programmatic UIKit project.

Let’s start by creating a new file called ViewController.swift and add the following code.

import UIKit

class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

This is the minimal view controller we are going to use to display the collection.

We are using this controller as the root ViewController for window in Scene Delegate.

Adding the collection to the view

Now it’s time to add our UICollectionView, inside the ViewController add the following property.

import UIKit

class ViewController: UIViewController {

    private var collectionView: UICollectionView! // add this

    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

Next, let’s configure the collection, by adding and calling a configure function.

class ViewController: UIViewController {

    private var collectionView: UICollectionView!

    override func viewDidLoad() {
        super.viewDidLoad()
        setupCollectionView() // 2. call the function
    }

    // 1. create this function
    func setupCollectionView() {
        // Creating layout
        let layout = UICollectionViewFlowLayout()
        layout.itemSize = CGSize(width: 100, height: 100)
        layout.sectionInset = UIEdgeInsets(top: 10, left: 10, bottom: 10, right: 10)
        layout.scrollDirection = .horizontal
        
        // creating actual collection
        collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout)
        collectionView.backgroundColor = .darkGray
        
        // adding to view
        view.addSubview(collectionView)
        
        // adding constraints
        collectionView.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            collectionView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            collectionView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
            collectionView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
            collectionView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor)
        ])
    }
}

This functions creates the actual collection and the layout for the collection.

Why we need a `collectionViewLayout`

When working with UICollectionView, you need to provide a layout object that determines how the items in the collection view are arranged.

UICollectionViewFlowLayout is a concrete layout object that organizes items into a grid with optional header and footer views for each section. It’s the most commonly used layout class because it provides a lot of built-in functionality that suits many common use cases.

UICollectionView does not come with a default layout. You must provide a layout object for it to work. UICollectionViewFlowLayout is the default layout provided by UIKit that supports basic grid-like arrangements.

Adding the data source

Our collection is already created with a basic layout but we need to have actual data to make it display any information, to solve this problem we could implement the UICollectionViewDataSource but I prefer to use a diffable data source.

What’s a diffable data source

A diffable data source is a modern way to manage the data in your collection views and table views. It makes it easier to update your UI when your data changes, ensuring smooth and efficient updates without having to manually calculate the differences between the old and new data.

In simple terms, you provide the entire set of new data to the data source using a snapshot, then the data source internally manages the update without any intervention from the user. A snapshot is like a picture of your data at a particular moment.

Creating the diffable data source

Inside the class let’s create a new property called dataSource.

class ViewController: UIViewController {

    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>! // add this

    // More code ...

The provided types are for the section identifier and the actual data our collection will display, in our case we are using Int as the section identifier and String as the data we want to display. We could use any custom types as long as they are valid for the role.

Configuring the data source

The next step is crucial for our collection to work, we need to configure how the cells will be updated and we need to register the collection in our data source.

Let’s add the following function to our class

class ViewController: UIViewController {
    // more code ...

    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource() // 2. call the function
    }

    // 1. create the function
    private func setupDataSource() {
            // configuring cell with diffable data source
            collectionView.register(CustomCollectionCell.self, forCellWithReuseIdentifier: CustomCollectionCell.name)
            
            // configure cell update
            dataSource = UICollectionViewDiffableDataSource(collectionView: collectionView) { collectionView, indexPath, name in
                guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: CustomCollectionCell.name, for: indexPath) as? CustomCollectionCell else { fatalError("Unable to dequeue CustomCollectionCell") }
                cell.backgroundColor = .orange
                cell.update(with: name)
                return cell
            }
        }

        // more code ...
}

First, we are registering the cell we are going to use in our collection.

Next, creating the diffable data source and passing the reference to our collection. By doing this we are telling our data source the collection it will be managing.

The closure we are passing tells the data source how the update of each cell will be managed. Inside the closure we have access to the actual collection, the indexPath of the current element and the actual data element we want to display inside the cell.

By doing these simple steps we have our collection connected with its data source.

Creating the snapshot

Finally we need a way to update the collection data, to do this let’s add a new function that will handle the snapshot.

class ViewController: UIViewController {
    // more code ...

    // updating the diffable with new data
    func updateSnapshot(with data: [String]) {
        var snapshot = NSDiffableDataSourceSnapshot<Int, String>()
        snapshot.appendSections([0])
        snapshot.appendItems(data) // Adding more items
        dataSource.apply(snapshot, animatingDifferences: true)
    }

    // more code ...
}

This function creates a snapshot and applies the new data to the underlying system that will automatically updates the collection for us.

If your collection wants to show different data, you need to update the snapshot and the data source to be compatible. The data source and snapshot must be of the same type to work.

Creating a custom cell

By default, collection cell doesn’t have text or other elements, so let’s create a custom cell we can reuse in our collection. You already register this cell for the collection and you’re already using it in the data source. It’s a simple cell that only shows a centered label.

final class CustomCollectionCell: UICollectionViewCell {
    static let name = "CustomCollectionCell"
    
    private var label: UILabel!
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLabel()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func update(with data: String) {
        label.text = data
    }
    
    private func setupLabel() {
        label = UILabel()
        label.textAlignment = .center
        
        self.contentView.addSubview(label) // remember to add it to the contentView
        
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.topAnchor.constraint(equalTo: contentView.topAnchor), // we are referring to contentView not view
            label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), // we are referring to contentView not view
            label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), // we are referring to contentView not view
            label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), // we are referring to contentView not view
        ])
    }
}

In cells you need to add sub elements to the contentView not the view.

Testing the collection

Let’s test the collection. We need some data to show, here is some data you can add to your class.

class ViewController: UIViewController {
    
    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>!
    
    private var mockData: [String] {
        [
            "Bulbasaur", "Ivysaur", "Venusaur", "Charmander", "Charmeleon", "Charizard",
            "Squirtle", "Wartortle", "Blastoise", "Caterpie", "Metapod", "Butterfree",
            "Weedle", "Kakuna", "Beedrill", "Pidgey", "Pidgeotto", "Pidgeot",
            "Rattata", "Raticate", "Spearow", "Fearow", "Ekans", "Arbok",
            "Pikachu", "Raichu", "Sandshrew", "Sandslash", "Nidoran♀", "Nidorina",
            "Nidoqueen", "Nidoran♂", "Nidorino", "Nidoking", "Clefairy", "Clefable",
            "Vulpix", "Ninetales", "Jigglypuff", "Wigglytuff", "Zubat", "Golbat",
            "Oddish", "Gloom", "Vileplume", "Paras", "Parasect", "Venonat", "Venomoth",
            "Diglett", "Dugtrio", "Meowth", "Persian", "Psyduck", "Golduck",
            "Mankey", "Primeape", "Growlithe", "Arcanine", "Poliwag", "Poliwhirl",
            "Poliwrath", "Abra", "Kadabra", "Alakazam", "Machop", "Machoke", "Machamp",
            "Bellsprout", "Weepinbell", "Victreebel", "Tentacool", "Tentacruel",
            "Geodude", "Graveler", "Golem", "Ponyta", "Rapidash", "Slowpoke",
            "Slowbro", "Magnemite", "Magneton", "Farfetch'd", "Doduo", "Dodrio",
            "Seel", "Dewgong", "Grimer", "Muk", "Shellder", "Cloyster",
            "Gastly", "Haunter", "Gengar", "Onix", "Drowzee", "Hypno",
            "Krabby", "Kingler", "Voltorb", "Electrode", "Exeggcute", "Exeggutor",
            "Cubone", "Marowak", "Hitmonlee", "Hitmonchan", "Lickitung", "Koffing",
            "Weezing", "Rhyhorn", "Rhydon", "Chansey", "Tangela", "Kangaskhan",
            "Horsea", "Seadra", "Goldeen", "Seaking", "Staryu", "Starmie",
            "Mr. Mime", "Scyther", "Jynx", "Electabuzz", "Magmar", "Pinsir",
            "Tauros", "Magikarp", "Gyarados", "Lapras", "Ditto", "Eevee",
            "Vaporeon", "Jolteon", "Flareon", "Porygon", "Omanyte", "Omastar",
            "Kabuto", "Kabutops", "Aerodactyl", "Snorlax", "Articuno", "Zapdos",
            "Moltres", "Dratini", "Dragonair", "Dragonite", "Mewtwo", "Mew"
        ]
    }

    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource()
        updateSnapshot(with: mockData) // call the update and pass the data
    }

    // more code ...

Pass the data to the snapshot and run the code, you should see your data in the collection.

It should looks and behaves like the video above.

Conclusion

Congratulations! You’ve successfully set up a UICollectionView using a diffable data source and a custom cell, all programmatically. By following this tutorial, you now understand the basics of UICollectionView and how to leverage diffable data sources to manage your data efficiently. This approach not only simplifies your code but also ensures smooth and animated updates to your collection view.

In this post, we’ve covered:

Creating a minimal view controller and adding a UICollectionView to it.
Setting up a layout using UICollectionViewFlowLayout.
Understanding the importance of a layout object for UICollectionView.
Implementing a diffable data source to manage and update your collection view data.
Creating and registering a custom cell to display text within your collection view.

With these foundational concepts in place, you’re well-equipped to build more complex and dynamic collection views in your iOS apps. Whether you’re displaying a grid of images, a list of text items, or something entirely custom, UICollectionView and diffable data sources provide the flexibility and power you need.

Stay tuned for more in our UIKit Learning series, where we’ll dive deeper into advanced topics and best practices. Happy coding!

Apendix

Here is the full code.

import UIKit

class ViewController: UIViewController {
    
    private var collectionView: UICollectionView!
    private var dataSource: UICollectionViewDiffableDataSource<Int, String>!
    
    private var mockData: [String] {
        [
            "Bulbasaur", "Ivysaur", "Venusaur", "Charmander", "Charmeleon", "Charizard",
            "Squirtle", "Wartortle", "Blastoise", "Caterpie", "Metapod", "Butterfree",
            "Weedle", "Kakuna", "Beedrill", "Pidgey", "Pidgeotto", "Pidgeot",
            "Rattata", "Raticate", "Spearow", "Fearow", "Ekans", "Arbok",
            "Pikachu", "Raichu", "Sandshrew", "Sandslash", "Nidoran♀", "Nidorina",
            "Nidoqueen", "Nidoran♂", "Nidorino", "Nidoking", "Clefairy", "Clefable",
            "Vulpix", "Ninetales", "Jigglypuff", "Wigglytuff", "Zubat", "Golbat",
            "Oddish", "Gloom", "Vileplume", "Paras", "Parasect", "Venonat", "Venomoth",
            "Diglett", "Dugtrio", "Meowth", "Persian", "Psyduck", "Golduck",
            "Mankey", "Primeape", "Growlithe", "Arcanine", "Poliwag", "Poliwhirl",
            "Poliwrath", "Abra", "Kadabra", "Alakazam", "Machop", "Machoke", "Machamp",
            "Bellsprout", "Weepinbell", "Victreebel", "Tentacool", "Tentacruel",
            "Geodude", "Graveler", "Golem", "Ponyta", "Rapidash", "Slowpoke",
            "Slowbro", "Magnemite", "Magneton", "Farfetch'd", "Doduo", "Dodrio",
            "Seel", "Dewgong", "Grimer", "Muk", "Shellder", "Cloyster",
            "Gastly", "Haunter", "Gengar", "Onix", "Drowzee", "Hypno",
            "Krabby", "Kingler", "Voltorb", "Electrode", "Exeggcute", "Exeggutor",
            "Cubone", "Marowak", "Hitmonlee", "Hitmonchan", "Lickitung", "Koffing",
            "Weezing", "Rhyhorn", "Rhydon", "Chansey", "Tangela", "Kangaskhan",
            "Horsea", "Seadra", "Goldeen", "Seaking", "Staryu", "Starmie",
            "Mr. Mime", "Scyther", "Jynx", "Electabuzz", "Magmar", "Pinsir",
            "Tauros", "Magikarp", "Gyarados", "Lapras", "Ditto", "Eevee",
            "Vaporeon", "Jolteon", "Flareon", "Porygon", "Omanyte", "Omastar",
            "Kabuto", "Kabutops", "Aerodactyl", "Snorlax", "Articuno", "Zapdos",
            "Moltres", "Dratini", "Dragonair", "Dragonite", "Mewtwo", "Mew"
        ]
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        setupView()
        setupCollectionView()
        setupDataSource()
        updateSnapshot(with: mockData)
    }
    
    
}

private extension ViewController {
    
    func setupView() {
        view.backgroundColor = .systemBackground
    }
    
    func setupCollectionView() {
        // Creating layout
        let layout = UICollectionViewFlowLayout()
        layout.itemSize = CGSize(width: 100, height: 100)
        layout.sectionInset = UIEdgeInsets(top: 10, left: 10, bottom: 10, right: 10)
        layout.scrollDirection = .horizontal
        
        // creating actual collection
        collectionView = UICollectionView(frame: .zero, collectionViewLayout: layout)
        collectionView.backgroundColor = .darkGray
        
        // adding to view
        view.addSubview(collectionView)
        
        // adding constraints
        collectionView.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            collectionView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            collectionView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor),
            collectionView.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor),
            collectionView.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor)
        ])
    }
    
    func setupDataSource() {
        // registering cell to the collection
        collectionView.register(CustomCollectionCell.self, forCellWithReuseIdentifier: CustomCollectionCell.name)
        
        // creating and configuring diffable data source
        dataSource = UICollectionViewDiffableDataSource(collectionView: collectionView) { collectionView, indexPath, name in
            guard let cell = collectionView.dequeueReusableCell(withReuseIdentifier: CustomCollectionCell.name, for: indexPath) as? CustomCollectionCell else { fatalError("Unable to dequeue CustomCollectionCell") }
            cell.backgroundColor = .orange
            cell.update(with: name)
            return cell
        }
    }
    
    // updating the diffable with new data
    func updateSnapshot(with data: [String]) {
        var snapshot = NSDiffableDataSourceSnapshot<Int, String>()
        snapshot.appendSections([0])
        snapshot.appendItems(data) // Adding more items
        dataSource.apply(snapshot, animatingDifferences: true)
    }
}

final class CustomCollectionCell: UICollectionViewCell {
    static let name = "CustomCollectionCell"
    
    private var label: UILabel!
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        setupLabel()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    func update(with data: String) {
        label.text = data
    }
    
    private func setupLabel() {
        label = UILabel()
        label.textAlignment = .center
        
        self.contentView.addSubview(label) // remember to add it to the contentView
        
        label.translatesAutoresizingMaskIntoConstraints = false
        NSLayoutConstraint.activate([
            label.topAnchor.constraint(equalTo: contentView.topAnchor), // we are referring to contentView not view
            label.leadingAnchor.constraint(equalTo: contentView.leadingAnchor), // we are referring to contentView not view
            label.trailingAnchor.constraint(equalTo: contentView.trailingAnchor), // we are referring to contentView not view
            label.bottomAnchor.constraint(equalTo: contentView.bottomAnchor), // we are referring to contentView not view
        ])
    }
}

Configuring a Programmatic UIKit Project

Sun, 26 May 2024 22:35:31 +0000

In some projects, you might not want to use Storyboards or XIBs for various reasons, such as greater flexibility and control over your views, better version control, or simply personal preference. If that’s your case, this post will guide you through the basic steps to configure a Storyboard project to work with UIKit programmatically.

Step-by-Step Guide

I’m using Xcode 15.4, the graphical user interface (GUI) may change in the future causing some images to be outdated or some steps to be different.

1. Create a New Project

Start by creating a new iOS project in Xcode:

Open Xcode and select “Create a new Xcode project”.

Choose the “App” template under the iOS tab.

Enter your project details (Product Name, Team, etc.) and make sure “Storyboard” is selected for the User Interface.

Save your project wherever you like and optionally tick the “Create Git repository on my Mac” to initialize a local git repository for this project.

2. Remove the Main Storyboard

Next, we’ll remove the storyboard file and configure the project to work without it:

Delete Main.storyboard:
- In the Project Navigator, locate Main.storyboard.
- Right-click on Main.storyboard and select “Delete”. Choose “Move to Trash” to remove it completely.

Remove Storyboard References from Info.plist:
- Open Info.plist.
- Delete the Main storyboard file base name key (usually named Storyboard Name).

Remove Storyboard References from Build Settings:
- Select your project in the Project Navigator.
- Select your app target.
- Go to the “Build Settings” tab.
- Search for Main and make sure there are no references to Main.

3. Set the Root View Controller Programmatically

Depending on whether your project uses a SceneDelegate (iOS 13 and later) or not, you’ll set the root view controller differently.

Using AppDelegate (iOS 12 and earlier or single-window apps)

Open AppDelegate.swift.

In the application(_:didFinishLaunchingWithOptions:) method, add the following code to set up the window and root view controller:

import UIKit

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        window = UIWindow(frame: UIScreen.main.bounds)

        let initialViewController = YourInitialViewController()
        window?.rootViewController = UINavigationController(rootViewController: initialViewController)
        window?.makeKeyAndVisible()

        return true
    }
}

Using SceneDelegate (iOS 13 and later)

Open SceneDelegate.swift.

In the scene(_:willConnectTo:options:) method, add the following code to set up the window and root view controller:

import UIKit

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }

        window = UIWindow(windowScene: windowScene)
        let initialViewController = YourInitialViewController()
        window?.rootViewController = UINavigationController(rootViewController: initialViewController)
        window?.makeKeyAndVisible()
    }
}

In these files, you can do more complex setups like configuring routers for navigation, setting up a tab bar controller, or managing a split view controller, depending on your app’s needs.

4. Create Your Initial View Controller

Create a new Swift file for your initial view controller:

In the Project Navigator, right-click on the project folder and select “New File”.
Choose “Swift File” and name it YourInitialViewController.swift.

Implement your view controller as follows:

import UIKit

class YourInitialViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()

        // Set the background color to visually verify the setup
        view.backgroundColor = .white

        // Additional setup for your view controller
    }
}

5. Run the Project

Build and run your project. You should see a white screen, indicating that your initial view controller is being presented programmatically.

Conclusion

By following these steps, you’ve successfully configured your Storyboard-based project to work programmatically with UIKit. This setup provides you with greater flexibility and control over your views, and you can now add your UI elements directly in code.

Happy coding!

Programmatic Tab Bar

Sun, 26 May 2024 22:17:06 +0000

Tabs bars are one the most recognizable UI elements for an iOS apps. We can find this element in build in apps like Phone, Photos, Music, AppStore, and many more.

Lucky for us, this element is quite easy to use, and in this tutorial, we’ll learn how to create a tab bar programmatically using UIKit. Let’s start!

Simple example

Let’s start by configuring our project to allow us to instantiate our views programmatically. You can follow this guide.

1. Create the Tab Bar class

I prefer to have a separate class that handle all the Tab Bar related responsibilities, so let’s create a new file called TabBarViewController.swift and add the following code.

import UIKit

final class TabBarController: UITabBarController {
    override func viewDidLoad() {
        super.viewDidLoad()
    }
}

This is the minimum code we need to have a working tab bar.

2. Adding the tab bar to the app

Now we can instantiate this as we would do with a UINavigationController.

Open SceneDelegate.swift and and update the willConnectTo method as follows:

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = TabBarController()
        window?.makeKeyAndVisible()
    }

We are assigning the new Tab Bar as the window root view controller. This will present this as the first element in our screen.

Now run the app, you should see an empty tab bar in the screen.

3. Creating the View Controllers to show

We need to have some view controllers to show on the screen. Let’s make two simple dummy ones.

Create two new files, AViewController.swift and BViewController.swift and add the following code:

// A View Controller
import UIKit

final class AViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .yellow
    }
}

// B View Controller
import UIKit

final class BViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .orange
    }
}

These two view controllers are quite simple, with the only difference being their background color.

4. Presenting the View Controllers in the Tab Bar

Each UIViewController has a property called tabBarItem to which we can assign the tab bar item it will display in a tab bar.

Open the TabBarController.swift and update the code as follows:

import UIKit

enum TabBarTag: Int {
    case a, b
}

final class TabBarController: UITabBarController {
    override func viewDidLoad() {
        super.viewDidLoad()
        setupTabBar() // 3. Call the new function
    }
}

// 1 .Add this private extension
private extension TabBarController {
    // 2. Add this function that will instantiate the ViewControllers and assign their tab bar items
    func setupTabBar() {
        let aViewController = AViewController()
        // Adding the tab bar item to show in the tab bar for AViewController
        aViewController.tabBarItem = UITabBarItem(
            title: "A",
            image: UIImage(systemName: "1.lane"),
            tag: TabBarTag.a.hashValue
        )
        
        let bViewController = BViewController()
        // Adding the tab bar item to show in the tab bar for BViewController
        bViewController.tabBarItem = UITabBarItem(
            title: "B",
            image: UIImage(systemName: "2.lane"),
            tag: TabBarTag.b.hashValue
        )
        
        // UITabBarController contains an array of the view controllers that will be showing in the screen
        self.viewControllers = [aViewController, bViewController]
    }
}

I’m using an enum for the tag, so that we can refer to each tab bar item easily in the future for other parts of our app.

5. Run the app

Now run the app and see the tab bar in action.

With this little code, we have a simple tab bar implemented in our app.

Advanced Usage

Under development …

Delegate Pattern in Swift

Thu, 16 May 2024 22:16:34 +0000

Lately, I’ve been writing a lot about UIKit and I noticed I haven’t covered the delegate pattern.

This pattern is not exclusive to UIKit but it’s quite used in this framework.

In this post, we’ll dive into the Delegation Pattern, a fundamental design pattern in iOS development that helps in creating a well-structured codebase.

What is the Delegation Pattern?

The Delegation Pattern is a design pattern where one object (the delegator) hands off (or delegates) some of its responsibilities to another object (the delegate). This allows for a clear separation of concerns and makes it easier to manage and extend code.

By responsibilities, we mean functions or actions the object needs to perform but doesn’t want to implement itself because it’s not directly responsible. This allows for a clear separation of concerns and makes it easier to manage and extend code.

Why Use the Delegation Pattern?

Separation of Concerns: It helps in dividing the functionality into different classes, making the code more modular and easier to manage.
Reusability: Delegate objects can be reused across different contexts and components.
Flexibility: It provides a way to customize or extend the behavior of a class without modifying its source code.

How to Implement the Delegation Pattern in Swift

Let’s go through a practical example to illustrate the Delegation Pattern.

Step 1: Define the Protocol

First, define a protocol that outlines the responsibilities to be delegated.

protocol CustomDelegate: AnyObject {
    func someDelegatedFunction()
    func someOtherDelegatedFunction(withString: String)
}

Here, we are specifying the actions our object needs to perform but are not implemented by the object itself.

We can also pass information back to the delegate object. This can be as simple as one string or as complex as the whole object.

Step 2: Create the Delegator

Next, create the delegator class, which will hold a reference to the delegate and call its methods when appropriate.

class SomeObject {
    weak var delegate: CustomDelegate?

    func someAction() {
        delegate?.someDelegatedFunction()
    }

    func someOtherAction() {
        delegate?.someOtherDelegatedFunction(withString: "Some data being passed")
    }
}

It’s important to mark the delegate property as weak to avoid retain cycles and memory leaks.

This is a minimum example. In most cases, the object will also contain its own logic and only some parts will be delegated.

Step 3: Implement the Delegate

Finally, implement the delegate in a class that will handle the delegated tasks.

class OtherClassThatWantsToPerformTheActions {
    // Creating the object that needs the delegate
    // This can also be injected from a different object if we don't want to create it here.
    let someObject = SomeObject() 

    init() {
        // Assigning this class as the delegate object,
        // now someObject can call the implemented methods in this class when needed.
        someObject.delegate = self 
    }
}

// Implementing the delegate methods needed to be a valid delegate
extension OtherClassThatWantsToPerformTheActions: CustomDelegate {
    func someDelegatedFunction() {
        // Logic implemented when the method is called by the delegator 
    }

    func someOtherDelegatedFunction(withString: String) {
        // Logic implemented when the method is called by the delegator,
        // In this case, the delegator is passing back some information we may need to perform the action.
    }
}

Here are two crucial steps: we need to assign to SomeObject the class that will handle the delegate, and we need to implement the delegate protocol in the delegate class so that the assigned object can respond to the actions of SomeObject.

You’re done! Now, when you need to perform a delegated action, the responsible object will be called and perform the action in place of our delegator.

Example with UITableView

Let’s see an example involving UITableView, which frequently uses the delegation pattern.

With objects managed by UIKit we only need to implement the step 3 of the previous example (for our custom objects we need to implement all steps ourselves).

We will make our ViewController to act as the delegate for the UITableView.

import UIKit

class ViewController: UIViewController {
    
    // Creating the TableView that needs the delegate for certain actions
    let tableView = UITableView()
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        // Set up the table view
        tableView.frame = view.bounds
        tableView.delegate = self // assigning this object as the delegate
        tableView.dataSource = self
        tableView.register(UITableViewCell.self, forCellReuseIdentifier: "cell")
        view.addSubview(tableView)
    }
}

// MARK: - UITableViewDataSource
extension ViewController: UITableViewDataSource {
    
    // Return the number of rows in the section
    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return 10 // Example number of rows
    }
    
    // Configure and return the cell for the given index path
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "cell", for: indexPath)
        cell.textLabel?.text = "Row \(indexPath.row)"
        return cell
    }
}

// MARK: - UITableViewDelegate
extension ViewController: UITableViewDelegate {
    
    // Handle row selection
    // this method is defined in the delegate protocol for UITableView
    func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
        print("Selected row \(indexPath.row)")
        tableView.deselectRow(at: indexPath, animated: true)
    }
}

Both the delegate and the data source follow the delegation pattern, but the delegate manages user interactions and appearance, while the data source provides the data to be displayed.

In this example:

Define the Protocols: We use the built-in UITableViewDelegate and UITableViewDataSource protocols.
Create the Delegator: The UITableView instance is created and set up in the viewDidLoad method. It is configured to use the ViewController as its delegate and data source.
Implement the Delegate and Data Source: The ViewController class conforms to the UITableViewDelegate and UITableViewDataSource protocols. It implements required methods such as tableView(_:numberOfRowsInSection:) and tableView(_:cellForRowAt:) for the data source, and tableView(_:didSelectRowAt:) for the delegate.

Conclusion

The Delegation Pattern is a fundamental design pattern in iOS development that allows for a clear separation of concerns, making your code more modular and easier to manage. By delegating responsibilities, you can create reusable and flexible components that improve the maintainability of your codebase.

In this post, we explored the Delegation Pattern, learned how to implement it with a simple custom example, and saw how it is applied in a real-world scenario with UITableView.

Understanding and utilizing this pattern will help you create well-structured and efficient code, ensuring that your iOS applications remain robust and scalable. As always, following best practices and leveraging powerful design patterns like delegation will lead to better, more maintainable applications.

Happy coding!

Builder Pattern to Simplify UIKit Object Creation

Wed, 15 May 2024 20:52:02 +0000

One common issue with programmatic UIKit development is dealing with the creation and configuration of UI objects. Configuring UI elements in our code can be cumbersome and hard to synchronize their behavior and style across several screens.

By using the Builder Pattern, we can centralize the creation and configuration of these objects. This simplifies our codebase and decouples the creation of UI objects from our views.

What is the Builder Pattern?

The Builder Pattern is a creational design pattern that allows us to construct complex objects step by step. It separates the construction of a complex object from its representation, allowing the same construction process to create different representations.

I don’t want to focus on the formal definition too much (you can find a lot of great articles on the topic like this one). Instead, I prefer to show you a working example, so let’s go for it.

Practical Example

Let’s start with the builder. In this example, I want a way to configure a button with some defaults, so I can rely on these defaults to simplify further and accept modifications for specific cases.

Applying the Builder Pattern to UIKit

Let’s see how we can use the Builder Pattern to create and configure a UIButton in UIKit.

In a Storyboard project let’s create a new file ButtonBuilder.swift and add the following code.

class ButtonBuilder {
    private var button = UIButton(type: .system)
    
    func setTamic(_ active: Bool) -> Self {
        button.translatesAutoresizingMaskIntoConstraints = active
        return self
    }

    func setTitle(_ title: String) -> Self {
        button.setTitle(title, for: .normal)
        return self
    }

    func setTitleColor(_ color: UIColor) -> Self {
        button.setTitleColor(color, for: .normal)
        return self
    }

    func setBackgroundColor(_ color: UIColor) -> Self {
        button.backgroundColor = color
        return self
    }

    func setCornerRadius(_ radius: CGFloat) -> Self {
        button.layer.cornerRadius = radius
        return self
    }

    func setAction(_ action: @escaping () -> Void) -> Self {
        button.addAction(UIAction {_ in
            action()
        }, for: .touchUpInside)
        return self
    }

    func build() -> UIButton {
        return button
    }
}

They key point to implement a builder is that we have configuration functions that return the builder itself. These functions can be chained with other configuration functions as needed. Once we are done with the configuration, we call the build function to return the actual object configured with the selected options.

Using the builder inside a ViewController

To use our builder let’s create a new file called TestViewController.swift and add the following code.

import UIKit


class ExampleViewController: UIViewController {
    private lazy var button = ButtonBuilder()
        .setTamic(false)
        .setTitle("Example")
        .setAction {
            print("Button pressed")
        }
        .setBackgroundColor(.cyan)
        .build()
    
    override func viewDidLoad() {
        view.addSubview(button)
        NSLayoutConstraint.activate([
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor)
        ])
    }
}

#Preview {
    ExampleVC()
}

The final result resembles the simple and declarative style of SwiftUI!

Remember to use [weak self] if you’re capturing self or any property of self in your button action.

Test the button action in the Canvas and enjoy!

Considerations

Sometimes the object cannot be created before we have all the properties or dependencies. In these cases, we can gather the dependencies or properties and only create the object in the build function, where we inject the desired properties.

Here is an example for a Label to demonstrate this.

class LabelBuilder {
    private var text: String = ""
    private var numberOfLines: Int = 0
    private var tamic: Bool = false
    
    func withText(_ text: String) -> Self {
        self.text = text
        return self
    }
    
    func withNumberOfLines(_ number: Int) -> Self {
        self.numberOfLines = number
        return self
    }
    
    func withAutoLayout(_ tamic: Bool) -> Self {
        self.tamic = tamic
        return self
    }
    
    func build() -> UILabel {
        let label = UILabel()
        label.text = text
        label.numberOfLines = numberOfLines
        label.translatesAutoresizingMaskIntoConstraints = tamic
        return label
    }
}

In this example, we define the properties beforehand and assign default values that make sense for our final object. Changes to these defaults are optional and can be made using the configuration methods.

Conclusion

By leveraging the Builder Pattern, we can streamline the process of creating and configuring UI elements in UIKit. This approach not only makes our codebase more manageable but also decouples the configuration from the views, enhancing maintainability and reusability. Whether you are setting up a simple button or a more complex object, the Builder Pattern provides a flexible and clean solution.

I hope this guide helps you simplify your UIKit development. Give it a try in your next project and see the difference it can make!

Creating an MVVM Counter In UIKit

Mon, 13 May 2024 22:55:14 +0000

One of the standout features of SwiftUI is its reactive paradigm, which seamlessly updates views as data changes. This powerful approach isn’t confined to SwiftUI alone; it can also be harnessed in UIKit through the use of the Combine framework, and starting with iOS 17, through the new Observation framework.

In this post, we’re going to explore using MVVM with UIKit, leveraging Combine to achieve reactive behaviors similar to SwiftUI. I hope you find this information useful and that it helps you improve the way you create and think about your applications. Join me as we dive into making your UIKit apps more responsive and robust.

What is MVVM?

MVVM (Model-View-ViewModel) is a popular architectural pattern that divides the application into three interconnected components. This separation aids in managing complexities and enhances the maintainability of the application.

The Model includes both the data and the business logic specific to the application. It represents the actual data content and the operations that can manipulate this data.
The ViewModel acts as an intermediary between the Model and the View. It handles most of the view logic, transforming data from the Model in a way that the View can easily present. The ViewModel also responds to user input and view-related logic, thus abstracting the View from the Model. A key component of the ViewModel is its reactivity; it notifies the View of changes to the data automatically, facilitating a dynamic user experience.
The View is responsible for presenting the data provided by the ViewModel in a user-friendly format. It focuses purely on the visual representation, relying on the ViewModel to manage any state or processing of data. The View interacts with the ViewModel through mechanisms like data binding, which ensures that changes in the ViewModel are automatically reflected in the View.

By separating concerns in this manner, MVVM facilitates a clear division of labor with respect to how data is managed, presented, and interacted with. This not only makes the application easier to maintain but also enhances its scalability and testability.

How to Obtain Reactivity?

To ensure that view controllers are aware of changes in the ViewModels, a mechanism for subscribing to and receiving notifications of these changes is necessary. One effective approach to achieve this in iOS development is through the use of Apple’s Combine framework.

Combine allows ViewModels to publish updates whenever their state changes. View controllers can subscribe to these publications and react accordingly. This setup ensures that the View layer remains responsive and up-to-date with the latest data. Here’s a basic example of how this might be implemented:

ViewModel publishes changes: The ViewModel includes properties marked with @Published, triggering the publisher whenever the property’s value changes.
View controller subscribes to changes: In the view controller, a subscriber is set up to listen to the ViewModel’s publishers. Using Combine’s sink(receiveValue:) method, the view controller can update its UI components whenever it receives new data.

This model promotes a reactive and efficient architecture where data flow and user interface updates are tightly coordinated.

Making an app: MVVM Counter

Let’s recreate a simple counter app using MVVM + Combine + UIKit. This app is a great first introduction to reactive programming since it shows the basic components and their interactions.

Where is the model?

This app is quite simple, the model is just an Int that will be updated every time we press the button. That’s why we aren’t creating an explicit model object. But remember with more complex models is a good idea to have a separate struct for them.

Creating the View Model

The View Model will contains the state and the methods to interact with the states, this object will relay on Combine to publish the changes to their subscribers.

Create a new file called ViewModel.swift and add the following code.

import Combine

class ViewModel: ObservableObject {
    @Published private(set) var counter = 0
    
    func addOne() {
        counter += 1
    }
}

Here is a brief description of the code:

class ViewModel: ObservableObject: We define a class ViewModel that conforms to the ObservableObject protocol. This protocol is part of the Combine framework and allows the properties of our ViewModel to be observed by the UI for changes.
@Published private(set) var counter = 0: Here, counter is a property that stores a numerical value, initialized to 0. The @Published attribute before counter makes it a published property, meaning any UI components observing this property can react to changes in its value. The private(set) modifier means that the value of counter can only be modified within the ViewModel class itself, enforcing encapsulation and control over how the value is changed.
func addOne(): This function defines the behavior to increment the counter by 1. Whenever addOne is called, the counter property is increased, and because it’s a @Published property, all observers (such as UI components) are notified of this change.

Creating the View

To create the View we are using a UIViewController, let’s create a new file and call it ViewController.swift.

First, let’s add the UI Elements to our controller. In this simple app we only need a UILabel and a UIButton.

import UIKit

class ViewController: UIViewController {
    
    private lazy var counterLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Button pressed 0"
        return label
    }()
    
    private lazy var counterButton: UIButton = {
        let button = UIButton()
        button.translatesAutoresizingMaskIntoConstraints = false
        button.configuration = UIButton.Configuration.filled()
        button.setTitle("Count", for: .normal)
        return button
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        configuration()
        addObjectsToView()
        addConstraintsToObjects()
        
    }
}

private extension ViewController {
    func configuration() {
        view.backgroundColor = .systemBackground
        
        counterButton.addAction(UIAction { [weak self] _ in print("Button tapped") }, for: .touchUpInside)
    }
    
    func addObjectsToView() {
        [counterLabel, counterButton].forEach {
            view.addSubview($0)
        }
    }
    
    func addConstraintsToObjects() {
        NSLayoutConstraint.activate([
            counterLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            counterLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            counterButton.topAnchor.constraint(equalTo: counterLabel.bottomAnchor, constant: 32),
            counterButton.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32),
            counterButton.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32)
        ])
    }
}

So far nothing new, just a simple ViewController with some UI elements.

Adding Reactivity

Now comes the interesting part of the MVVM pattern, reacting to changes in the ViewModel.

The first step it to include Combine in the ViewController.

Next, let add a dependency to the ViewModel so that our ViewController can subscribe to the changes published by the view model.

Inside the ViewController class add the following properties

private let viewModel = ViewModel()
private var cancellables: Set<AnyCancellable> = []

The above code may become confusing because of the cancellables property, this is used to avoid memory leaks.

When you use the Combine framework to handle data flows in your applications, you often set up subscriptions where your UI components or other parts of your app listen to changes in your data. These subscriptions create what are known as “cancellables,” which are objects that represent the life of a subscription. To manage these effectively and avoid memory leaks, we use AnyCancellable.

By adding these AnyCancellable instances to a set called cancellables, you keep a reference to each active subscription. Storing them in a set is convenient because it ensures that each subscription is kept alive as long as you need it and is automatically cancelled and removed from memory when no longer needed or when the containing object (like a view model or view controller) is deallocated.

Next we need to subscribe to the published property of the view model.

Go to the configuration function and add the following at the bottom.

viewModel.$counter
            .sink { [weak self] value in
                self?.counterLabel.text = "Button Pressed \(value)"
            }.store(in: &cancellables)

The code snippet demonstrates how to update a user interface component in response to changes in a ViewModel property using Combine. Here’s how it works:

**viewModel.$counter**: This line begins observing changes to the counter property in the ViewModel. The $ prefix is a shorthand in Combine that provides a publisher for the property, which emits a new value each time the property changes.
.sink: The sink method is used to subscribe to the publisher and handle new data as it arrives. This method takes a closure that defines what to do with the emitted values. In this case, whenever counter updates, the closure receives the new counter value.
[weak self] value in: The closure captures self weakly to prevent retain cycles, which can lead to memory leaks. value is the latest value of counter emitted by the publisher.
self?.counterLabel.text = “Button Pressed (value)”: Inside the closure, the text of counterLabel (a UI label) is updated to display the number of times a button has been pressed, as indicated by the counter value.
.store(in: &cancellables): This part of the code is crucial for managing the subscription’s lifecycle. It adds the subscription to a set of cancellables (explained in the previous part about AnyCancellable). This ensures that the subscription remains active as long as needed and gets properly disposed of to prevent memory leaks.

This pattern is commonly used in iOS development with UIKit to dynamically update the UI in response to data changes in the ViewModel, enhancing the app’s reactivity and user experience.

Finally let’s update the button action to call the method that will triggers the View Model updates, in the configuration method, change the button action to the following.

counterButton.addAction(UIAction { [weak self] _ in self?.viewModel.addOne() }, for: .touchUpInside)

This will change the value in the view model each time we press the button, by changing the value we will trigger the notification in the published property, making the view controller to react to the change and update the value in the label automatically.

Here is the final form of the ViewController.

import UIKit
import Combine

class ViewController: UIViewController {
    
    private let viewModel = ViewModel()
    private var cancellables: Set<AnyCancellable> = []
    
    private lazy var counterLabel: UILabel = {
        let label = UILabel()
        label.translatesAutoresizingMaskIntoConstraints = false
        label.text = "Button pressed 0"
        return label
    }()
    
    private lazy var counterButton: UIButton = {
        let button = UIButton()
        button.translatesAutoresizingMaskIntoConstraints = false
        button.configuration = UIButton.Configuration.filled()
        button.setTitle("Count", for: .normal)
        return button
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        configuration()
        addObjectsToView()
        addConstraintsToObjects()
        
    }
}

private extension ViewController {
    func configuration() {
        view.backgroundColor = .systemBackground
        
        counterButton.addAction(UIAction { [weak self] _ in self?.viewModel.addOne() }, for: .touchUpInside)
        
        viewModel.$counter
            .sink { [weak self] value in
                self?.counterLabel.text = "Button Pressed \(value)"
            }.store(in: &cancellables)
    }
    
    func addObjectsToView() {
        [counterLabel, counterButton].forEach {
            view.addSubview($0)
        }
    }
    
    func addConstraintsToObjects() {
        NSLayoutConstraint.activate([
            counterLabel.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            counterLabel.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            counterButton.topAnchor.constraint(equalTo: counterLabel.bottomAnchor, constant: 32),
            counterButton.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -32),
            counterButton.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 32)
        ])
    }
}

Running the app

As simple as this you’ve implemented MVVM with Combine and UIKit. This example is a great way to observe the simplicity and power of reactive programming.

Here is the final result.

Conclusion

Throughout this post, we’ve explored how the MVVM architectural pattern can be effectively implemented in UIKit applications using the Combine framework to create reactive behaviors similar to those found in SwiftUI. By integrating MVVM with Combine, we’ve demonstrated that UIKit is far from obsolete in the era of modern, reactive iOS applications. Instead, it offers a robust platform for adopting reactive programming paradigms that can make your apps more responsive and easier to maintain.

The MVVM pattern not only separates concerns, enhancing the maintainability and testability of your applications, but also leverages the power of Combine to keep your UI in perfect sync with the underlying data model. As we have seen with our simple counter app example, even traditional UIKit apps can benefit immensely from the clarity and efficiency that reactive programming brings.

I hope this walkthrough has provided you with a clear understanding and practical knowledge on integrating MVVM with UIKit using Combine, and inspires you to apply these concepts to your own iOS projects. Reactive programming might seem daunting at first, but with practice, it becomes an indispensable part of crafting elegant and efficient iOS applications.

Thank you for joining me on this journey through reactive programming with UIKit and MVVM. Happy coding!

Working With Xibs And Storyboards

Sun, 05 May 2024 05:40:28 +0000

In this entry, I’d like to explore the different ways we can interact with Xibs and Storyboards in our programmatic code. These files are present in many projects, so it’s important to understand the basics of how to work with them.

Let’s start with some definitions!

Definitions

What are Storyboards

Storyboards are like a big visual map in Xcode that lets you design your app’s screens. You can drag and drop things like buttons, labels, and images onto these screens to see how they’ll look. Plus, you can easily set up how the screens connect and move between each other. It’s like drawing out your app’s flow and layout so you can get a good idea of how it’ll all work together without needing to write too much code right away.

What are Xibs/Nibs

Xibs, short for “XML Interface Builder,” are individual files in Xcode that help you design a specific screen or component of your app. Think of them as blueprints for smaller, reusable parts of your app’s user interface. Unlike Storyboards, which give you a big-picture view of your entire app, Xibs are focused on one screen or view at a time. You can visually arrange buttons, labels, and other UI elements in a Xib file, then load that design in your app to get a custom layout exactly how you want it. It’s a handy way to build specific UI pieces without touching too much code.

On the other hand, Nibs (short for “NeXT Interface Builder”) are essentially compiled versions of Xibs. When you design a user interface in Xcode using a Xib file, it gets converted into a more optimized format called a Nib file that the app can load at runtime. This makes the interface ready to use more quickly. In short, Nibs are pre-packaged user interface designs created from Xibs, enabling the app to load and use them efficiently when needed.

So, while you work on Xibs during development, your app uses Nibs when it runs!

Working with Storyboards

Creating a new Storyboard

When we create a new app with Storyboard, Xcode automatically will create a Main Storyboard. We can also create these files, here is how:

Inside an Xcode project let’s press CMD + N and select storyboard in the presented window.

Add a name for the new Storyboard, remember to add it to the correct Group and Target.

The new Storyboard is ready to use in our project, add the elements you need inside the Storyboard graphically, no code is needed here.

Adding constraints to the Storyboard

By default, new UI elements added to the Storyboard doesn’t know where they will be placed on the screen. To alleviate this we can add constraints to the elements in the screen.

UI elements can be seen as rectangles on the screen and the constraints tells these sides how to relate to other elements in the screen.

If the UI element is affected by the language orientation you should use leading and trailing.

One key difference between programmatic constraints and visual constraints (those added in the Xcode Interface Builder) is that the latter are added to the closest element to the selected UI element.

In this example, the Label bottom is constrained to the top side of the button because that is the closest element to the Label, the other sides are related to the container view sides because this is the the closest element in relation to this UI object.

To add constraints using the Interface Builder we use the buttons at the bottom right.

These are called:

Update frames
Align
Add new constraints
Resolve Autolayout Issues

We can use Add new constraints to add constrains to the selected view. Remember that this constrains will be in relation to the closest object for the selected side of the object.

to center elements with respect to the super view, we can use Align.

Once these constraints are set, we can modify them by open the right panel and select Show the size inspector.

In this panel we can also modify the Hugging and Compression.

Hugging and Compression

When working with auto layout, there are two important concepts:

Content Hugging Priority: This controls how much a view likes to stick to its natural size. Higher priority = less likely to grow bigger than its content.
Content Compression Resistance Priority: This controls how much a view resists shrinking below its natural size. Higher priority = less likely to be squished.

Simply put, hugging stops a view from stretching too much, and compression resistance prevents it from getting squished too much.

Adjusting Priorities and Values

Priority Values: Default values are 250 for content hugging and 750 for compression resistance. Adjusting these values can help achieve the desired behaviors in your UI.
Intrinsic Content Size: Some elements, like labels and buttons, have a natural size based on their content. Hugging and compression resistance help these elements maintain that size whenever possible. For example, a label with high compression resistance won’t shrink and cut off the text, while low compression resistance allows it to shrink and potentially truncate the text. A low content hugging priority allows the label to expand beyond the text’s size, while high content hugging priority keeps the label close to its content and prevents unnecessary expansion.

Handling Ambiguity and Conflicts

Ambiguous Layouts: When auto layout can’t determine the final position or size of a view, you may see a warning about ambiguous layouts. To fix this, ensure all views have enough constraints to define their positions fully.
Conflicting Constraints: Conflicting constraints happen when two or more constraints contradict each other. For instance, a button cannot be both centered and anchored to a side. Resolve these by removing or adjusting constraints to eliminate conflicts.

Use Cases and Best Practices

Adjusting Priorities: If you have a flexible view like a label next to a fixed-size view like an image, increase the label’s hugging priority to prevent unwanted expansion.
Avoiding Common Mistakes: Be careful not to over-constrain views. Over-constraint can lead to conflicts or unexpected resizing, so it’s best to only apply necessary constraints.

Assigning a ViewController to the Storyboard

Having the storyboard is great, but we need to add code to make it function logically within our app. One way to do this is by associating a view controller with the storyboard.

Open the right panel in Xcode (CMD + OPT + 0) and the Storyboard file.
Select the View Controller Scene in the inner left panel.
On the right panel select Show Identity Inspector, here you will see a section called Custom Class, you add your reference in the Class section. Select any UIViewController class you want to connect to the storyboard and assign a Storyboard ID.

After adding the ViewController, you will end up with this. Now you can connect your elements in the storyboard to your ViewController and access their attributes and add actions as needed.

Don’t forget to add a Storyboard ID, we need this to reference it from objects in our code.

Linking Storyboard elements to ViewController

There are several ways of linking the UI elements in the Storyboard to a particular View Controller.

Here is one simple approach with CONTROL + Drag.

CONTROL + Drag means you should move your cursor (using your mouse, trackpad, or other input device) to the file on the right while you’re pressing the CONTROL key on your keyboard.

Open the Storyboard file.
On the up right side click on Adjust Editor Options.
Select Assistant Layout (CONTROL + OPTION + CMD + ENTER).
CONTROL + Drag the UI elements to the code.

Here is a video showing the whole process.

Finally you can add the logic in the View Controller. For this example we have a button that changes the background color and updates the label with the selected color.

import UIKit

class ExampleViewController: UIViewController {

    @IBOutlet weak var colorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
    }
    
    private func updateScreen(with color: UIColor) {
        view.backgroundColor = color
        colorLabel.text = color.accessibilityName
    }
    
    @IBAction func whiteAction(_ sender: Any) {
        updateScreen(with: .white)
    }
    
    @IBAction func redAction(_ sender: Any) {
        updateScreen(with: .red)
    }
    
    @IBAction func greenAction(_ sender: Any) {
        updateScreen(with: .green)
        
    }
    
    @IBAction func blueAction(_ sender: Any) {
        updateScreen(with: .blue)
    }
}

Accessing the UI element in the View Controller

Interactive Elements

To access interactive UI elements declared in the storyboard from the view controller, we have two options:

Using an IBOutlet reference.
Using an associated IBAction.

If we want to use the associated action, we can cast the received sender to the appropriate UI type. Here’s an example with a button.

@IBAction func greenAction(_ sender: Any) {
        guard let button = sender as? UIButton else { return }
        print(button.titleLabel?.text ?? "No title label found")
        updateScreen(with: .green)
        
    }

We can do this with all UI elements that support interactivity via @IBAction.

The IBAction mechanism is designed specifically to handle user-triggered events, which usually means interactive controls like buttons, sliders, switches, etc.

List of interactive UIElements

UIButton: Supports touch events like tapping and can be connected to IBAction for touchUpInside, touchDown, etc.
UISwitch: Can trigger an IBAction when its on/off state changes.
UISlider: Sends an action when its value changes due to user interaction.
UISegmentedControl: Triggers an action when the selected segment changes.
UIDatePicker: Triggers an action when the selected date changes.
UITextField: Supports actions like editingDidEnd or editingChanged.
UIPageControl: Triggers an action when the current page index changes.
UIRefreshControl: Triggers an action when the user initiates a refresh in a scroll view.
UINavigationItem and UIBarButtonItem: Both can have actions assigned via IBAction to handle navigation or toolbar events.

Non interactive element

To access non-interactive elements, we need to use their IBOutlet reference inside the view controller.

To add actions for these elements, we can use a UITapGestureRecognizer.

In this example, the view controller has a reference to a label in the storyboard via IBOutlet, and we can add the following code to enable interactivity.

class ExampleViewController: UIViewController {

    @IBOutlet weak var colorLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        addTapActionToLabel() // Add this function call
    }

    // More code

    // Add this function
    private func addTapActionToLabel() {
        let tapGesture = UITapGestureRecognizer(target: self, action: #selector(labelTapped))
        colorLabel.addGestureRecognizer(tapGesture)
        colorLabel.isUserInteractionEnabled = true
    }
    
    // Add this function
    @objc func labelTapped() {
        print("Label tapped!")
    }

    // More code
}

The IBOutlet mechanism is designed specifically to link UI elements, such as labels, buttons, and image views, to properties in your code, enabling you to access and modify these components programmatically after connecting them via a storyboard or Xib file.

List of non interactive UI elements

UILabel: Displays static or dynamic text but doesn’t respond to user interactions on its own.
UIImageView: Shows images but isn’t designed to respond to taps or other gestures directly.
UIView: A base view class that serves as a container for other elements and doesn’t have direct user interaction methods.
UIStackView: Arranges child views in a horizontal or vertical stack but doesn’t have built-in user-triggered events.
UITableViewCell: The individual cells in a table view that respond to user interaction only through their parent table view.
UICollectionViewCell: Similar to table view cells, these collection view cells interact through the parent collection view.

Instantiating Storyboards from another View Controller

To instantiate programmatically a storyboard from another class we can follow the next approach.

To achieve this we need two pieces of information, the name of the storyboard file and the Storyboard ID. We use the first element in UIStoryboard and the second element in storyboard.instantiateViewController.

We can present or push the final object, in this example we are pushing the storyboard as a modal.

// A different view controller that will instantiate the storyboard
class ViewController: UIViewController {

    // More code

    override func viewDidAppear(_ animated: Bool) {
        presentStoryboard()
    }

    func presentStoryboard() {
        let storyboard = UIStoryboard(name: "ExampleStoryboard", bundle: nil)
        if let exampleViewController = storyboard.instantiateViewController(withIdentifier: "ExampleSB") as? ExampleViewController {
            present(exampleViewController, animated: true, completion: nil)
        }
    }

    // More code

}

Here is a small example of the resulting presentation.

Working with Xibs

Working with Xibs is similar to working with Storyboards, so this section will feel familiar to the Storyboard section.

Creating Xibs

With an associated View Controller

One simple way to create a Xib is during the creation of a View Controller.

Inside an open Xcode project press CMD + N to open the template window.

Then give it a name and check the box Also create XIB file.

After pressing Next, select a directory to create the files and check the target and group are correct.

Now two files will be created, the Xib and the View Controller class.

These two files are now linked by default, so you can add IBActions and IBOutlets in your custom controller class to add some logic to the Xib.

Simple example to control the Xib objects from code

Let’s add and connect the following elements to the Xib. You can add the constrains as you like.

Then let’s add some IBOutlet to the preconfigured UIViewController subclass (this process is the same as with the Storyboard, you can refer it here).

class ExampleXibViewController: UIViewController {
    @IBOutlet weak var titleLabel: UILabel!
    @IBOutlet weak var subheadingLabel: UILabel!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        titleLabel.text = "Awesome Xib Example"
        subheadingLabel.numberOfLines = 0
        subheadingLabel.text = "Learning how to integrate Xibs on your programmatic projects."
    }

}

#Preview(traits: .sizeThatFitsLayout) {
    ExampleXibViewController()
}

Now you can see how the Xib is loaded automagically (this works because both files have the same name and the Xib was autoconfigured to have this class as its file owner) and thanks to the IBOutlet you can manage their state and actions using the references in the code.

Individually

To create an individual Xib file, press CMD + N and select either View or Empty.

Finally, we give a name, check the correct group and target, and press Create.

Change Xib visual interface to freeform

By default Xib interface resembles an iPhone screen, sometimes we are creating a View that will act as a component, in these cases having the iPhone layout is not the best idea.

To change to a freeform layout we can do the following

Open the right bar CMD + OPC + 0.
In the right bar, select Show the attribute inspector.
Under Simulated metrics select size.
In the size menu select Freeform.
Optional, change the dimensions of your Xib to your liking.

Disable Safe Area for Freeform Xibs

If we are using our Xibs as a component to the final screen, we may not want to have Safe area on by default, to turn it off we can do the following:

Open the right bar CMD + OPC + 0.
In the right bar, select Show the size inspector.
Under Layout Guides untick Safe Area.

Adding constraints to Xibs

This works the same as adding constraints to Storyboards, you can refer to that section here.

Connecting Xibs to Classes

Individual Xibs can be connected to Classes to add some logic to them.

We are covering these cases:

Connecting to UIView subclass.
Connecting to UIViewController subclass.
Connecting to UITableViewCell or UICollectionViewCell subclasses.

Connecting to `UIView` subclass

We can bind a Xib with a UIView subclass, this process is a tad complicated than binding with UIViewControllers.

First, let’s create the UIView subclass we are going to bind to the Xib.

Press CMD + N and select Swift File.

Give it a name and be sure to add it to the right group and target, press create.

Create the class by adding the following code to the new created file.

import UIKit

class SimpleXibView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

#Preview(traits: .sizeThatFitsLayout) {
    SimpleXibView(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
}

Assign this class as the File's Owner

Add the nib load method to the UIView custom class.

We use this method to load the Xib with the same name as our UIView class, if your Xib has a different name update the method accordingly.

private func loadFromNib() {
        guard let view = Bundle(for: type(of: self)).loadNibNamed(String(describing: type(of: self)), owner: self, options: nil)?.first as? UIView else { return }
        view.frame = self.bounds
        view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        self.addSubview(view)
    }

Call the method in the init to load the Nib, your class should look like this.

import UIKit

class SimpleXibView: UIView {
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        loadFromNib()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
    private func loadFromNib() {
        guard let view = Bundle(for: type(of: self)).loadNibNamed(String(describing: type(of: self)), owner: self, options: nil)?.first as? UIView else { return }
        view.frame = self.bounds
        view.autoresizingMask = [.flexibleWidth, .flexibleHeight]
        self.addSubview(view)
    }
   
}

#Preview(traits: .sizeThatFitsLayout) {
    SimpleXibView(frame: CGRect(x: 0, y: 0, width: 100, height: 100))
}

Preview the Nib on the Canvas!

Now you have linked your Xib with a custom UIView subclass.

You can add IBOutlet or IBAction to manage the logic of your View. This mechanism doesn’t change from how we did it with Storyboards, here you can find out more.

Connecting to `UIViewController` subclass

Xibs are easy to connect to UIViewController.

Assign the File's Owner to the desire custom class.
CONTROL + CLICK on File's Owner and drag view to the view object on screen.

The view property of the File's Owner only appear if the assigned class is a subclass of UIViewController.

Here is a video showing the process.

Connecting to `UITableViewCell` or `UICollectionViewCell` subclasses

Working with tables deserves a separate entry, but to finish Xibs let’s give the steps needed to create and link cells.

Create the Xib File: In Xcode, right-click on the project navigator, select “New File…”, choose “View” under the User Interface section, and name the Xib after the cell it represents, like CustomTableViewCell.xib.
Design the Interface: Open the Xib file, drag a UITableViewCell or UICollectionViewCell from the object library onto the canvas, and add UI elements like labels, images, buttons, etc.
Create the Cell Subclass: Create a new Cocoa Touch Class, subclass UITableViewCell or UICollectionViewCell as CustomTableViewCell, then go back to your Xib file, select the cell, and set the class to CustomTableViewCell in the Identity Inspector.
Connect Outlets: With the Xib file and the Assistant Editor open (showing CustomTableViewCell.swift), Ctrl-drag from the UI elements in the Xib to the class file to create outlets and actions.
Register the Xib with the Table or Collection View: In your view controller’s viewDidLoad() method, register the Xib with let nib = UINib(nibName: "CustomTableViewCell", bundle: nil) and tableView.register(nib, forCellReuseIdentifier: "CustomCellIdentifier") for UITableView, or similar steps for UICollectionView.

Conclusion

In this blog entry, we’ve embarked on a comprehensive exploration of Xibs and Storyboards within Xcode, unraveling their functionalities and best practices to enhance our iOS development skills. By dissecting their definitions and diving into practical implementation scenarios, we’ve equipped ourselves with the knowledge to effectively utilize these tools in creating both complex and component-specific user interfaces.

The step-by-step guides provided will serve as a valuable reference for integrating Xibs and Storyboards into your projects, ensuring you can confidently handle layout constraints, link UI elements to code, and streamline your development process. Whether you’re crafting a single view or orchestrating an entire app’s flow, the insights shared here aim to bolster your proficiency and creativity in using these powerful features of Xcode.

As we continue to evolve our skills in the iOS development landscape, let’s leverage the flexibility and functionality of Xibs and Storyboards to create more dynamic, efficient, and visually compelling applications when working with UIKit.

Introduction to Programmatic UIKit

Tue, 16 Apr 2024 01:27:55 +0000

Hello world, I’m back with a new entry on UIKit. In iOS 17 Apple added the ability to preview our views and ViewControllers using the SwiftUI canvas. This brings the possibility of faster programmatic UIKir programming. Let’s make a small project that illustrates how to leverage this new functionality and revising how we can create an app in UIKit 100% programmatically. 🚀

The app

We will be coding an app that will ask for user information and then send it back to the main ViewController, this will showing us a simple way to pass information between views, a small introduction intro programmatic navigation and view reusability.

Configuring the project to work without Storyboard

Deleting storyboard files and references

UIKit only works on iOS and iPadOS, so you’ll need to create an iOS app in Xcode and select Storyboard, but don’t worry we’re going to delete all the stuff related to it. We’re going full code this time.

Select iOS App and Storyboard for the interface, remember Storyboard means UIKit under the hood.

Once Xcode is open with our project we need to delete all the stuff related to storyboard configuration.

First, let’s delete the Storyboard by moving it to the trash (you can leave the LaunchScreen).

Now let’s delete the references for the deleted Storyboard, follow the images and delete the selected sections.

Congratulations, you have deleted storyboards from your UIKit project. Now run the app and see a cool black screen.

Now it’s time to instantiate and show our first screen!

Open SceneDelegate.swift and locate the function func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions), next replace the code inside the function with this.

guard let windowScene = (scene as? UIWindowScene) else { return }
let viewController = ViewController()
let navigationController = UINavigationController(rootViewController: viewController)
window = UIWindow(windowScene: windowScene)
window?.rootViewController = navigationController
window?.makeKeyAndVisible()

Here is an explanation of the code above:

Scene Detection and Guard Clause: guard let windowScene = (scene as? UIWindowScene) else { return }
This line ensures the scene parameter is of type UIWindowScene. If not, it exits the block of code to prevent errors. This is essential for apps supporting multiple scenes in iOS 13 and later.
View Controller Initialization: let viewController = ViewController()
Creates a new instance of ViewController, which should be a subclass of UIViewController. This controller will manage the app’s initial view.
Navigation Controller Setup: let navigationController = UINavigationController(rootViewController: viewController)
Initializes a UINavigationController with the viewController as its root. This setup provides a navigation bar and a stack-based navigation mechanism.
Window Initialization: window = UIWindow(windowScene: windowScene)
Creates a new UIWindow using the windowScene from the first line, setting up the environment where the app’s content will be displayed.
Setting the Root View Controller: window?.rootViewController = navigationController
Assigns the navigationController as the window’s root view controller, making viewController the first visible view.
Making the Window Key and Visible: window?.makeKeyAndVisible()
This method sets the window as the key window and ensures it is visible, making it the main focus for user interactions.

Each ViewController has an associated optional NavigationController, this object is used to manage the push and pop of different ViewControllers, some architectures like to manage this navigation using a coordinator.

Congratulations on having the basic components to navigate your app and show your first screen.

Creating the Model

The app is quite simple, the model just consist of two Strings that will be change according to what the user inputs in the form.

To create a Model we just need to create a struct with the fields we need. Create a new file called TrainerInfo.swift and add the following code.

import Foundation

struct TrainerInfo: Identifiable {
    let id: UUID
    var name: String
    var favoritePokemon: String
}

extension TrainerInfo: CustomStringConvertible {
    var description: String {
        "Trainer \(name) likes \(favoritePokemon)"
    }
}

This model will store the trainer’s name and their favorite Pokémon. The extension is a good way to get a string representation of the object, we will use this string later in our views.

Creating reusable components

Our app is quite simple, yet we are using several repeated components in our Views, to avoid repeating code and ensure the UI elements behave the same way through the app we are going to create simple reusable components. To do this we are going to extend the class element of the component we need and add a function that will create the component configured for our use.

Let’s start by creating a new Group called Extensions by pressing CMD + OPC + A, inside this new group let’s create a new file called UIExtensions.swift and add the following code:

import UIKit

extension UIButton {
    static func makeSimpleButton(title: String, action: UIAction) -> UIButton {
        let button = UIButton()
        button.setTitle(title, for: .normal)
        button.addAction(action, for: .touchUpInside)
        button.configuration = UIButton.Configuration.filled()
        button.translatesAutoresizingMaskIntoConstraints = false
        return button
    }
}

extension UILabel {
    static func makeSimpleLabel(
        text: String = "",
        textAlignment: NSTextAlignment = .center,
        font: UIFont = .preferredFont(forTextStyle: .body)
    ) -> UILabel {
        let label = UILabel()
        label.textAlignment = textAlignment
        label.text = text
        label.font = font
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }
}

extension UIStackView {
    static func makeSimpleStack(axis: NSLayoutConstraint.Axis ) -> UIStackView {
        let stack = UIStackView()
        stack.axis = axis
        stack.translatesAutoresizingMaskIntoConstraints = false
        return stack
    }
}

extension UITextField {
    static func makeSimpleTextField(delegate: (any UITextFieldDelegate)?) -> UITextField {
        let textField = UITextField()
        textField.borderStyle = .roundedRect
        // Don't forget to add delegate to call the function that sends data back
        textField.delegate = delegate
        textField.translatesAutoresizingMaskIntoConstraints = false
        return textField
    }
}

Done, now we can use these methods to create preconfigured UI elements, we can configure further to tailor our needs, if the systems grows quite complex we could even implement Factories. This is a great way to avoid repeating code and ensuring UI uniformity for our app.

Creating our first screen

Now that we have all the needed code in place, it’s time to see some changes in our phone’s screen. Let’s open ViewController.swift and let’s start adding our UI elements!

For this screen we are going to use a UILabel and a UIButton, it’s time to use our handy make methods we defined in our previous step.

In the body class, let’s add the following properties that will contain the references to the UI elements.

private lazy var button: UIButton = .makeSimpleButton(title: "Add Trainer Data", action: buttonAction)
private lazy var label: UILabel = .makeSimpleLabel()

Now you will get an error because buttonAction is not defined, let’s fix that now!

Create a private extension of your ViewController class and add the missing method there.

private extension ViewController {
    
    var buttonAction: UIAction {
        UIAction { [weak self] action in
            print("Button pressed")
        }
    }
}

This should fix the error. Later on, we will add the logic for the pressed button.

Previewing your ViewController

iOS 17 allow us to see in the Canvas the current state of our ViewController. This addition makes creating UIKit code easier and faster since we can preview in realtime our changes.

To use this new feature we just need to add the following at the bottom of our ViewController.swift file. This uses the new macro features to creates a preview canvas that instantiate a copy of our view controller

#Preview {
    ViewController()
}

Now you will have this white iPhone on your right.

But wait, we just added two UI components to our ViewController, why aren’t they visible? This is because we need to tell the view controller where we want to place them in the View. to achieve this we need to use a nifty tool called Auto Layout.

Adding constraints to our UI elements

We have to elements loaded on memory now it’s time to define where in the view they will be and add them to the current View.

To make our process of adding these elements to the current view lets create a simple extension, place it in the UIExtensions file.

extension UIStackView {
    func addArrangedSubviews(_ views: [UIView]) {
        views.forEach {
            self.addArrangedSubview($0)
        }
    }
}

To make Auto Layout to work on our UI elements we need to remember to set translatesAutoresizingMaskIntoConstraints to false.

Now it’s time to add and configure how the UI will be displayed on the View.

To make this process easy, let’s make a method that will do this for us. Inside the ViewController class we need to add the following functions.

func configureView() {
        view.backgroundColor = .systemBackground
        view.addSubviews([button, label])
        configureConstraints()
    }
    
    func configureConstraints() {
        let buttonConstraints = [
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64),
            label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16)
        ]
        NSLayoutConstraint.activate(buttonConstraints)
    }

Understanding Auto Layout

When creating user interfaces in iOS under UIKit, Auto Layout is used to calculate the size and position of views based on the constraints we specify.

The code above establishes rules for placing a button and a label within their container view, centering the button and positioning the label near the top and stretching it from side to side. These constraints ensure that the UI elements are correctly laid out across different devices and orientations.

Setting Up the Scene

Here is a small analogy that I hope can help you to understand better the Auto Layout code:

Imagine you’re arranging furniture in a room (the view), with a chair (button) and a painting (label). You want these items to be placed according to specific rules:

Centering the Chair:
- button.centerXAnchor.constraint(equalTo: view.centerXAnchor):
  - Align the chair’s center with the room’s horizontal center.
- button.centerYAnchor.constraint(equalTo: view.centerYAnchor):
  - Align the chair’s center with the room’s vertical center.
Positioning the Painting:
- label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64):
  - Place the top of the painting slightly below the top of the safe area (like giving it some space from the ceiling).
- label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16):
  - Set the painting’s left edge a bit away from the room’s left wall.
- label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16):
  - Set the painting’s right edge a bit away from the room’s right wall.

Applying the Rules

NSLayoutConstraint.activate(buttonConstraints):
- This activates the constraints, like finalizing the arrangement and instructing the system to place the furniture accordingly.

Remeber to call configureView() inside viewDidLoad or this code will never execute!

Now you can get your UI in the Canvas, congratulations!

If run the app and try to press the button nothing interesting will happen, let’s fix that next!.

Creating the Second Screen

The second screen will contain a Form that will ask for certain date to the user, this form is a great way to introduce reusable UIView

Creating the Reusable Field View

To make our reusable view we need to create a UIView.

Create a new Swift file and call it FormSectionView.swift, inside that file let’s create our class that inherit from UIView (all views in UIKit inherit from this class).

final class FormSectionView: UIView {
    // Our code will be here
}

Our View needs a way to communicate internal information outward and to receive information from the outside. To solve this problem we have several common methods in UIKit:

Delegation
Closures
Notification Center

In this example let’s explore using closures.

Creating the communication path

To receive information we need a closure that returns the information from the outside when this changes.

To send information we need to send the information as the closure parameter so the outside world can get and manipulate this information.

For our app we are receiving and sending text from this View.

Let’s define the communication path, inside FormSectionView class define the following variables.

var textDidChange: ((String) -> Void)?
    
var sectionTitle: (() -> String)? {
    didSet {
        sectionLabel.text = sectionTitle?()
    }
}

Here is what the code is doing:

Understanding the `textDidChange` Closure

Purpose: This property is a closure that takes a string as input and performs an action with no return value (Void). It’s designed to execute when text data changes, allowing for dynamic responses to user input or programmatic changes.
Usage: You use textDidChange to update other components of your application when the user modifies the text in a UITextField. This closure provides a way to react immediately to changes, facilitating actions like validation, interface updates, or data transformations without needing additional delegation or observation mechanisms.

Dynamic Title Setting with `sectionTitle`

Purpose: sectionTitle is a closure that, when called, returns a String representing the title of a section. It’s used to dynamically provide text for UI labels.
Behavior on Change (didSet): The didSet observer attached to sectionTitle automatically updates the sectionLabel.text each time the closure’s value is set or updated. The safe call sectionTitle?() ensures that the closure is only called if it’s not nil, preventing runtime errors.
Practical Use: This property can be particularly useful in adaptive UIs where the section title might change based on user interactions or other application logic. By tying the label text directly to a closure, you maintain flexibility and reduce the need for explicit refresh or update calls throughout your codebase.

Creating the UI elements

You may have noticed that the code inside the didSet failed because we didn’t add any UI to our UIView. Let’s fix that by adding the UI elements from this View.

As you remember, we extended some UI elements to create some preconnfigured objects, this will come handy in this class too.

Inside FormSectionView class add the following elements.

private lazy var sectionLabel: UILabel = .makeSimpleLabel(
        text: "No Text Received, sectionTitle not set.",
        textAlignment: .natural,
        font: .systemFont(ofSize: 24, weight: .semibold)
    )
    
    private lazy var sectionTextField: UITextField = .makeSimpleTextField(delegate: self)

These are the two elements we need to make our view, as before we also need to use Auto Layout to position them on the screen and add the elements so the View knows about them, to do that add this code at the bottom of the file.

private extension FormSectionView {
    func configureView() {
        addSubviews([sectionLabel, sectionTextField])
        configureConstraints()
    }
    
    func configureConstraints() {
        let sectionLabelConstraints = [
            sectionLabel.topAnchor.constraint(equalTo: topAnchor),
            sectionLabel.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionLabel.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let sectionTextFieldConstraints = [
            sectionTextField.topAnchor.constraint(equalTo: sectionLabel.bottomAnchor),
            sectionTextField.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionTextField.trailingAnchor.constraint(equalTo: trailingAnchor),
            sectionTextField.bottomAnchor.constraint(equalTo: bottomAnchor)
        ]
        
        let constraints = sectionLabelConstraints + sectionTextFieldConstraints
        
        NSLayoutConstraint.activate(constraints)
        
    }
    
}

In ViewControllers we usually place the configuration in viewDidLoad but since this is a View, we don’t have that life cycle so we need to use a normal init. Add the following code to the class.

override init(frame: CGRect) {
    super.init(frame: frame)
    configureView()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

In UIKit, the required init?(coder: NSCoder) initializer is a crucial component of the view and view controller initialization process when they are being instantiated from storyboards or XIB files.

To finalize our view we need a way to know when the text in the UITextField change, to achieve this we can use a delegate of this class. This is way we set this View as the delegate of the custom UITextField.

Add the following extension at the end of the file.

extension FormSectionView: UITextFieldDelegate {
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
        guard let currentText = textField.text,
              let textRange = Range(range, in: currentText) else { return false }
        
        let updatedText = currentText.replacingCharacters(in: textRange, with: string)
        textDidChange?(updatedText)
        return true
    }
}

Function textField(_:shouldChangeCharactersIn:replacementString:): This delegate method is called whenever the user types a character, deletes a character, or pastes content into the text field. It asks the delegate (in this case, FormSectionView) if the specified text should be changed.

Inside the Function

Parameters:

textField: The text field containing the text.
range: The range of characters to be replaced.
string: The replacement string that is typed or pasted into the text field.

Guard Statement:

Checks if it can obtain the current text of the text field and convert the NSRange to a Range<String.Index> suitable for Swift string operations.
If it can’t, it returns false, preventing the change to the text field’s content.

Updating Text:

updatedText: A new string is created by replacing the characters within the specified range with the new string.
This is done using replacingCharacters(in:with:), which handles the text replacement safely, considering character encoding and composition.

Closure Call:

textDidChange?(updatedText): If the textDidChange closure is set, it’s called with the updatedText. This allows the class to react to text changes, potentially updating models, views, or triggering other logic.

Return Value:

Returns true to allow the text change to proceed. If you return false, the text field would not update its display to reflect the new text.

Previewing the View

As before, we can preview our View thanks to the canvas.

Add the following code at the end of the file to activate the Preview.

#Preview(traits: .sizeThatFitsLayout) {
    FormSectionView()
}

Here is our view!

Creating the Form View using the Reusable View component

It’s time to create the Form View that will be present in the view controller, thanks to the reusable view we can simplify the creation of this view.

Create a new Swift file called TrainerFormView.swift and add the following code.

import UIKit

final class TrainerFormView: UIView {

}

Next, let’s add the UI elements we need for this.

Add the following inside the class.

private lazy var headerTitle: UILabel = .makeSimpleLabel(
        text: "Trainer Form",
        font: .preferredFont(forTextStyle: .extraLargeTitle)
    )
    
    private lazy var formStack: UIStackView = .makeSimpleStack(axis: .vertical)
    
    private lazy var saveButton: UIButton = .makeSimpleButton(
        title: "Save Trainer Data",
        action: saveAction
    )

The button’s action saveAction will mark an error, we need to define this action. As before let’s create a private extension and add the action.

private extension TrainerFormView {
    var saveAction: UIAction {
        UIAction { [weak self] action in
            guard let self else { return }
            self.saveButtonAction?(self.trainerData)
        }
}

And add the following property inside the class, we are using this tuple as a way to store the current state of the entered data, this represents an instance of our model.

private var trainerData: TrainerInfo = .init(id: UUID(), name: "Name", favoritePokemon: "Pokemon")

Adding the custom fields to the stack

Stacks are a great way to add elements in a ordered way. In our case we are using them to store the custom text fields.

Let’s configure the stack with the UI we need.

Inside private extension TrainerFormView add the following function.

func configureStack() {
    let nameSection = FormSectionView()
    nameSection.sectionTitle = { "Trainer Name" }
    nameSection.textDidChange = { [weak self] text in
        self?.trainerData.name = text
    }
    
    let pokemonSection = FormSectionView()
    pokemonSection.sectionTitle = { "Favorite Pokémon"}
    pokemonSection.textDidChange = { [weak self] text in
        self?.trainerData.favoritePokemon = text
    }
    
    formStack.addArrangedSubviews([nameSection, pokemonSection])
    
    formStack.spacing = 16
}

Here we are setting the closure for communication, passing the text name and receiving the input data to then store it the tuple we have in this View.

Adding constraints

So far our elements cannot be rendered in the View because we still need to add them. As usual we need to set the Auto Layout for these elements, add the following function inside private extension TrainerFormView.

func configureConstraints() {
    let headerTitleConstraints = [
        headerTitle.topAnchor.constraint(equalTo: topAnchor),
        headerTitle.leadingAnchor.constraint(equalTo: leadingAnchor),
        headerTitle.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]   
    
    let formStackConstraints = [
        formStack.topAnchor.constraint(equalTo: headerTitle.bottomAnchor, constant: 32),
        formStack.leadingAnchor.constraint(equalTo: leadingAnchor),
        formStack.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]
    
    let saveButtonConstraints = [
        saveButton.topAnchor.constraint(equalTo: formStack.bottomAnchor, constant: 32),
        saveButton.heightAnchor.constraint(equalToConstant: 48),
        saveButton.leadingAnchor.constraint(equalTo: leadingAnchor),
        saveButton.trailingAnchor.constraint(equalTo: trailingAnchor)
    ]
    
    let viewConstraints = headerTitleConstraints + formStackConstraints + saveButtonConstraints
    
    NSLayoutConstraint.activate(viewConstraints)
}

Adding the init

To make all this work we need to add the init and call the configuration functions, like in the previous UIView we need to add the following to the class.

override init(frame: CGRect) {
    super.init(frame: frame)
    addSubviews([headerTitle, formStack, saveButton])
    configureConstraints()
    configureStack()
}

required init?(coder: NSCoder) {
    fatalError("init(coder:) has not been implemented")
}

If you don’t add the subviews before the constraints the simulator will crash.

Previewing the result

As normal, we can preview the view by using the canvas. Add the following code at the end of the file.

#Preview(traits: .sizeThatFitsLayout) {
    TrainerFormView()
}

Here is the final View!

Creating the FormViewController

The View Form is read, now we need a Controller that manages it!, it’s time to create our FormViewController.

Add a new file called FormViewController.swift and add the following code.

import UIKit

class FormViewController: UIViewController {

}

Adding the View

We could create a factory that help us to create the Views but this time let’s use a simple closure that returns the View.

inside the class add the following UI element (the view we just created).

lazy var trainerForm: TrainerFormView = {
        let form = TrainerFormView()
        return form
    }()

We also need a way to communicate the result of our View Form to any parent view controller, to achieve this we are using again a closure with the data received from the view.

Add this to the class.

var saveAction: ((TrainerInfo) -> Void)?

As always we need to add the view (we could override the default view also) and set the constraints, here we are also setting the closure that will receive the data from the View.

This closure will call the closure of our ViewController and send the information to the next object that needs this information.

The dismiss is used to pop this view from the screen.

Usually we have two way of presenting screens in iOS:

With a Push

With a Modal

To do that add this function to the class.

private func configureView() {
    trainerForm.translatesAutoresizingMaskIntoConstraints = false
    
    trainerForm.saveButtonAction = { [weak self] trainerData in
        self?.saveAction?(trainerData)
        self?.dismiss(animated: true)
    }
    
    view.addSubview(trainerForm)
    
    NSLayoutConstraint.activate([
        trainerForm.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16),
        trainerForm.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
        trainerForm.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16),
        trainerForm.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor, constant: -16)
    ])
}

Wiring up the ViewController

To finish this ViewController just call the functions inside the viewDidLoad.

override func viewDidLoad() {
    super.viewDidLoad()
    view.backgroundColor = .systemBackground
    configureView()
}

As always you can also add a Preview, add at the end of the file.

#Preview {
    FormViewController()
}

Congratulations, you have the second view controller ready to use!

Next step is to present it from the first view controller and setting up the communication path.

Presenting the form

Open ViewController.swift and let’s modify the button action. Locate the var buttonAction: UIAction computed proerty and let’s modify it to have this code instead.

var buttonAction: UIAction {
        UIAction { [weak self] action in
            let formViewController = FormViewController()
            formViewController.saveAction = { [weak self] trainerData in
                self?.label.text = trainerData.description
            }
            self?.present(formViewController, animated: true)
        }
    }

Here, we are updating the UIAction, we are creating the controller we want to present and configure its closure. then we use the present() method to present modally the view controller.

In the closure we are receiving the data every time we press the button Save Trainer Data in the FormViewController. We are using this data to update the label in this ViewController.

By doing this change the app is ready.

Press run and let’s test it!

Testing the final app

Here is a video of the resulting app.

Congratulations, you made it to the end!

Conclusion

In this blog post, we’ve explored the benefits of programmatic UIKit development in iOS 17, showcasing the power and flexibility of bypassing storyboards to create dynamic user interfaces directly in code. By delving into practical examples—from configuring the project environment to creating reusable components and leveraging the SwiftUI canvas for real-time previews—we have demonstrated how a UIKit app can be constructed from the ground up with clarity and precision.

The ability to preview UIViews and ViewControllers within Xcode enhances development by providing immediate visual feedback, a feature that significantly streamlines the process of building and refining user interfaces. Moreover, our dive into the creation of reusable components not only promotes cleaner, more maintainable code but also fosters a modular approach to UI development that can be easily adapted or expanded upon.

By the end of our project, we effectively utilized closures and extensions to keep our codebase efficient and readable, and demonstrated the seamless flow of data between views, emphasizing the robustness of UIKit in handling complex user interactions.

As iOS continues to evolve, embracing these programmatic techniques provides a solid foundation for both new and experienced developers to build sophisticated and responsive apps. Whether you are transitioning from storyboards or enhancing your existing skills, the insights from this tutorial will undoubtedly aid in your journey towards mastering programmatic UIKit development. Happy coding! 🚀

Appendix

Here are the full code separated by files:

Controllers

`ViewController`

final class ViewController: UIViewController {
    
    // MARK: - UI Elements
    private lazy var button: UIButton = .makeSimpleButton(title: "Add Trainer Data", action: buttonAction)
    private lazy var label: UILabel = .makeSimpleLabel()

    // MARK: - ViewController Life Cycle
    override func viewDidLoad() {
        super.viewDidLoad()
        // To show the title I need a navigation controller initialized
        title = "Trainer Log"
        configureView()
    }


}

// MARK: - Private Methods
private extension ViewController {
    
    var buttonAction: UIAction {
        UIAction { [weak self] action in
            let formViewController = FormViewController()
            formViewController.saveAction = { [weak self] trainerData in
                self?.label.text = trainerData.description
            }
            self?.present(formViewController, animated: true)
        }
    }
    
    func configureView() {
        view.backgroundColor = .systemBackground
        view.addSubviews([button, label])
        configureConstraints()
    }
    
    func configureConstraints() {
        let buttonConstraints = [
            button.centerXAnchor.constraint(equalTo: view.centerXAnchor),
            button.centerYAnchor.constraint(equalTo: view.centerYAnchor),
            label.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 64),
            label.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            label.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16)
        ]
        NSLayoutConstraint.activate(buttonConstraints)
    }
}

`FormViewController`

class FormViewController: UIViewController {
    
    var saveAction: ((TrainerInfo) -> Void)?
    
    private lazy var trainerForm: TrainerFormView = {
        let form = TrainerFormView()
        return form
    }()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .systemBackground
        configureView()
    }
    
    private func configureView() {
        trainerForm.translatesAutoresizingMaskIntoConstraints = false
        
        trainerForm.saveButtonAction = { [weak self] trainerData in
            self?.saveAction?(trainerData)
            self?.dismiss(animated: true)
        }
        
        view.addSubview(trainerForm)
        
        NSLayoutConstraint.activate([
            trainerForm.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16),
            trainerForm.leadingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.leadingAnchor, constant: 16),
            trainerForm.trailingAnchor.constraint(equalTo: view.safeAreaLayoutGuide.trailingAnchor, constant: -16),
            trainerForm.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor, constant: -16)
        ])
    }

}

Extensions

import UIKit

extension UIView {
    /// Add the array of subviews to the current View
    /// - Parameter views: The views to add
    func addSubviews(_ views: [UIView]) {
        views.forEach {
            self.addSubview($0)
        }
    }
}

extension UIStackView {
    func addArrangedSubviews(_ views: [UIView]) {
        views.forEach {
            self.addArrangedSubview($0)
        }
    }
}

extension UIButton {
    static func makeSimpleButton(title: String, action: UIAction) -> UIButton {
        let button = UIButton()
        button.setTitle(title, for: .normal)
        button.addAction(action, for: .touchUpInside)
        button.configuration = UIButton.Configuration.filled()
        button.translatesAutoresizingMaskIntoConstraints = false
        return button
    }
}

extension UILabel {
    static func makeSimpleLabel(
        text: String = "",
        textAlignment: NSTextAlignment = .center,
        font: UIFont = .preferredFont(forTextStyle: .body)
    ) -> UILabel {
        let label = UILabel()
        label.textAlignment = textAlignment
        label.text = text
        label.font = font
        label.translatesAutoresizingMaskIntoConstraints = false
        return label
    }
}

extension UIStackView {
    static func makeSimpleStack(axis: NSLayoutConstraint.Axis ) -> UIStackView {
        let stack = UIStackView()
        stack.axis = axis
        stack.translatesAutoresizingMaskIntoConstraints = false
        return stack
    }
}

extension UITextField {
    static func makeSimpleTextField(delegate: (any UITextFieldDelegate)?) -> UITextField {
        let textField = UITextField()
        textField.borderStyle = .roundedRect
        // Don't forget to add delegate to call the function that sends data back
        textField.delegate = delegate
        textField.translatesAutoresizingMaskIntoConstraints = false
        return textField
    }
}

Views

`TrainerFormView`

import UIKit

final class TrainerFormView: UIView {
    
    private var trainerData: TrainerInfo = .init(id: UUID(), name: "Name", favoritePokemon: "Pokemon")
    
    var saveButtonAction: ((TrainerInfo) -> Void)?
    
    private lazy var headerTitle: UILabel = .makeSimpleLabel(
        text: "Trainer Form",
        font: .preferredFont(forTextStyle: .extraLargeTitle)
    )
    
    private lazy var formStack: UIStackView = .makeSimpleStack(axis: .vertical)
    
    private lazy var saveButton: UIButton = .makeSimpleButton(
        title: "Save Trainer Data",
        action: saveAction
    )

    override init(frame: CGRect) {
        super.init(frame: frame)
        // If you don't add the subviews before the constraints the simulator will crash
        addSubviews([headerTitle, formStack, saveButton])
        configureConstraints()
        configureStack()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

private extension TrainerFormView {
    
    func configureConstraints() {
        let headerTitleConstraints = [
            headerTitle.topAnchor.constraint(equalTo: topAnchor),
            headerTitle.leadingAnchor.constraint(equalTo: leadingAnchor),
            headerTitle.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let formStackConstraints = [
            formStack.topAnchor.constraint(equalTo: headerTitle.bottomAnchor, constant: 32),
            formStack.leadingAnchor.constraint(equalTo: leadingAnchor),
            formStack.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let saveButtonConstraints = [
            saveButton.topAnchor.constraint(equalTo: formStack.bottomAnchor, constant: 32),
            saveButton.heightAnchor.constraint(equalToConstant: 48),
            saveButton.leadingAnchor.constraint(equalTo: leadingAnchor),
            saveButton.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let viewConstraints = headerTitleConstraints + formStackConstraints + saveButtonConstraints
        
        NSLayoutConstraint.activate(viewConstraints)
    }
    
    var saveAction: UIAction {
        UIAction { [weak self] action in
            // If I don't safe unwrap self this wont work because trainerData despite not being optional
            // by the weak self it becomes optional when accessing via self?. .
            guard let self else { return }
            self.saveButtonAction?(self.trainerData)
        }
    }
    
    func configureStack() {
        let nameSection = FormSectionView()
        nameSection.sectionTitle = { "Trainer Name" }
        nameSection.textDidChange = { [weak self] text in
            self?.trainerData.name = text
        }
        
        let pokemonSection = FormSectionView()
        pokemonSection.sectionTitle = { "Favorite Pokémon"}
        pokemonSection.textDidChange = { [weak self] text in
            self?.trainerData.favoritePokemon = text
        }
        
        formStack.addArrangedSubviews([nameSection, pokemonSection])
        
        formStack.spacing = 16
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    TrainerFormView()
}

`FormSectionView`

import UIKit

final class FormSectionView: UIView {
    
    var textDidChange: ((String) -> Void)?
    
    var sectionTitle: (() -> String)? {
        didSet {
            sectionLabel.text = sectionTitle?()
        }
    }
    
    private lazy var sectionLabel: UILabel = .makeSimpleLabel(
        text: "No Text Received, sectionTitle not set.",
        textAlignment: .natural,
        font: .systemFont(ofSize: 24, weight: .semibold)
    )
    
    private lazy var sectionTextField: UITextField = .makeSimpleTextField(delegate: self)
    
    override init(frame: CGRect) {
        super.init(frame: frame)
        configureView()
    }
    
    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }
    
}

private extension FormSectionView {
    func configureView() {
        addSubviews([sectionLabel, sectionTextField])
        configureConstraints()
    }
    
    func configureConstraints() {
        let sectionLabelConstraints = [
            sectionLabel.topAnchor.constraint(equalTo: topAnchor),
            sectionLabel.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionLabel.trailingAnchor.constraint(equalTo: trailingAnchor)
        ]
        
        let sectionTextFieldConstraints = [
            sectionTextField.topAnchor.constraint(equalTo: sectionLabel.bottomAnchor),
            sectionTextField.leadingAnchor.constraint(equalTo: leadingAnchor),
            sectionTextField.trailingAnchor.constraint(equalTo: trailingAnchor),
            sectionTextField.bottomAnchor.constraint(equalTo: bottomAnchor)
        ]
        
        let constraints = sectionLabelConstraints + sectionTextFieldConstraints
        
        NSLayoutConstraint.activate(constraints)
        
    }
    
}

extension FormSectionView: UITextFieldDelegate {
    func textField(_ textField: UITextField, shouldChangeCharactersIn range: NSRange, replacementString string: String) -> Bool {
        guard let currentText = textField.text,
              let textRange = Range(range, in: currentText) else { return false }
        
        let updatedText = currentText.replacingCharacters(in: textRange, with: string)
        textDidChange?(updatedText)
        return true
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    FormSectionView()
}

Model

`TrainerInfo`

import Foundation

struct TrainerInfo: Identifiable {
    let id: UUID
    var name: String
    var favoritePokemon: String
}

extension TrainerInfo: CustomStringConvertible {
    var description: String {
        "Trainer \(name) likes \(favoritePokemon)"
    }
}

SceneDelegate modified function

func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let windowScene = (scene as? UIWindowScene) else { return }
        let viewController = ViewController()
        let navigationController = UINavigationController(rootViewController: viewController)
        window = UIWindow(windowScene: windowScene)
        window?.rootViewController = navigationController
        window?.makeKeyAndVisible()
    }

An Introductory Example of Deeplinking in iOS

Sat, 13 Jan 2024 16:22:55 +0000

Hello everyone. Lately, I’ve been experimenting with deep links and SwiftUI.

In the realm of iOS development, deep linking emerges as a powerful and indispensable tool, offering developers the means to seamlessly connect users to specific content or features within their applications.

At its core, deep linking allows for the precise navigation to a particular section of an app, rather than merely launching the app’s home screen.

Understanding the fundamentals of iOS deep linking is pivotal for enhancing user experience, promoting user engagement, and, ultimately, unlocking the full potential of your mobile applications.

In today’s tutorial, we’re going to create a simple iOS app with several screens and configure the deeplinking mechanism to access and send data to those parts of our app.

So, grab your coding gear, fire up Xcode, and let’s create a new iOS project!

Deeplinking App Example

Configuring our project to handle deep links

The first step is related to some configuration that will allow deep links to work in our app. To do this configuration, follow the steps below:

Open your Xcode project file.
Select your target.
Select the Info tab.
Expand URL Types section.
Press the + button to add a new URL Type
Fill in the Identifier and Schema

The Identifier is used to uniquely identify your app in the system, so it’s a good idea to use your reverse domain and the name of your app. The URL Schema is the url used to access your app from other parts of the system, normally we use it as yourschema://action?param1=val1&param2=val2.

Creating the Data Model

Let’s continue with the creation of an enum that will handle the shape of our data. In this app we have 3 Views that are coordinated with a TabView, so we could define 3 possible states for each one and use the power of enums to define the data state for each view.

Let’s create a file called DeepLink.swift and inside add the following code:

import Foundation

// define the deep link options and associated tag value for each view in the tab view
enum DeepLink {
    case first
    case second
    case third
    
    var tag: Int {
        switch self {
        case .first: 1
        case .second: 2
        case .third: 3
        }
    }
    
    var action: String {
        switch self {
        case .first: "first"
        case .second: "second"
        case .third: "third"
        }
    }
    
    var icon: String {
        switch self {
        case .first: "1.lane"
        case .second: "2.lane"
        case .third: "3.lane"
        }
    }
    
    var title: String {
        self.action.capitalized
    }
}

extension DeepLink {
    static let scheme = "deeplink"
}

The enum contains the three cases we discussed earlier and returns the specific data needed for each view in each computed property. Finally, we’re adding a static property to store the scheme we will be accepting in our app. By doing this we can avoid problems when typing the different strings, and it also serve us as a single source of truth for our data.

Creating the Views

Let’s continue working on the Views we are going to access via deep links. These are simple views that will display a text, the last one will accept data from outside.

Create the files FirstView.swift, SecondView.swift, ThirdView.swift, then add the following code to each file respectively:

// Add this to FirstView.swift
import SwiftUI

struct FirstView: View {
    var body: some View {
        ZStack {
            Color.green
                .ignoresSafeArea()
            Text("First")
                .font(.largeTitle)
                .fontWeight(.bold)
        }
    }
}

#Preview {
    FirstView()
}

// Add this to SecondView.swift
import SwiftUI

struct SecondView: View {
    var body: some View {
        ZStack {
            Color.yellow
                .ignoresSafeArea()
            Text("Second")
                .font(.largeTitle)
                .fontWeight(.bold)
        }
    }
}

#Preview {
    SecondView()
}

// Add this to ThirdView.swift
import SwiftUI

struct ThirdView: View {
    let message: String?
    
    var body: some View {
        ZStack {
            Color.orange
                .ignoresSafeArea()
            VStack {
                Text("Third")
                    .font(.largeTitle)
                    .fontWeight(.bold)
                Text(message ?? "No message")
                    .font(.headline)
            }
        }
    }
}

#Preview {
    ThirdView(message: "Hello World")
}

Now let’s add the TabView that will handle the navigation between the three views. We are going to reuse the ContentView.swift file to do this. Open it and replace the code inside with this:

/*
 To test the deep links you can use Safari and enter the url with the schema and action defined here
 
 example:
 
 [Schema]   [Action]  [query variables]
 deeplink://first
 deeplink://second
 deeplink://third
 deeplink://third?msg=Hello%20from%20Safari
 */

import SwiftUI

struct ContentView: View {
    // our deep link will change this variable
    @State private var selectedTab: Int = DeepLink.first.tag
    // Stores the message sent from the deep link
    @State private var message: String? = nil
    
    var body: some View {
        TabView(selection: $selectedTab) {
            FirstView()
                .tabItem { Label(DeepLink.first.title, systemImage: DeepLink.first.icon) }
                .tag(DeepLink.first.tag) // we use the tag to navigate in the TabView
            SecondView()
                .tabItem { Label(DeepLink.second.title, systemImage: DeepLink.second.icon) }
                .tag(DeepLink.second.tag)
            ThirdView(message: message)
                .tabItem { Label(DeepLink.third.title, systemImage: DeepLink.third.icon) }
                .tag(DeepLink.third.tag)
        }
        .tint(.black)
        .onAppear { // Styling the TabBar
            let appearance = UITabBarAppearance()
            appearance.backgroundEffect = UIBlurEffect(style: .systemUltraThinMaterial)
            appearance.backgroundColor = UIColor(.white.opacity(0.6))
            UITabBar.appearance().standardAppearance = appearance
            UITabBar.appearance().scrollEdgeAppearance = appearance
        }
        .onOpenURL { url in // handling the deep link
            print("URL: \(url)")
            handleIncomingURL(url)
        }
    }
}

private extension ContentView {
    /// Handles the incoming URL and performs validations before acknowledging.
    private func handleIncomingURL(_ url: URL) {
        // Check that the scheme is the one for our app.
        guard url.scheme == DeepLink.scheme else {
            return
        }
        
        // Checking the URL contains valid components and saving them in a new variable.
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: true) else {
            print("Invalid URL")
            return
        }
        
        // From the components we are getting the URL host, in our case this equals the actions for our deep links.
        guard let action = components.host else {
            print("No action found")
            return
        }
        
        // Setting the data for the given action
        switch action {
        case DeepLink.first.action:
            selectedTab = DeepLink.first.tag
        case DeepLink.second.action:
            selectedTab = DeepLink.second.tag
        case DeepLink.third.action:
            selectedTab = DeepLink.third.tag
            // For the 3rd View we can accept data, we are getting all the data from the query's first element,
            // we could check for specific variable if needed.
            if let messageValue = components.queryItems?.first?.value {
                message = messageValue
            }
        default:
            print("Invalid action")
        }
    }
}

#Preview {
    ContentView()
}

The focus point of the above code is in the modifier .onOpenURL, we are using it to handle the upcoming URL from the deeplink. To handle this url we are defining a function that extracts the information and sets the appropriate data state for our views.

We may want to create a ViewModel for handling the data update and retrieval and make our Views reusable.

Testing the App

To test the deep links we could use different approaches, from using the terminal to third party apps. To keep this simple let’s use Safari inside the iOS simulator.

Open Safari and in the search bar enter the deeplink URL, we have three valid states:

deeplink://first
deeplink://second
deeplink://third?msg=Hello%20from%20Safari, here the msg query is optional, and you could send any data here.

Here is the app running:

Conclusion

And that’s a wrap on our introduction into iOS deep linking with SwiftUI! We’ve covered the ins and outs, from setting up the project to creating views and handling deep links seamlessly. Now armed with this knowledge, we’re ready to level up our iOS app game. So, dive in, experiment, and enjoy implementing deep linking for a more engaging user experience! Happy coding!

A Simple Full-Stack iOS App Example

Tue, 09 Jan 2024 18:04:28 -0800

One of the benefits of using Swift is its excellent performance and low memory footprint. This is a key point when doing backend programming.

The future of Swift in Linux looks promising. With Swift 5.9, there will be better error logging, and Apple is developing a new open-source cross-platform testing framework with swift-testing that will replace XCTest and works on Linux too.

Let’s hope this encourages more backend systems to be written in Swift.

In this tutorial, we’ll explore how to code a backend in Vapor and establish its connection to a simple iOS app. I hope this example serves as a good starting point for learning about the interaction between mobile and backend systems.

Getting Started: Tech Stack Overview

Backend

Some mobile developers prefer using auto-managed backend solutions like Firebase and may not pay much attention to the server side. Nevertheless, I believe that understanding the basic programming and concepts used in the backend can enhance your comprehension of the entire system. This understanding enables us to create solutions that are not only more efficient but also better integrated.

Framework

Backend programming is a complex topic with various frameworks in the market. In the Swift world, the most widely used backend framework is Vapor.

Vapor is an excellent solution for building backend systems. It utilizes a non-blocking, event-driven architecture built on top of Apple’s SwiftNIO. This offers us great performance, allowing us to create complex systems that scale well.

Keep in mind that some third-party services may not have a ready-to-use Swift/Vapor API. This can introduce additional complexity when integrating these services.

Database

For the database, we are using PostgreSQL. This database is an open-source relational database and offers great performance with a lot of useful features for any needs we could have.

To install and run our database, we are going to use Docker with a docker-compose file. This is great because we can start a database in seconds and allows us to replicate our configuration in different environments.

App

We use SwiftUI with modern concurrency (async/await), implementing a Network layer to manage requests, and follow the MVVM architecture to organize our code.

This approach enables us to delve into modern iOS development, providing insights into how all elements interconnect and respond to changes.

Coding the Backend

Installing docker

Let’s start our project by installing docker, we need it to create the database and the container for our vapor app.

We can use Homebrew to install it via the terminal, or just get it from the Docker site.

If you decide to use Homebrew, we need to have brew installed and run the following command on the terminal:

brew install --cask docker

Open Docker and let’s continue.

Creating and running the database

To set up our PostgreSQL database, we’ll need to create a docker-compose.yml file and define its configuration. Follow these steps:

Create a file named docker-compose.yml in your project directory.
Add the following configuration to the docker-compose.yml file:

version: '3'

services:
  postgres:
    image: postgres:latest
    container_name: postgres
    restart: always
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: postgres
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    ports:
      - '5432:5432'
    networks:
      - fullstack-ios-net

volumes:
  postgres_data:

  networks:
    fullstack-ios-net:
        driver: bridge

volumes will tell Docker to create the persistance layer with the given name for us, so we don’t need to specify any directory.

Open a terminal in the directory containing the docker-compose.yml file.
Run the following command to start the database container:

docker-compose -p database-vapor up -d

You can change the container name by replacing database-test with your preferred name. The -d flag runs the container in detached mode, freeing up the terminal.

This will create a running database locally, ready for us to use in our backend.

To confirm that the database is running, execute the command docker ps in your terminal. Alternatively, you can check Docker Desktop if it is installed on your system.

Since we are running separate containers for the database and the vapor app, we need to get the network in which the database is attached, to do so let’s run:

docker network ls

In my case, the network created for this container is called database-vapor_fullstack-ios-net. We’ll use this network for the vapor app, so keeps your network name saved.

To check the containers attached to a network run: docker network inspect <network_name/ID>.

To delete a network run the command: docker network rm <network_name/ID>.

Here’s an example of the resulting database running on my system:

Creating the Vapor Container

Let’s move on to the exciting part – building our Vapor app. For this process, we’ll leverage a development container with VSCode, a fantastic tool that helps maintain a clean local environment and ensures reproducibility for every project.

Feel free to adjust this according to your style and preferences!

Follow these steps to create your empty vapor container:

Create a root directory for the vapor container.
Inside the root directory, create a new directory called .devcontainer.
Inside .devcontainer, create a new file called devcontainer.json and add the following:

{
    "name": "Vapor",
    "image": "swift:latest",
    "runArgs": [
        "--name=vapor-local-devcontainer",
        "--network=database-vapor_fullstack-ios-net"
    ],
    "postCreateCommand": "bash .devcontainer/vaporinstall.sh",
    "customizations": {
        "vscode": {
            "extensions": [
                "sswg.swift-lang",
                "streetsidesoftware.code-spell-checker"
            ]
        }
    }
}

We are adding this container to the same network as the database, this will allow communication between the two containers.

Create the Vapor installation script vaporinstall.sh file inside the .devcontainer directory.
Add the following to vaporinstall.sh:

#!/bin/bash

echo "Vapor installation is starting"

# Updating and installing packages
apt update && apt upgrade -y
apt install -y make

# Installing Vapor
git clone https://github.com/vapor/toolbox.git
cd toolbox
make install
cd ..
rm -rf toolbox

echo "Vapor installation was successful"

Open the project in VSCode and then select the option Reopen in Container.

To check Vapor is installed, run in a terminal vapor --version.

This will create the container and install vapor inside, you’re ready to code the backend in Vapor!

Finally, let’s check that both containers are under the same network, run this command in the host terminal:

docker network inspect database-vapor_fullstack-ios-net | grep -A 20 "Containers"

There you can check that our two containers are listed in the output under "Containers", we’re good to continue.

Creating a barebone Vapor App

It’s time to create our app inside the container, this is a simple task thanks to the integrated vapor tools:

Run in the container’s terminal the following:

vapor new temperature-api -n

-n will create a barebone project

Enter the new directory cd temperature-api
Run the project swift run

Congratulations, now your Vapor app is up and running. To verify that it works as expected you can check the root endpoint / in the URL mentioned in the terminal, usually http://127.0.0.1:8080/

Creating the Model for the Database

Let’s start by codding the Model that will represent our table!

This step is crucial because we are modeling our problem and it’s important that we discuss this thoroughly to get a model that efficiently defines our data and allow us to have a simple and performant representation of the problem’s data.

This is a really simple app, so we are just storing a given temperature and a related date. Since this is simple to model we’re going to use a simple table containing these values and a unique identifier for each new value.

Installing `Fluent` and `Postgres Driver`

We’re going to use an ORM to communicate with our database, this is a great tool that allow us to stay in Swift when making queries, models and relationships. In our case we decided to use Fluent and a Postgres Driver.

To install them, follow the next steps:

Open Package.swift
Add the following lines in the dependencies array:

  .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"),
  .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"),

Add the following inside the second dependencies array, nested inside targets:

.product(name: "Fluent", package: "fluent"),
.product(name: "FluentPostgresDriver", package: "fluent-postgres-driver"),

If you’re using a different database look into Fluent documentation to find an appropriate driver.

Your Package.swift should look similar to this:

// swift-tools-version:5.9
import PackageDescription

let package = Package(
    name: "temperature-logger",
    platforms: [
       .macOS(.v13)
    ],
    dependencies: [
        // 💧 A server-side Swift web framework.
        .package(url: "https://github.com/vapor/vapor.git", from: "4.83.1"),
        .package(url: "https://github.com/vapor/fluent.git", from: "4.8.0"), // added
        .package(url: "https://github.com/vapor/fluent-postgres-driver.git", from: "2.8.0"), //added
    ],
    targets: [
        .executableTarget(
            name: "App",
            dependencies: [
                .product(name: "Vapor", package: "vapor"),
                .product(name: "Fluent", package: "fluent"), // added
                .product(name: "FluentPostgresDriver", package: "fluent-postgres-driver") //added
            ]
        ),
        .testTarget(name: "AppTests", dependencies: [
            .target(name: "App"),
            .product(name: "XCTVapor", package: "vapor"),

            // Workaround for https://github.com/apple/swift-package-manager/issues/6940
            .product(name: "Vapor", package: "vapor"),
        ])
    ]
)

These new packages will be automatically added to our project.

Creating our Temperature model

The models we define in this step will be used to create the tables in our database.

Create a new file called Temperature.swift in the following path: Sources/App/Models/
Add the following code:

import Vapor
import Fluent

final class Temperature: Model, Content {
    static let schema: String = "temperatures"

    @ID
    var id: UUID?

    @Field(key: "temperature")
    var temperature: String

    @Field(key: "date")
    var date: String

    init() { }

    init(id: UUID? = nil, temperature: String, date: String) {
        self.id = id
        self.temperature = temperature
        self.date = date
    }
}

The property wrappers are defined in Fluent and let us mark the different roles for our database, the names inside @Field are used to represent the name of the columns in the table. The schema at the top will be used as the table name in our database.

Excellent, we have our schema defined.

Connecting the Postgres Database to our Vapor App

Oru next goal is to connect our database to our vapor app and create the schema for our system.

Creating the Migration file

Migrations serve the purpose of defining and applying changes to the database schema. A migration is essentially a set of instructions that describe how to evolve the database structure, creating or modifying tables and their columns.

To create our own migration file follow the next steps:

Create the file CreateTemperature.swift in the path: Sources/App/Migrations/
Add the following code:

// To run migrations, call `swift run App migrate` from the command line

import Fluent

struct CreateTemperature: AsyncMigration {
    func prepare(on database: Database) async throws {
        try await database.schema("temperatures")
            .id()
            .field("temperature", .string, .required)
            .field("date", .string, .required)
            .create()
    }
    
    func revert(on database: Database) async throws {
        try await database.schema("temperatures")
            .delete()
    }
}

The prepare function is part of the migration and specifies what changes to make to the database when applying the migration. In simple terms, it says:

Create a new table named ’temperatures'.
Add an ‘id’ column (which is typically an identifier for each row in the table).
Add a ’temperature’ column of type ‘string’ that is required.
Add a ‘date’ column of type ‘string’ that is also required.
Ensure that all these changes are applied to the database.

The revert function is part of the migration and specifies how to undo the changes made by the prepare function. In simple terms, it says:

Delete the ’temperatures’ table from the database.

Setting-up the Postgres Database

We need to configure the credentials for our Postgres database. To do this we need to open the file configure.swift inside the path: Sources/App/.

Add the packages needed at the top of the file:

import Fluent
import FluentPostgresDriver

Add the following code at the top inside the configure function:

The data for these credentials are defined in the docker-file of the database. If you’re hosting your database in a system other than localhost, use your URL in place of localhost.

// defining the postgres configuration object
let databaseConfiguration = SQLPostgresConfiguration(
    hostname: "localhost",
    username: "user",
    password: "password",
    database: "postgres",
    tls: .disable
)

// applying the configuration
app.databases.use(
    .postgres(configuration: databaseConfiguration), as: .psql
)

// Adding our migration object
app.migrations.add(CreateTemperature())

// Optional, make the logger more verbose
app.logger.logLevel = .debug

Your configuration.swift should look similar to this:

import Vapor
import Fluent
import FluentPostgresDriver

// configures your application
public func configure(_ app: Application) async throws {
    // uncomment to serve files from /Public folder
    // app.middleware.use(FileMiddleware(publicDirectory: app.directory.publicDirectory))

    // defining the postgres configuration object
    let databaseConfiguration = SQLPostgresConfiguration(
        hostname: "localhost",
        username: "user",
        password: "password",
        database: "postgres",
        tls: .disable
    )

    // applying the configuration
    app.databases.use(
        .postgres(configuration: databaseConfiguration), as: .psql
    )

    // Adding our migration object
    app.migrations.add(CreateTemperature())

    // Optional, make the logger more verbose
    app.logger.logLevel = .debug


    // register routes
    try routes(app)
}

Now stop the app and run the following commands to apply the migrations and get the database connected.

# Stop the project by pressing CTRL + C
swift run App migrate # to start migration

Creating the endpoints

We’re about to finish the backend for our iOS app. This backend is quite simple, it will expose a GET method that will return all the stored temperatures in the database and a post method that will allow us to save a temperature sent from our iOS app.

Since we are only using two endpoints we can add this logic to the file routes.swift, found in the path temperature-api/Sources/App/.

Open the file and add the following modules:

import Fluent
import FluentPostgresDriver

Next, inside the routes function, delete all its body and add this:

 app.get("temperatures") { req async throws in
    app.logger.info("Temperatures GET received.")
    return try await Temperature.query(on: req.db).all()
}

app.post("temperatures") { req async throws -> Temperature in
app.logger.info("Temperature POST request received.")
    let temperature = try req.content.decode(Temperature.self)
    try await temperature.create(on: req.db)
    return temperature
}

Your routes.swift file should look like this:

import Vapor
import Fluent
import FluentPostgresDriver


func routes(_ app: Application) throws {
     app.get("temperatures") { req async throws in
        app.logger.info("Temperatures GET received.")
        try await Temperature.query(on: req.db).all()
    }

    app.post("temperatures") { req async throws -> Temperature in
        app.logger.info("Temperature POST request received.")
        let temperature = try req.content.decode(Temperature.self)
        try await temperature.create(on: req.db)
        return temperature
    }
}

GET Route for “temperatures”:

When the server receives a GET request at the path "/temperatures", it logs an informational message saying "Temperatures GET received.".
It then attempts to retrieve all temperature records from the database asynchronously using try await Temperature.query(on: req.db).all().

POST Route for “temperatures”:

When the server receives a POST request at the path "/temperatures", it logs an informational message saying "Temperature POST request received.".
It then tries to decode the request’s content into a Temperature model object using let temperature = try req.content.decode(Temperature.self).
After decoding, it attempts to create a new temperature record in the database asynchronously with try await temperature.create(on: req.db).
Finally, it returns the created Temperature object as a response.

Congratulations, you’ve finished your backend using Vapor!

Run it with swift run and let’s test it!

Testing our backend

For testing our backend I’m using Postman.

First let’s try the GET, since the database is empty it should return an empty array [].

Now let’s test the POST by adding some data.

Finally, let’s check GET again to verify we get the new stored data from the DB.

Great, our backend is working as expected.

Let’s continue with the iOS app, great work!

Coding the iOS App

Let’s start our iOS app that will connect to our vapor backend.

One of the most used design patters for SwiftUI is MVVM, this stands for Model, View and ViewModel.

Model: Represents the application’s data and business logic. It is responsible for managing and manipulating the data, as well as enforcing business rules.

View: Represents the user interface and is responsible for displaying data to the user. It observes changes in the ViewModel and updates accordingly. In some implementations, the View may also handle user input and pass it to the ViewModel.

ViewModel: Acts as an intermediary between the Model and the View. It contains the presentation logic and transforms the data from the Model into a form that can be easily displayed by the View. The ViewModel often exposes properties and commands that the View can bind to.

The key point is that the ViewModel doesn’t tell the view what to do; it just receives queries from the view. When the data is ready, it notifies the subscribers, mostly views, about the changes. Then, the views that get the notifications can act accordingly with the new data received.

Let’s create a new iOS SwiftUI project in Xcode to continue, we could name it Temperatures App or anything you like.

Creating the Model

Let’s start with the Model, this model would be quite similar to the one in our backend.

Let’s create a new Group called Models and inside this group create a new file called Temperature.swift.

import Foundation

struct Temperature: Codable, Identifiable {
    var id: UUID = UUID()
    var temperature: String = ""
    var date: String = ""
}

This is the model our app will use when creating new temperatures locally. The code acts similarly to the one in the backend; we define a new ID for each new temperature and store the temperature and date for that measurement.

We use Identifiable to make every temperature object uniquely identifiable. This is useful in the SwiftUI ForEach view.

The Codable protocol guarantees that our data can be encoded and decoded, in our case, to and from JSON.

Creating the Network Layer

The network layer is next; this layer will handle the communication with the server.

Creating the Request Protocol

Let’s start by defining a protocol that will tell us the public API for a network request. The network request will handle all the information needed by the network service to perform its work.

Create a new group called Networking and inside create a new file called NetworkRequestProtocol.swift. Then add this code:

import Foundation

protocol NetworkRequestProtocol {
    var url: URL { get }
    var method: String { get }
    var headers: [String: String]? { get }
    var body: Data? { get }
}

As mentioned before, these are the elements we will need to pass to the network manager to be able to send requests to our backend:

The URL of our backend.
The type of HTTP method we want to use.
The headers for our requests.
The body of our request in case of POST.

Creating the Temperature Request

Now let’s conform to this protocol. Create a new file called TemperatureRequest.swift in the Networking group and add the following code:

import Foundation

enum TemperatureRequest: NetworkRequestProtocol {
    case post(temperature: Temperature)
    case get

    var url: URL {
        switch self {
        case .get: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        case .post: URL(string: "http://localhost:8080/temperatures") ?? URL(string: "https://apple.com")!
        }
    }

    var method: String {
        switch self {
        case .get: "GET"
        case .post: "POST"
        }
    }

    // no matter the selected case we always return the same header
    var headers: [String : String]? {
        ["Content-Type": "application/json"]
    }

    var body: Data? {
        switch self {
        case .get: nil
        case .post(let temperature): try? JSONEncoder().encode(temperature)
        }
    }

}

We’re making this app simple, so we are not defining custom errors.

enums are great for handling our network request parameters. Here, TemperatureRequest conforms to NetworkRequestProtocol. This is great because we can change our request object with a different one by only conforming to the same protocol. This helps to lower code coupling and improves testability.

The code itself configures the GET and POST method data. In the case of POST, we send the Temperature object and convert it into a proper JSON type for our backend. The rest of the code is self-explanatory.

Creating the Network Service Protocol

As mentioned before, protocols are a great way to lower coupling in code and help with testability because we can create mock objects that can simplify our tests for different parts of the code.

Let’s create a new file called NetworkServiceProtocol.swift in the Networking group and add this code:

import Foundation

protocol NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data
}

As before, we are defining the public API for this object. In this case, we only have one function that will execute the request using the request data we pass.

Creating the Network Service

The Network service is the final component we need to implement in our Network layer. This object is responsible for doing the actual communication with the backend. To configure our request, we pass a TemperatureRequest object with the parameters we need.

In the same Networking group, create a new file called NetworkService and add the following code:

import Foundation

struct NetworkService: NetworkServiceProtocol {
    func execute(request: NetworkRequestProtocol) async throws -> Data {
        // configuring the request
        var urlRequest = URLRequest(url: request.url)
        urlRequest.httpMethod = request.method
        urlRequest.allHTTPHeaderFields = request.headers
        urlRequest.httpBody = request.body

        // performing the request, we wait for the server response
        let (data, _) = try await URLSession.shared.data(for: urlRequest)
        
        // returning the data from the server
        return data
    }
}

In simpler terms the code above does the following:

Implementing the protocol NetworkServiceProtocol
execute function: takes a NetworkRequestProtocol as a parameter and performs a network request to our backend.
URLRequest setup: Inside the execute function, a URLRequest is created using information from the provided NetworkRequestProtocol, such as the URL, HTTP method, headers, and request body.
Network request: The function then uses URLSession.shared to perform an asynchronous network request based on the constructed URLRequest. It awaits the response and extracts the obtained data.
Return data: Finally, the obtained data is returned from the function.

Notice that this layer is not responsible of converting the json data to the proper type for our app.

Creating the View Model

To create the View Model, we need to create a new group called ViewModels and inside this new group create a new file called TemperaturesViewModel.swift. Add the following code to this file:

import Foundation

@MainActor // Runs this code in the main thread to avoid updating the UI outside of it.
final class TemperatureViewModel: ObservableObject {
    @Published private(set) var temperatures: [Temperature]
    private let networkService: NetworkServiceProtocol
    
    // Injecting dependencies
    init(temperatures: [Temperature] = [], networkService: NetworkServiceProtocol) {
        self.temperatures = temperatures
        self.networkService = networkService
    }
    
    /// POST a new temperature to the backend.
    func addTemperature(temperature: String, date: String) async {
        let newTemperature = Temperature(temperature: temperature, date: date)
        let request = TemperatureRequest.post(temperature: newTemperature)
        do {
            let _ = try await networkService.execute(request: request)
        } catch {
            print("Error adding temperature")
        }
    }
    
    /// GET all stored temperatures in the backend.
    func getTemperatures() async {
        let request = TemperatureRequest.get

        // perform request
        do {
            let data = try await networkService.execute(request: request)

            // decode data
            guard let decodedData = decodeData(data: data) else { return }
            print(decodedData)
            // saving data on published var
            temperatures = decodedData
        } catch {
            print("Some error in get")
        }
    }
}

// MARK: - Helper private functions
private extension TemperatureViewModel {
    func decodeData(data: Data) -> [Temperature]? {
        do {
            return try JSONDecoder().decode([Temperature].self, from: data)
        } catch {
            print("Error decoding temperatures")
            return nil
        }
    }
}

This code may seem complex, but in reality, it is just doing two things: sending data back to the server and getting data from the server. This happens in the methods addTemperature and getTemperatures.

Then we are publishing the values with @Published private(set) var temperatures: [Temperature], so any object that subscribes to updates can get a notification for changes in this variable. Notice the private(set), this allows read-only access to the value.

All of this is handled in the main thread to avoid updating the UI in a different thread by marking the object with @MainActor.

addTemperature function: This function is responsible for sending a new temperature to the backend using a POST request:

It creates a new Temperature object with the provided temperature and date.
It creates a TemperatureRequest for a POST request, encapsulating the new temperature data.
It tries to execute the request asynchronously using the networkService.
If an error occurs during the request execution, it catches the error and prints an error message.

getTemperatures function: This function is responsible for fetching all stored temperatures from the backend using a GET request:

It creates a TemperatureRequest for a GET request.
It tries to execute the request asynchronously using the networkService.
If the request is successful, it decodes the received data into an array of Temperature objects using the decodeData function.
It prints the decoded data and assigns it to the temperatures property, which is likely a @Published property that updates the UI when changed.
If an error occurs during the request execution, it catches the error and prints an error message.

Creating the Views

Now it’s time to see something on our phone’s screen. Let’s create a new group called Views. Here, we are going to add all the views for our app.

The system will have two views: one for creating new temps and the other for viewing the current temperatures stored in our system. To manage the navigation of these two views, we are going to use a tab navigation style. Since the tab view doesn’t have a title, we’re going to use a title view that will help us to name our screens. This also allows us to customize the screens to our liking.

So, let’s create these three SwiftUI files inside Views. Let’s call them:

RootView.swift: Our tab view will be here.
PostTemperaturesView.swift: It will display a simple UI to send the data to the server.
GetTemperaturesView.swift: It will display a simple table with the temperatures from the server.
TitleView.swift: A helper view that will display the title of the current view.

Creating `TitleView`

The easiest view for this app is the TitleView. It will be a simple view that displays formatted text on the screen.

Add this code to TitleView.swift:

import SwiftUI

struct TitleView: View {
    let title: String

    var body: some View {
        Text(title)
            .font(.largeTitle)
            .fontWeight(.bold)
            .padding()
    }
}

#Preview(traits: .sizeThatFitsLayout) {
    TitleView(title: "Custom Title")
}

In this view we are just applying some font styles to the given title.

Creating `PostTemperaturesView`

This view will present the user with a button and two fields for the temperature and date. We are implementing some extremely basic validation that will disable the button if both text fields are empty. In a production app, we should validate against edge cases and be more thoughtful.

Add the following code to PostTemperaturesView.swift:

import SwiftUI

struct PostTemperaturesView: View {
    @State private var temperature = Temperature()
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        ZStack {
            VStack {
                TitleView(title: "Post your temperature")
                Divider()
                Spacer()
            }
            VStack {
                inputSection()
                    .padding()
                buttonSection()
            }
        }
    }
}

#Preview {
    PostTemperaturesView()
}

private extension PostTemperaturesView {
    
    /// Checks if the temperature components are empty or not.
    var invalidTemperatureData: Bool {
        temperature.date.isEmpty || temperature.temperature.isEmpty ? true : false
    }
    
    /// Based on the validity of the temperature object, it returns a specific color.
    var buttonBackground: Color {
        invalidTemperatureData ? .gray : .red
    }
    
    func inputSection() -> some View {
        VStack(spacing: 20) {
            TextField("Temperature", text: $temperature.temperature)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
            TextField("Date", text: $temperature.date)
                .padding()
                .background(.gray.opacity(0.2))
                .clipShape(RoundedRectangle(cornerRadius: 15.0))
        }
        .frame(width: 130, height: 120)
        .padding()
        .overlay(
            RoundedRectangle(cornerRadius: 25.0)
                .stroke(.red, lineWidth: 3)
        )
    }

    func buttonSection() -> some View {
        Button {
            Task {
                await temperatureViewModel.addTemperature(
                    temperature: temperature.temperature,
                    date: temperature.date
                )
            }

        } label: {
            Text("POST Temperature")
                .foregroundStyle(.white)
                .frame(maxWidth: .infinity, maxHeight: .infinity)
        }
        .disabled(invalidTemperatureData)
        .frame(width: 230, height: 60)
        .background(buttonBackground)
        .clipShape(RoundedRectangle(cornerRadius: 25.0))
    }
}

Since we are not reusing any of the sub-views, I decided to implement them in private functions. This helps to lower the code complexity since all sub-views will have direct access to the parent view properties.

To call async functions in our views, we need to create an asynchronous context. To do that, we use Task { ... }. Inside a task, we can call our async functions from the view model. The main advantage of this is that we don’t block our UI by waiting for the response.

The rest of the code is self-descriptive thanks to the declarative aspect of SwiftUI.

Creating `GetTemperaturesView`

Since we need to get the current data from the server, I’m attaching a .task action that executes every time the view is rendered. This will download the most up-to-date data from the server. Then we will display this information in a formatted table.

In production apps, it’s important to manage possible errors and inform the users visually about the current state of the task. For this small app, we are not managing that aspect.

import SwiftUI

struct GetTemperaturesView: View {
    @EnvironmentObject private var temperatureViewModel: TemperatureViewModel

    var body: some View {
        VStack {
            TitleView(title: "Recorded Temperatures")
            Divider()
            List {
                ForEach(temperatureViewModel.temperatures) { temp in
                    row(temperature: temp)
                }
            }
            .listStyle(.plain)
            .task {
                await temperatureViewModel.getTemperatures()
            }
        }
    }
}

#Preview {
    GetTemperaturesView()
        .environmentObject(TemperatureViewModel(networkService: NetworkService())) // needed for the preview not to crash
}

private extension GetTemperaturesView {
    func row(temperature: Temperature) -> some View {
        VStack {
            Text("Date: \(temperature.date)")
            Text("Temperature: \(temperature.temperature) \u{2103}")
        }
    }
}

As before, thanks to the declarative nature of SwiftUI, the code is self-explanatory.

Creating `RootView`

Finally, let’s piece together all the views and complete our UI.

This last part is quite simple to implement, thanks to the way SwiftUI works. Add the following code to the file RootView.swift:

import SwiftUI

struct RootView: View {
    var body: some View {
        TabView {
            PostTemperaturesView()
                .tabItem { Label("POST", systemImage: "square.and.arrow.up") }
            GetTemperaturesView()
                .tabItem { Label("GET", systemImage: "square.and.arrow.down") }
        }
        .tint(.red) // change button color in tab
    }
}

#Preview {
    RootView()
        .environmentObject(TemperatureViewModel( networkService: NetworkService()))
}

Here we are creating the tab view and assigning the post and get views we created early in this tutorial.

Configuring the Environment Object

You may have noticed that some of our views need an Environment object. In the preview, the app works well, but if you try to run it, the app will crash because we are only injecting this object into the preview context. Let’s fix that now.

Open the entry point app file. It’s the one named as your app and contains the attribute @main.

Inside the struct, let’s add the view model we will be observing:

@StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

Next let’s change our View entry point to the RootView we just created, and inject the environment object. This will allow access to the ViewModel to RootView and all of its sub-views.

We’re also attaching an initial get to our backend, this will get us an up to date temperatures each time our app starts.

WindowGroup {
            RootView() // change to our RootView
                .environmentObject(temperatureViewModel) // inject the ViewModel
                .task { // When open the app, perform an initial GET to the server.
                    await temperatureViewModel.getTemperatures()
                }
        }

Your file should look like something like this, (your struct may have a different name):

import SwiftUI

@main
struct temperature_logger_App: App {
    @StateObject private var temperatureViewModel = TemperatureViewModel(networkService: NetworkService())

    var body: some Scene {
        WindowGroup {
            RootView()
                .environmentObject(temperatureViewModel)
                .task {
                    await temperatureViewModel.getTemperatures()
                }
        }
    }
}

Congratulations! You just finished the app!

Testing the App

To test the app, you need to have the Vapor app and the database containers running. Verify that they are up and running.

Now, let’s run the app on the simulator and add some temperatures. Then, check the list to see how they update in real-time!

You can also view the logs in our Vapor app to see the requests we are receiving from our app.

Conclusion

In concluding our exploration of building a full-stack iOS application, the versatility of Swift has truly shone through. Swift not only excels in crafting engaging iOS applications but also seamlessly extends its capabilities to backend development, as demonstrated by the integration with the Vapor framework.

The collaboration between the iOS app and the Vapor backend illustrates the straightforward nature of Swift in the development landscape. The use of Docker for containerization further streamlined the setup, enabling a hassle-free configuration of a PostgreSQL database synchronized with the Vapor app. This amalgamation of Swift, Docker, and Vapor reflects the smooth interplay of modern development tools.

This experience emphasizes Swift’s adaptability, not just in the iOS environment but also in Linux setups, where it effortlessly integrates and collaborates with container technologies like Docker. Swift emerges as a pragmatic choice for end-to-end development.

As we wrap up the journey of creating a full-stack iOS application, it’s worth acknowledging Swift’s role in orchestrating various technologies. It showcases how Swift fosters a developer-friendly environment, encouraging innovation and blurring the lines between frontend and backend development. Here’s to the practicality of Swift and the possibilities it unlocks in the ever-evolving landscape of software development!

Replacing Elements in a String

Mon, 09 Oct 2023 19:15:49 -0600

One of the most common problems we face when working with strings is modifying certain characters in the string.

This problem can be easily solved with the use of regular expressions (regex).

Before Swift 5.7

If you can’t uae the newest Swift you can achieve this by using the method replacingOccurrences(of:with:options).

Here is an example of its use:

let s = "12abc34"
let t = ss.replacingOccurrences(
    of: "[a-z]", // regex
    with: "",
    options: .regularExpression
)
// output: "1234"

If we want to do the opposite (i.e., to keep everything but lowercase letters), we can use the symbol ^ to invert the expression set.

let s = "12abc34"
let t = ss.replacingOccurrences(
   of: "[^a-z]", // regex
   with: "",
   options: .regularExpression
)
// output: "abc"

After Swift 5.7

If we have access to a newer version of swift, you can use a simpler method to achieve the same result: replacing(_:with:maxReplacements:).

let s = "12abc34"
let t = s.replacing(/[a-z]/, with: "")
// output: "1234"

As before, we can use ^ to obtain the inverse result:

let s = "12abc34"
let t = s.replacing(/[^a-z]/, with: "")
// output: "abc"

Conclusion

Regular expressions are quite powerful and can help us to solve problems with a simple predicate that describes what the want to obtain.

Regex may seems hard to grasp at first, but we can start with little examples like these to gain experience with this useful tool.

SwiftUI – Horizontal Pages Carousel

Wed, 27 Sep 2023 01:44:33 -0600

Horizontal page carousels are a common element in iOS interfaces for presenting pages in a horizontal, swipeable format.

They are particularly useful for showcasing views with varying content.

Code

In SwiftUI, creating such elements is straightforward.

Let’s define a SwiftUIView and use the following code:

import SwiftUI

struct PageSliderView: View {
    
    // the data we want to present in each page,
    // this can be as simple as an array of string or as complex as an array of compound views.
    let pages = ["One", "Two", "Three"]
    
    var body: some View {
        TabView {
            ForEach(pages, id: \.self) {
                Text("Page \($0)")
                    .font(.title)
            }
        }
        .tabViewStyle(PageTabViewStyle()) // set the tab view behaviour to page
        .indexViewStyle(PageIndexViewStyle(backgroundDisplayMode: .always)) // set the dot indicator to be visible
    }
}

#Preview {
    PageSliderView()
}

The code above showcases one of the advantages of declarative UI frameworks, where you describe what you want instead of instructing the computer how to do it.

This approach results in expressive and concise code.

Result

The outcome is impressive, especially when you consider the minimal code required.

Conclusion

SwiftUI is a powerful tool that enables us to focus on describing the UI. With just a few lines of code, we can achieve results that would necessitate significantly more code in UIKit.

Swift copy-on-write

Mon, 25 Sep 2023 01:30:20 -0600

To understand what copy-on-write means we need to delve into Swift’s type classification.

Objects in Swift can be divided into two type groups: value types and reference types.

The main difference between the two is how they are managed in memory. Theoretically, Value types create a new copy on memory each time they are assigned to a new variable, conversely reference types share the same reference amongst all variables.

What is copy-on-write?

This is a technique used to manage the copy of objects efficiently.

When we create a new assignment of a variable that holds a type supporting copy-on-write, the actual duplication of the data only occurs when there is a modification to the data through its references (data mutation).

This mechanism also occurs when we initialize or pass them as arguments.

This technique allow us to improve performance and reduce the use of costly copy operations.

In essence, we are postponing the allocation and copying of data in memory until we actually need it.

How does this affect Swift?

We mentioned that, in Swift, value types are copied to a new memory region when we assign them to variables (copy semantics). This is partially true for built-in value-types and for custom types where we implement this functionality.

The whole process involves the extra step of copy-on-write mechanism that allows us to reduce unnecessary memory allocations, making the entire process more efficient and performant.

Copy and move semantics is a complex topic and it’s out of the scope of this post, in simple terms here are some definitions of them:

Copy semantics means that when you pass or assign an object, you create a new copy of that object’s data.

Move semantics means that when you pass or assign an object, you transfer the ownership of that object’s data to another object.

This means that every time we make a new assignment, the copy allocation is delayed until we modify the actual data (mutation). This implies that at certain times, our value types can refer to the same memory region, behaving as reference types.

Does all value types uses copy-on-write in Swift?

We have this behaviour for free in Collection types: Arrays, Sets, Dictionaries, and Strings.

For custom value types, we need to manually implement it using the function isKnownUniquelyReferenced(_:). Apple provides guidance on how to apply this mechanism here.

Code example

To demonstrate this functionality let’s use an Array collection:

/// Prints the address of the given array
/// - Parameter bytes: the array pointer
func printAddress(_ bytes: UnsafeRawBufferPointer) {
    print(NSString(format: "%p", Int(bitPattern: bytes.baseAddress)))
}

var nums1 = [1,2,3]
var nums2 = nums1 // copying

nums1.withUnsafeBytes(printAddress) // 0x60000170c0e0
nums2.withUnsafeBytes(printAddress) // 0x60000170c0e0

nums2.append(4)

nums1.withUnsafeBytes(printAddress) // 0x60000170c0e0
nums2.withUnsafeBytes(printAddress) // 0x60000210c6b0 (copy-on-write happens)

In the above code we can observe how the copy-on-write delays the duplication on a different memory location until we made some changes to the underlying data.

Warning: There was a change in the Swift 5.3 compiler that made the withUnsafeBytes (_:) method of String internal, meaning that it can only be accessed within the same module as the String type. Meaning this way of printing addresses won’t work for Strings.

Another example: Passing collections to functions

Let’s explore passing collections as arguments in functions.

By default, when we pass a type to a function this is immutable by default (it cannot be changed). This improves the predictability and safety of our code.

Another consequence of this immutability in function’s parameters is the use of copy-on-write. Since we cannot mutate our value types, no memory copy occurs and we get a reference to the same value. This helps to avoid unnecessary cpu and memory work.

Let’s demonstrate this fact with the following code.

/// Prints the address of the given array
/// - Parameter bytes: the array pointer
func printAddress(_ bytes: UnsafeRawBufferPointer) {
    print(NSString(format: "%p", Int(bitPattern: bytes.baseAddress)))
}

/// A functions that receives an array as argument and prints its memory address and content.
/// - Parameter array: the array being passed.
func foo(_ array: [Int]) {
    array.withUnsafeBytes(printAddress)
    print(array)
}

var nums = [1, 2, 3]

nums.withUnsafeBytes(printAddress) // 0x6000017001a0

foo(nums) // 0x6000017001a0 (same memory address)

The previous code shows that the data we get inside the function is the same as the one being passed. This indicates the use of copy-on-write.

This is great from a performance point of view because we don’t need to optimize the memory copy for built-in types.

In the case of custom value types, the copy does occur if we don’t add the copy-on-write functionality manually.

Advantages and disadvantages

The use of copy-on-write can be a great way to reduce memory usage by having several references to the same object in memory, this also helps with performance when we use it in data that rarely change and is shared across several parts.

Conversely, it can be hard to implement for our custom types, specially if our types are complex. This can limit the applicability of this technique by adding complexity to our code.

Conclusion

Copy-on-write is a great way to improve memory management and boost performance of our value types. Despite some complexities involved in its manual implementation for custom types, it’s a great tool that we need to understand to be able to write performant code when implementing low level abstractions.

Apple Development on entangledDEV

Parsing JSON with Swift

Sample JSON Payload

Create a Codable Model

Decode with JSONDecoder

Configure a Shared Decoder

Handling Optional Data

Supplying Defaults Without Optionals

What Happens to init(from:)

Modeling Enumerated Values

1. Direct String Backing

2. Mapping Backend Slugs to Expressive Cases

3. Capturing Unknown Cases

Custom Decoding Logic

Decoding Polymorphic Payloads

Mapping Nested Collections

Integrating with Legacy [String: Any] Stores

Surface Decoding Errors Clearly

Decoding with Swift Concurrency

Testing Your Decoders

Wrap Up

Handling Touch Gestures in UIKit

Long Press Gesture

Gesture States

Example

State Driven Enum Navigation

Navigating SwiftUI with an Enum Router (Cyclical A → B → C Flow) — A Simple example

Introduction

1. Defining the Router State

2. The Router Protocol & Default Implementation

3. The Navigation Container

4. The Three Views

5. How It Works

6. Pros and Cons

Pros:

Cons:

7. Conclusion

SwiftUI Generic Containers

💡 SwiftUI Tip: Wrapping Views with Generics and Closures

🚧 The Problem

🔍 The Fix: Use a Generic + Closure

🤯 But wait — doesn’t MyCoolView(param: 123) need a closure like (Int) -> some View?

🧠 What this unlocked for me

🧪 Bonus: Custom Layout Containers

📦 Usage

🤔 What’s up with where Footer == EmptyView?

💡 Why it exists:

📦 TL;DR

Working With Collections

Setting Up a Minimal UICollectionView

Creating the base view controller

Adding the collection to the view

Why we need a collectionViewLayout

Adding the data source

What’s a diffable data source

Creating the diffable data source

Configuring the data source

Creating the snapshot

Creating a custom cell

Testing the collection

Conclusion

Apendix

Configuring a Programmatic UIKit Project

Step-by-Step Guide

1. Create a New Project

2. Remove the Main Storyboard

3. Set the Root View Controller Programmatically

Using AppDelegate (iOS 12 and earlier or single-window apps)

Using SceneDelegate (iOS 13 and later)

4. Create Your Initial View Controller

5. Run the Project

Conclusion

Programmatic Tab Bar

Simple example

1. Create the Tab Bar class

2. Adding the tab bar to the app

3. Creating the View Controllers to show

4. Presenting the View Controllers in the Tab Bar

5. Run the app

Advanced Usage

What Happens to `init(from:)`

Integrating with Legacy `[String: Any]` Stores

🤯 But wait — doesn’t `MyCoolView(param: 123)` need a closure like `(Int) -> some View`?

🤔 What’s up with `where Footer == EmptyView`?

Why we need a `collectionViewLayout`

Connecting to `UIView` subclass

Connecting to `UIViewController` subclass

Connecting to `UITableViewCell` or `UICollectionViewCell` subclasses