Swift 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.

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!

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.

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.

Swift 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

Delegate Pattern in Swift

What is the Delegation Pattern?

Why Use the Delegation Pattern?

How to Implement the Delegation Pattern in Swift

Step 1: Define the Protocol

Step 2: Create the Delegator

Step 3: Implement the Delegate

Example with UITableView

Conclusion

An Introductory Example of Deeplinking in iOS

Deeplinking App Example

Configuring our project to handle deep links

Creating the Data Model

Creating the Views

Testing the App

Conclusion

A Simple Full-Stack iOS App Example

Getting Started: Tech Stack Overview

Backend

Framework

Database

App

Coding the Backend

Installing docker

Creating and running the database

Creating the Vapor Container

Creating a barebone Vapor App

Creating the Model for the Database

Installing Fluent and Postgres Driver

Creating our Temperature model

Connecting the Postgres Database to our Vapor App

Creating the Migration file

Setting-up the Postgres Database

Creating the endpoints

Testing our backend

Coding the iOS App

Creating the Model

Creating the Network Layer

Creating the Request Protocol

Creating the Temperature Request

Creating the Network Service Protocol

Creating the Network Service

Creating the View Model

Creating the Views

Creating TitleView

Creating PostTemperaturesView

Creating GetTemperaturesView

Creating RootView

Configuring the Environment Object

Testing the App

Conclusion

Replacing Elements in a String

Before Swift 5.7

After Swift 5.7

Conclusion

Swift copy-on-write

What is copy-on-write?

How does this affect Swift?

Does all value types uses copy-on-write in Swift?

What Happens to `init(from:)`

Integrating with Legacy `[String: Any]` Stores

Installing `Fluent` and `Postgres Driver`

Creating `TitleView`

Creating `PostTemperaturesView`

Creating `GetTemperaturesView`

Creating `RootView`