One of the most effective ways to improve the user experience of an iOS app is by utilizing features that feel native and familiar to the user. A perfect example of this is the Context Menu.

You are likely already familiar with this interaction: when you long-press an app icon on your iPhone’s home screen, a menu pops up offering shortcuts like "Rename," "Edit Home Screen," or "Remove App." Despite being a standard iOS behavior that users expect, many developers forget to implement it in their own applications.

The good news is that implementing Context Menus in SwiftUI is incredibly simple and provides significant value with very little code.

How It Works

A Context Menu is triggered by a long-press gesture. When activated, the system automatically handles the complex UI transitions for you: it blurs the background, brings the selected view into focus (often with a slight zoom), and displays a list of actions.

Implementation

To add this feature, you simply use the .contextMenu modifier on any view. This modifier accepts a ViewBuilder closure where you can define the contents of the menu.

While you can technically place various types of views inside the menu (like a static Text view for information), the best practice is to use buttons to provide actionable items.

Dynamic Content

You can also make the menu dynamic. In the example provided below, we use a @State variable to track whether an item has been "liked." The menu icon changes between a hollow heart and a filled heart depending on that state, giving the user immediate visual feedback the next time they open the menu.

struct ContentView: View {
    // 1. State variable to track the 'liked' status
    @State var liked: Bool = false

    var body: some View {
        Image("Image") // Replace with your image asset name
            .resizable()
            .frame(width: 300, height: 200)
            // 2. The Context Menu Modifier
            .contextMenu {

                // You can add static text (informational)
                Text("Information")

                // 3. Action Button: Toggles the state
                Button {
                    liked.toggle()
                } label: {
                    // Logic to swap the icon based on state
                    Label("Like", systemImage: liked ? "heart.fill" : "heart")
                }

                // 4. Standard Action Button
                Button {
                    print("Delete action triggered")
                } label: {
                    Label("Trash", systemImage: "trash")
                }
            }
    }
}

Handling Optionals is a bread-and-butter task for Swift developers. We all know the standard way to unwrap a value or provide a fallback, but things get tricky when we are dealing with String interpolation and data types that don't match (like Integers vs Strings).

In this post, we’ll look at a common friction point when printing optional values and a cleaner syntax (introduced in newer Swift versions) to handle default values without messy type-casting.

The Standard Approach: Nil-Coalescing

The most common way to handle a nil value inside a print statement is using the Nil-Coalescing Operator (??).

If you have a generic string optional, this works perfectly.

var name: String? = nil

// Standard coalescing works because both sides are Strings
print("Hello, \(name ?? "Unknown")") 

// Output: Hello, Unknown

If name has a value, it prints the name. If it is nil, it falls back to "Unknown". Simple, right?

The Problem: Type Mismatch

The issue arises when the optional variable is not a String, but you want the default fallback to be text.

Let's say you are tracking a user's age. If the age is known, you want to print the number. If it is unknown (nil), you want to print "Unknown".

Attempting to use ?? will cause a crash or compiler error here:

Swift

var age: Int? = nil

// ❌ Error: Cannot convert value of type 'Int?' to expected argument type 'String'
print("Age: \(age ?? "Unknown")")

Why does this fail?

The ?? operator expects both the left side (Int?) and the right side (String) to be of compatible types. Swift cannot magically decide that the result should be a String just because you are inside a print statement.

The Old Workaround

Previously, developers might force the default value to match the type, resulting in bad semantics. For example, defaulting to 0:

Swift

print("Age: \(age ?? 0)")
// Output: Age: 0

This is technically correct code, but logically incorrect. A user with an unknown age is not a newborn baby (0 years old).

The Solution: Interpolation with Default

There is a much cleaner way to handle this directly inside String Interpolation without needing to convert types manually or use complex if-let statements.

You can use the default: parameter directly within the interpolation structure.

Here is the updated, clean code:

var age: Int? = nil

// ✅ The Clean Way
print("Age: \(age, default: "Unknown")")

How it works:

1. If age is nil: Swift uses the value provided in the default parameter. It automatically handles the fact that "Unknown" is a String, allowing the print statement to compile successfully.

2. If age has a value (e.g., 25): It unwraps the Integer and prints "25".

// Example with a value
age = 25
print("Age: \(age, default: "Unknown")")

// Output: Age: 25

SwiftUI offers two primary components for creating resizable divisions:

•HSplitView: Used to arrange views horizontally, separated by a vertical, draggable divider. This is ideal for side-by-side content areas, such as a sidebar and a main content pane.

•VSplitView: Used to arrange views vertically, separated by a horizontal, draggable divider. This is useful for dividing a single content area into top and bottom sections.

The fundamental benefit of these components is that they automatically handle the user interaction required for resizing. By simply embedding views within an HSplitView or VSplitView, a developer instantly gains a fully functional, resizable divider.

Basic Implementation:

A simple implementation of a resizable interface involves using HSplitView to divide the application window into two distinct, adjustable sections.

For example, to create a layout with a blue panel on the left and a purple panel on the right, the structure is straightforward:

struct ContentView: View {
    var body: some View {
        HSplitView {
            // Left Panel
            Color.blue
                .frame(minWidth: 100)

            // Right Panel
            Color.purple
                .frame(minWidth: 100)
        }
    }
}

When the application runs, the user can click and drag the vertical divider between the blue and purple panels to resize them, and the views will automatically adapt to the new dimensions.

Advanced Layouts

For more complex application designs, HSplitView and VSplitView can be nested to create multi-dimensional, resizable layouts. This technique allows for both horizontal and vertical resizing within the same window.

Consider a scenario where the right-hand side of the horizontal split needs to be further divided vertically into a red and a green section. This is achieved by placing a VSplitView inside the right-hand pane of the HSplitView:

struct ComplexContentView: View {
    var body: some View {
        HSplitView {
            // Left Panel (Blue)
            Color.blue
                .frame(minWidth: 100)

            // Right Panel (Vertically Split)
            VSplitView {
                // Top-Right Panel
                Color.red
                    .frame(minHeight: 50)

                // Bottom-Right Panel
                Color.green
                    .frame(minHeight: 50)
            }
        }
    }
}

Controlling Resizing with Constraints

While the default behavior allows for free resizing, developers often need to impose limits to maintain a usable interface. This is accomplished using standard SwiftUI frame modifiers.

By applying modifiers like .frame(maxWidth: 200) to a view within a split view, you can set a maximum size for that pane. The divider will stop moving once the pane reaches this constraint, ensuring that critical content areas are not completely obscured or resized beyond a functional limit.

For instance, to ensure the left panel never exceeds 200 points in width:

HSplitView {
    Color.blue
        .frame(minWidth: 100, maxWidth: 200) // Constrained Panel

    Color.purple
        .frame(minWidth: 100) // Flexible Panel
}

The Bottleneck of Sequential await

In Swift's structured concurrency, the await keyword is used to pause the execution of the current task until the asynchronous function it calls returns a result. While this is essential for managing dependencies, using multiple sequential await calls for tasks that do not depend on each other forces the program to wait for each operation to complete before starting the next.

Consider a scenario where an application needs to fetch six independent pieces of data (simulated here by six network requests). The sequential approach looks like this:

Task { let startInstant = clock.now
    // Each 'await' pauses execution until the previous one is complete
    let joke1 = try! await requestJoke(index: 1)
    let joke2 = try! await requestJoke(index: 2)
    let joke3 = try! await requestJoke(index: 3)
    let joke4 = try! await requestJoke(index: 4)
    let joke5 = try! await requestJoke(index: 5)
    let joke6 = try! await requestJoke(index: 6)

    jokes = [joke1, joke2, joke3, joke4, joke5, joke6]
    print("Time taken = \(clock.now - startInstant)")
}

private func requestJoke(index: Int) async throws -> String { 
    let url = URL(string: "https://api.chucknorris.io/jokes/random" )! 
    let (data, _) = try await URLSession.shared.data(from: url)
    let decoded = try JSONSerialization.jsonObject(with: data, options: []) print("(index)") 
    if let dict = decoded as? [String: Any] { 
        return dict["value"] as! String 
    } 
    return "Error" 
}

In a test environment, this sequential execution took approximately 2.2 to 2.3 seconds to complete all six requests. The total time is roughly the sum of the individual request times, as they run one after the other.

Achieving True Parallelism with async let

The async let binding is designed to solve this exact problem. It allows you to declare an asynchronous value, immediately starting the task in parallel with the current execution flow. The task runs concurrently in the background, and the current task continues without pausing. You only use await later when you actually need the result of that task.

By using async let, all six network requests are initiated almost simultaneously, and the program only pauses at the final step to collect the results.

Task { let startInstant = clock.now
    // Each 'await' pauses execution until the previous one is complete
    async let joke1 = try! requestJoke(index: 1)
    async let joke2 = try! requestJoke(index: 2)
    async let joke3 = try! requestJoke(index: 3)
    async let joke4 = try! requestJoke(index: 4)
    async let joke5 = try! requestJoke(index: 5)
    async let joke6 = try! requestJoke(index: 6)

    // The 'await' here waits for all six concurrent tasks to finish
    jokes = await [try! joke1, try! joke2, try! joke3, try! joke4, try! joke5, try! joke6]
    print("Time taken = \(clock.now - startInstant)")
}

The performance improvement is dramatic. In the same test environment, the parallel execution using async let completed in approximately 1.0 to 1.1 seconds. This is a reduction of over 50% in execution time, as the total time is now dictated by the longest-running task, not the sum of all tasks.

Summary of Performance

The following table summarizes the performance difference between the two approaches:

Conclusion

For any Swift application that needs to perform multiple independent asynchronous operations, adopting async let is a straightforward and highly effective way to leverage the power of structured concurrency and achieve significant performance gains. It provides a clean, readable, and modern alternative to older techniques like DispatchGroup, ensuring your application remains responsive and efficient.

By replacing sequential await calls with async let for independent tasks, you can ensure that your application is utilizing system resources to their fullest, leading to a faster and more fluid user experience.

The video is in Portuguese but with English subtitles

This article explores the critical distinction between the .task and .onAppear view modifiers in SwiftUI, a common point of confusion and a frequent topic in iOS development interviews. While both modifiers execute code when a view is presented, their fundamental difference lies in their handling of asynchronous operations and automatic task cancellation.

1. Execution Timing: A Minor Difference

Both .onAppear and .task are triggered when the view is about to be displayed on the screen. The video demonstrates that .onAppear runs marginally before .task, but for most practical purposes, they are both executed at the view's presentation.

Example 1: Synchronous Code

For synchronous operations, both modifiers function identically.

Conceptual Code Example (Synchronous):

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .onAppear {
                // Synchronous code runs successfully
                startAnimation()
            }
            .task {
                // Synchronous code runs successfully
                startAnimation()
            }
    }

    func startAnimation() {
        print("Starting UI animation...")
        // ... animation logic ...
    }
}

2. The Core Distinction: Asynchronous Operations

The true difference emerges when dealing with asynchronous code, such as network requests or long-running background tasks.

Example 2: Asynchronous Code

The .onAppear Limitation

The closure provided to .onAppear is synchronous. Attempting to call an async function directly using await will result in a compilation error.

Conceptual Code Example (Error):

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .onAppear {
                // ❌ ERROR: 'async' call in a function that does not support concurrency
                await fetchData()
            }
    }

    func fetchData() async -> Data {
        // ... network request logic ...
        return Data()
    }
}

The .onAppear Workaround

To execute asynchronous code within .onAppear, you must manually wrap the call in a Task block.

Conceptual Code Example (Workaround):

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .onAppear {
                Task {
                    // Manual Task wrapper required
                    let data = await fetchData()
                    print("Data fetched via onAppear workaround: \(data.count) bytes")
                }
            }
    }
    // ... fetchData() async function ...
}

The .task Solution

The .task modifier is designed specifically for concurrency. Its closure is implicitly asynchronous, allowing for the direct use of await without any manual wrapping.

Conceptual Code Example (Recommended):

struct ContentView: View {
    var body: some View {
        Text("Hello, World!")
            .task {
                // ✅ Direct use of await is supported
                let data = await fetchData()
                print("Data fetched via task: \(data.count) bytes")
            }
    }
    // ... fetchData() async function ...
}

3. Automatic Cancellation: The Key Advantage of .task

The most significant benefit of using .task is its automatic cancellation feature. When a view with a .task modifier is dismissed (e.g., the user navigates back), the task is automatically cancelled by the SwiftUI framework.

If you use the Task { ... } workaround inside .onAppear, the task will not be automatically cancelled when the view disappears. This can lead to memory leaks, unnecessary background processing, and potential crashes if the task tries to update the now-deallocated view. To prevent this, you would need to manually store the Task reference and call task.cancel() within the .onDisappear modifier, which adds boilerplate code.

Best Practice Summary:

Conclusion: For any operation involving concurrency (async/await), the .task modifier is the modern, safer, and cleaner choice in SwiftUI. Use .onAppear only for simple, synchronous setup code.

The video is in Portuguese but with English subtitles.

In modern application development, providing a clear and intuitive user experience is paramount. A key aspect of this is gracefully handling moments when content is not available. Whether it's due to a failed network request, an empty search result, or a feature that requires user data to be populated, presenting a blank screen can leave users confused. With the release of iOS 17, Apple introduced ContentUnavailableView, a powerful and flexible native SwiftUI component designed to elegantly manage these empty or unavailable states. 1

This article provides a comprehensive guide on how to use ContentUnavailableView to improve your SwiftUI applications, complete with practical code examples.

What is ContentUnavailableView?

ContentUnavailableView is a specialized view that provides a standardized interface for situations where a view’s primary content cannot be displayed. It typically consists of a label (often with an icon), a descriptive text, and optional action buttons. By using this native component, developers can save time and ensure a consistent user experience across the app and the entire Apple ecosystem. 2

Basic Implementation

The simplest way to use ContentUnavailableView is by providing a title and a system image. This is ideal for conveying a simple, clear message to the user.

For example, if you have a list of items that is currently empty, you can display a message as an overlay.

import SwiftUI

struct MyItemsView: View {
    @State private var items: [String] = []

    var body: some View {
        NavigationStack {
            List(items, id: \.self) { item in
                Text(item)
            }
            .navigationTitle("My Items")
            .overlay {
                if items.isEmpty {
                    ContentUnavailableView("No Items", systemImage: "tray.fill")
                }
            }
        }
    }
}

In this code, if the items array is empty, the List will be overlaid with a centered view showing the "tray.fill" icon and the text "No Items".

Adding Descriptions and Actions

To provide more context, you can add a description and even interactive actions, such as a "Refresh" button. This is particularly useful for scenarios like network errors, where you want to give the user a way to retry the action.

ContentUnavailableView offers a more advanced initializer that uses ViewBuilder closures for the label, description, and actions.

import SwiftUI

struct ProductsView: View {
    @State private var products: [String] = []
    @State private var hasError = true

    var body: some View {
        NavigationStack {
            if hasError {
                ContentUnavailableView {
                    Label("Connection Failed", systemImage: "wifi.slash")
                } description: {
                    Text("Please check your internet connection and try again.")
                        .multilineTextAlignment(.center)
                } actions: {
                    Button("Refresh") {
                        // Add logic to refetch data
                        fetchProducts()
                    }
                    .buttonStyle(.borderedProminent)
                }
            } else {
                List(products, id: \.self) { product in
                    Text(product)
                }
                .navigationTitle("Products")
            }
        }
        .onAppear(perform: fetchProducts)
    }

    func fetchProducts() {
        // Simulate a network request
        hasError = true // or false to show content
    }
}

This example demonstrates a common use case where an error state prompts the user with a clear explanation and a direct way to resolve the issue.

Handling Search Results

Another excellent use case for ContentUnavailableView is handling empty states in a searchable list. SwiftUI provides a convenient, pre-configured version specifically for this scenario: ContentUnavailableView.search.

This static instance automatically displays a relevant message, and if you provide the search text, it will even include the user's query in the description.

import SwiftUI

struct ContactsView: View {
    @State private var allContacts = ["Alice", "Bob", "Charlie", "David"]
    @State private var searchText = ""

    var searchResults: [String] {
        if searchText.isEmpty {
            return allContacts
        } else {
            return allContacts.filter { $0.lowercased().contains(searchText.lowercased()) }
        }
    }

    var body: some View {
        NavigationStack {
            List(searchResults, id: \.self) { contact in
                Text(contact)
            }
            .navigationTitle("Contacts")
            .searchable(text: $searchText)
            .overlay {
                if searchResults.isEmpty {
                    // Shows a message like "No results for \"query\""
                    ContentUnavailableView.search(text: searchText)
                }
            }
        }
    }
}

If the user searches for a term that yields no results, this view provides immediate and helpful feedback without any need for manual text formatting.

Conclusion

ContentUnavailableView is a valuable addition to the SwiftUI framework that simplifies the process of handling empty and error states. By leveraging its basic and advanced customization options, you can create more robust, user-friendly applications that communicate clearly and effectively in any scenario. Adopting this native component not only saves development time but also ensures your app feels polished and consistent with platform standards.

O que são as High Order Function

Uma higher order function é uma função que recebe uma outra como argumento, ou uma função que retorna outra função.

Depois dessa breve introdução do que é uma High Order Function, vamos imaginar que temos um array de Ints e que precisamos pegar o numero de elementos dentro dele que são múltiplos de 2.

Antes do Swift 6

Poderíamos usar diversas formas de pegar count de elementos, usando for ou foreach mas nesse caso estou trazendo como normalmente eu fazia usando o filter. Perceba que filter retorna um array com os elemento que retornam true para condição e depois disso pegamos o nosso count.

let array = [1,2,3,4,5,6,7,8,9,10]
let count = array.filter {
    $0.isMultiple(of: 2)
}.count

Depois do Swift 6

let array = [1,2,3,4,5,6,7,8,9,10]
let count = array.count {
    $0.isMultiple(of: 2)
}

Perceba que agora no nosso count podemos passar um argumento igual no filter só que trazendo direto o count do array da condição.

Não é nada que vai mudar a nossa vida como desenvolvedor iOS drasticamente mas acho legal quando novas versões do Swift trazem facilidades pro nosso dia a dia e ajudam a remover a verbosidade do código.

O tópico que eu quero trazer aqui é na verdade o tópico sobre alocação de memória.

Alocação de memória

VStack

A VStack ela aloca todas os elementos na memória mesmo que não estejam visíveis e também não remove por nenhum motivo. Supondo que você monte uma lista com ForEach e VStack de 200 elementos, os 200 elementos estarão alocados na memória mesmo que o usuário não faça nada.

LazyVStack

A LazyVStack ela aloca na memória somente os elementos que estão sendo visto mas não remove os elementos já alocados na memória. Supondo que você monte uma lista com ForEach e VStack de 200 elementos, os 10 primeiros elementos estarão alocados na memória e o restante não, entretanto se o usuário fizer scroll até o elemento 200 a memória vai estar com os 200 elementos alocados.

List

A List ela usa o mesmo mecanismos de reutilização da TableView(saudades UIKit), ela aloca e remove os elementos, reutilizando os componentes. Supondo que você monte uma lista com ForEach e List de 200 elementos, os 10 primeiros elementos estarão alocados na memória e o restante não e se o usuário realizar o scroll vai remover da memória os elementos que ficaram não visíveis pro usuário e alocar os novos que ficaram visíveis.

Basicamente se a sua tela exibe 10 elementos a List vai deixar os 5 elementos antes e depois alocado na memória para melhorar a performance do scroll e quando damos mais alguns scrolls ela reutiliza a memória alocada para esses novos objetos sempre deixando reservado reservado um espaço de memória de 20 itens mais ou menos.

Comparação Real

VStack

Como vocês podem perceber no exemplo acima a VStack nem tinha terminado de carregar todos os elementos mas o uso da memória já estava em 2.07 GB

LazyVStack

Reparem que a LazyVStack alocou os elementos de maneira mais rápida e não consumiu memória desnecessária neste primeiro momento, entretanto basta fazer scroll para perceber que a alocação de memória só aumenta, nem fizemos tanto scroll assim e nosso uso de memória foi pra 248,8 MB, mostrando que realmente os objetos renderizados não removidos.

List

A List em um primeiro momento se parece muito com a LazyStack somente aloca os elementos visíveis na memória mas basta realizar o scroll para vermos a diferença. Fizemos o scroll até o final da lista e pasmem o uso de memória foi de apenas 129,4 MB enquanto na LazyStack um simples scroll ja aumentou consideravelmente o uso de memória

Conclusão

Não sou o dono da verdade eu acho que cada um sabe o que é melhor para usar em cada situação do seu projeto mas atualmente eu tenho feito da seguinte maneira:

• se são elementos estáticos e que não possuem scroll eu utilizo normalmente a VStack sem nenhum problema;

• se é alguma lista um pouco mais longa mas eu sei a quantidade de itens ou sei que a API retornará por exemplo um numero de itens relativamente baixo eu utilizo a LazyVStack;

• se for alguma lista com scroll infinito ou a API pode me mandar uma lista longa, sem controle de tamanho eu opto por utilizar a List mesmo sabendo que ela não é tão maleável assim.

#Unique

A nova atualização trouxe para uma macro super interessante chamada #Unique que permite a criação de uma constraint (Não sei o melhor jeito de traduzir isso rs) para múltiplos atributos. Antigamente precisávamos fazer algum workaround para termos isso.

Antigamente:

@Model final class Song {
    @Attribute(.unique)
    var nameAndSinger: String    

    var name: String
    var singer: String

    init(name: String, singer: String) {
        self.name = name
        self.singer = singer
        nameAndSinger = name + singer
    }
}

Usando o #Unique:

@Model final class Song {
    #Unique<Song>([\.name, \.singer])
    var name: String
    var singer: String

    init(name: String, singer: String) {
        self.name = name
        self.singer = singer
    }
}

Dessa forma o SwiftData nos permite criar diversos objetos com tanto que a combinação de nome e singer seja única. Podemos criar Song com name A pro Faganello e podemos criar um Song com nome A pro cantor Bruno. Uma adição que eu já foi utilizar nos meus projetos porque eu fazia a gambiarra acima para ter o mesmo resultado.

@Attribute(.preserveValueOnDeletion)

As vezes precisamos criar a famosa exclusão lógica, quem nunca fez algo parecido com isDeleted: Bool. As vezes você queria deixar parcialmente excluido por x tempos caso o usuário tenha se arrependido de apagar e com isso você de fato não apagava o registro agora é possível fazer isso nativamente com o SwiftData

@Model
final class Song {
    @Attribute(.preserveValueOnDeletion)
    var album: Album
}

if let deletion = change as? History.DefaultDeleteChange<Song> {
   data = deletion.tombstone[\.album]
}

Pra saber mais sobre esse History: Apple Doc History

Custom Schemas

Podemos agora criar Custom Schemas para nosso Container do SwiftData, isso pode ser interessante se caso você precise por exemplo salvar algo em um formato de arquivo especifico para realizar uma exportação por exemplo.

// Modo Tradicional usando o proprio Schema da Apple
var container: ModelContainer = {
        do {
            let configuration = ModelConfiguration(schema: Schema([Trip.self]), url: fileURL)
            return try ModelContainer(for: Trip.self, configurations: configuration)
        }
        catch { ... }
    }()

// Seu Scheme personalizado, nesse caso algo voltado para json
var container: ModelContainer = {
        do {
            let configuration = JSONStoreConfiguration(schema: Schema([Song.self]), url: jsonFileURL)
            return try ModelContainer(for: Song.self, configurations: configuration)
        }
        catch { ... }

@Previewable

Uma ultima coisa que gostaria de destacar aqui é que aparentemente ficará mais fácil usar o SwiftData com o preview do SwiftUI sem muitas "gambiarras" para fazerem as coisas acontecerem, podemos inserir Mock ModelContainer utilizando um parâmetro na Preview do SwiftUI e para fazer alguma busca nos modelos podemos usar o @Previewable . Acabei brincando pouco com isso até o momento até porque eu já tenho minhas gambiarras funcionando e acabei não investindo tempo nessa mudança. Segue um exemplo de como utilizar.

struct SampleData: PreviewModifier {
    static func makeSharedContext() throws -> ModelContainer {
        let config = ModelConfiguration(isStoredInMemoryOnly: true)
        let container = try ModelContainer(for: Trip.self, configurations: config)
        Trip.makeSampleTrips(in: container)
        return container
    }

    func body(content: Content, context: ModelContainer) -> some View {
        content.modelContainer(context)
    }
}

extension PreviewTrait where T == Preview.ViewTraits {
    @MainActor static var sampleData: Self = .modifier(SampleData())
}

import SwiftUI
import SwiftData

struct ContentView: View {
    @Query
    var trips: [Trip]

    var body: some View {
        ...
    }
}

#Preview(traits: .sampleData) {
    ContentView()
}

import SwiftUI
import SwiftData

#Preview(traits: .sampleData) {
    @Previewable @Query var trips: [Trip]
    BucketListItemView(trip: trips.first)
}

Como usar async let

func loadWeather(lat: Double, long: Double, index: Int) async -> Weather {
    let url = URL(string: "https://api.openweathermap.org/data/2.5/weather?lat=\(lat)&lon=\(long)&appid=*****")!
    let request = URLRequest(url: url)
    let (data, _) = try! await URLSession.shared.data(for: request, delegate: nil)
    print("Done \(index)")
    return try! JSONDecoder().decode(Weather.self, from: data)
}

Temos o nosso código para fazer uma request para nossa API de tempo e retornar nosso modelo. Adicionei um print index para ficar mais fácil a visualização mas isso não é necessário

Do jeito tradicional criaríamos uma função nos moldes a seguir

func getWeather() {
    Task {
        let saoPaulo = await loadWeather(lat: -23.5489, long: -46.6388, index: 1)
        let rio = await loadWeather(lat:  -22.9035, long: -43.2096, index: 2)
        let bahia = await loadWeather(lat: -11.4098, long:  -41.2808, index: 3)
        let tempo = [saoPaulo, rio, bahia]
    }
}

Se executamos esse código vamos perceber que o nosso log vai estar assim

Done 1
Done 2
Done 3

Se você reparar bem não existe nenhum motivo para executar essas requests em serie, uma não depende da outra e como faríamos isso com async await? Usando o novo termo async let o código ficará assim:

Task {
    async let saoPaulo = loadWeather(lat: -23.5489, long: -46.6388, index: 1)
    async let rio = loadWeather(lat:  -22.9035, long: -43.2096, index: 2)
    async let bahia = loadWeather(lat: -11.4098, long:  -41.2808, index: 3)
    let tempo = await [saoPaulo, rio, bahia]
}

Percebam que agora só temos um await e perceba que ele fica posicionado no momento em que tentamos acessar a variável em questão, nesse caso antes de criamos o nosso array.

Se executamos o código agora podemos receber diferentes tipos de log, no meu caso foi:

Done 1
Done 3
Done 2

Lembrando que só o async let só pode ser usado dentro de funções.

struct Joke: Decodable {
    let icon_url: String
    let value: String
}

func fetchRandomJoke(completion: @escaping (Joke?) -> Void) {
    let url = URL(string: "https://api.chucknorris.io/jokes/random")!

    URLSession.shared.dataTask(with: url) { data, response, error in
        if let data = data {
            if let messages = try? JSONDecoder().decode(Joke.self, from: data) {
                completion(messages)
                return
            }
        }

        completion(nil)

    }.resume()
}

O código acima está escrito da maneira "antiga" de como fazíamos requests em Swift.

Vamos supor que você está desenvolvendo uma nova feature em SwiftUI que vai utilizar a mesma request fecthRandomJoke que outras feature legadas utilizam, você pode acabar com alguns problemas:

• Async/Await tem alguns comportamentos estranhos rodando com CompletionHandler

• Pode pensar em criar 2 requests uma nova e outra legada o problema seria se o modelo mudasse com alguma frequência, você teria que alterar em 2 lugares

• Você pode editar o código legado para usar o Async/Await mas provavelmente teria que mudar em vários lugares porque o código legado estará todo em CompletionHandler

Existe salvação?

Claro! Se você pensou em criar 2 requests você quase acertou o Swift nos permite utilizar uma função chamada withCheckedContinuation para fazermos essa alteração. Veja o código a seguir:

struct Joke: Decodable {
    let icon_url: String
    let value: String
}

func fetchRandomJoke(completion: @escaping (Joke?) -> Void) {
    let url = URL(string: "https://api.chucknorris.io/jokes/random")!

    URLSession.shared.dataTask(with: url) { data, response, error in
        if let data = data {
            if let messages = try? JSONDecoder().decode(Joke.self, from: data) {
                completion(messages)
                return
            }
        }

        completion(nil)

    }.resume()
}

func fetchRandomJoke() async -> Message? {
    await withCheckedContinuation { continuation in
        fetchRandomJoke { joke in
            continuation.resume(returning: joke)
        }
    }
}

let joke = await fetchRandomJoke()
print(joke.value)

Dessa maneira mantemos somente uma request então o problema de alterar em dois lugares foi solucionado e agora você pode utilizar o novo jeito do Swift para lidar com chamadas assíncronas.

Primeiro de tudo é que não podemos confundir o SwiftData com um Banco de Dados, o SwiftData é basicamente um ORM (Mapeamento objeto-relacional (Object–relational mapping)). Para curiosidade dos demais, o banco de dados padrão do iOS é o SQLite.

SwiftData é uma framework lançada para substituir a antiga framework chamada CoreData que vem da era do Objective-C (Saudades colchetes). Mesmo seu projeto sendo em Swift/SwftUI você conseguia integrar o CoreData, mas não é uma solução nativa para essas ferramentas.

SwiftData foi introduzido no iOS 17 e não funciona nas versões abaixo, uma pena para projeto que ainda não podem migrar a versão minima.

Models

Vamos falar sobre as Models, que basicamente seriam nossas tabelas em um banco de dados relacional.

@Model class Book {
  var title: String
  var pages: Double
  var theme: String
}

Primeiro de tudo que precisamos adicionar a Macro @Model e não podemos trabalhar com Struct, temos que obrigatóriamente com as class. Basicamente esse é um modelo da classe Livro que será salvo no nosso banco de dados.

Atributos

Você deve estar se perguntando, mas se eu quiser adicionar um atributo unico, pode ser o title ou talvez um id. Nesse caso vamos adicionar outra macro na frente do nosso atríbuto.

@Model class Book {
  @Attribute(.unique) var title: String
  var pages: Double
  var theme: String
}

Dessa forma não conseguiremos salvar dois livros com o mesmo título.

Vou deixar uma lista aqui de atríbutos que podemos ser usados:

 /// Ensures the property's value is unique across all models of the same type.
 public static var unique: Schema.Attribute.Option { get }

/// Transforms the property's value between an in-memory form and a persisted form.
public static func transformable(by transformerType: ValueTransformer.Type) -> Schema.Attribute.Option
public static func transformable(by transformerName: String) -> Schema.Attribute.Option

/// Stores the property's value as binary data adjacent to the model storage.
public static var externalStorage: Schema.Attribute.Option { get }

/// Stores the property's value in an encrypted form.
public static var allowsCloudEncryption: Schema.Attribute.Option { get }

/// Preserves the property's value in the persistent history when the context deletes the owning model.
public static var preserveValueOnDeletion: Schema.Attribute.Option { get }

/// Track changes to this property but do not persist
public static var ephemeral: Schema.Attribute.Option { get }

/// Indexes the property's value so it can appear in Spotlight search results.
public static var spotlight: Schema.Attribute.Option { get }

Atributos Transitórios (transient attributes)

São atributos que fazem parte da nossa model, mas que não queremos salvar no banco de dados por algum motivo específico.

@Model class Book {
  @Attribute(.unique) var title: String
  var pages: Double
  var theme: String

  // Will not save this two properties 
  @Transient var readingSpeedPerPage = 0
  var fullTitle: String {
        "\(title) - \(theme)"
  }
}

SwiftData vai automaticamente salvar somente as Stored Properties do seu modelo, qualquer Computed Properties será tratada como transient, caso você queria que alguma Stored Property seja temporário basta colocar a macro @Transient na frente.

Relationship

@Model class Book {
  @Attribute(.unique) var title: String
  var pages: Double
  var theme: String

  // Will not save this two properties 
  @Transient var readingSpeedPerPage = 0
  var fullTitle: String {
        "\(title) - \(theme)"
  }
}

@Model class Author {
  @Attribute(.unique) var name: String
  @Relationship(deleteRule: .cascade) var books: [Books]
}

Para criar uma relação entre duas classes precisamos criar um atributo, nesse caso eu estou dizendo que o Author conhece seus livros mas o livro não sabe quem é seu Author, e adicionar a Macro @Relationship e adicionar o tipo de regra de exclusão. Segue uma lista das regras disponíveis:

case cascade
A rule that deletes any related models.

case deny
A rule that prevents the deletion of a model because it contains one or more references to other models.

case noAction
A rule that doesn’t make changes to any related models.

case nullify
A rule that nullifies the related model’s reference to the deleted model.

Basicamente:

• Cascade - Se apagarmos o Author todos os livros que ele tem como referencia vão ser apagados.

• Deny - Só vai deixar apagar o Author depois que apagarmos todos os livros

• noAction - Apaga o Author mas deixa os livros salvos

• nullify - Se nossa classe Book conhecesse a classe Author essa propriedade ficaria com valor nil se apagarmos o Author desses livros.

Por padrão o SwiftData a regra de deleção é nullify

Para terminar esse artigo vamos fazer nossa classe livro conhecer o autor, porque existem dois jeito de fazer isso.

Uma maneira é deixar explicito na macro de relação

@Model class Book {
  @Attribute(.unique) var title: String
  var pages: Double
  var theme: String
  var author: Author

  // Will not save this two properties 
  @Transient var readingSpeedPerPage = 0
  var fullTitle: String {
        "\(title) - \(theme)"
  }
}

@Model class Author {
  @Attribute(.unique) var name: String
  @Relationship(deleteRule: .cascade,  inverse: \Book.author) var books: [Books]
}

A outra é deixar o atributo Author como Optional

@Model class Book {
  @Attribute(.unique) var title: String
  var pages: Double
  var theme: String
  var author: Author?

  // Will not save this two properties 
  @Transient var readingSpeedPerPage = 0
  var fullTitle: String {
        "\(title) - \(theme)"
  }
}

@Model class Author {
  @Attribute(.unique) var name: String
  @Relationship(deleteRule: .cascade) var books: [Books]
}