SwiftUI: apa itu, konsep kunci dan View Protocol

Apa itu SwiftUI?

SwiftUI adalah framework deklaratif, diperkenalkan oleh Apple pada tahun 2019 untuk menggantikan UIKit dalam proyek-proyek baru. Alih-alih membuat instance UIView secara manual dan menambahkannya ke hierarki, pengembang mendeskripsikan antarmuka melalui struktur yang mengimplementasikan protokol View. SwiftUI secara otomatis menghitung perbedaan antara status saat ini dan yang baru dan hanya menggambar ulang bagian yang berubah, menggunakan mesin rendering miliknya sendiri.

Framework ini ditulis dalam Swift menggunakan value semantics (struktur, bukan kelas), yang membuat komponen UI menjadi ringan dan thread-safe. Tidak seperti UIKit, di mana UIViewController dapat berbobot 200+ byte karena runtime Objective-C, View SwiftUI hanyalah sebuah struktur berukuran beberapa byte. Ini sangat penting untuk watchOS dengan memorinya yang terbatas.

Lintas Platform SwiftUI

Deskripsi View yang sama berfungsi di iPhone, iPad, Mac, Apple Watch, Apple TV, dan Apple Vision Pro. SwiftUI menyesuaikan antarmuka dengan platform: di iOS — gerakan sentuh, di macOS — pintasan keyboard, di watchOS — pengguliran Digital Crown. Ini mempercepat waktu pengembangan bagi perusahaan yang merilis aplikasi di beberapa platform Apple, tetapi memerlukan konfigurasi tambahan untuk elemen spesifik setiap platform.

View Protocol dan tubuh tampilan

Di SwiftUI, setiap layar adalah struktur yang mengimplementasikan protokol View dengan satu persyaratan: properti terkomputasi body bertipe some View. Kata kunci some (opaque type) menyembunyikan tipe konkret view, memungkinkan SwiftUI mengoptimalkan rendering. Di dalam body, pengembang menggabungkan komponen siap pakai — Text, Image, Button, List — menggunakan ViewBuilder, yang mengumpulkan beberapa view menjadi satu.

struct GreetingView: View {
    let name: String

    var var body: some View {
        VStack {
            Text("Halo, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Image(systemName: "hand.wave")
                .imageScale(.large)
        }
        .padding()
    }
}

Dalam contoh, VStack (tumpukan vertikal) berisi Text dan Image. Nilai name diteruskan melalui inisialisasi struktur — begitulah cara DI (Dependency Injection) bekerja di SwiftUI tanpa wadah DI eksternal. Setiap pengubah mengembalikan view baru dengan perubahan yang diterapkan, tanpa mengubah aslinya. Ini dimungkinkan berkat imutabilitas (immutability) tipe nilai (value types).

ViewBuilder dan kondisional

ViewBuilder adalah result builder, yang dianotasi dengan @resultBuilder, yang mengumpulkan hingga 10 view menjadi satu. Di dalam body, if/else, switch, dan ForEach dapat digunakan tanpa pembungkus tambahan. ForEach bekerja dengan elemen Identifiable — setiap view menerima id unik untuk animasi yang benar saat menyisipkan/menghapus.

Manajemen status: @State, @Binding, @ObservedObject

Di SwiftUI, status menentukan konten apa yang ditampilkan di layar. Ketika status berubah, SwiftUI membuat ulang body dari view yang bergantung dan membandingkan hasilnya dengan sebelumnya, menerapkan algoritma diff. Untuk menyimpan status digunakan property wrappers — masing-masing menyelesaikan tugasnya sendiri: status lokal, koneksi dengan view anak, atau model data eksternal.

struct CounterView: View {
    @State private var count = 0

    var var body: some View {
        VStack {
            Text("Penghitung: \(count)")
            Button("Tambah") {
                count += 1
            }
        }
    }
}

class UserViewModel: ObservableObject {
    @Published var name = ""
    @Published var age = 0
}

@State menyimpan nilai lokal sederhana (Int, String, Bool) di dalam struktur View. SwiftUI memindahkan memori dari struktur ke penyimpanan terpisah — oleh karena itu properti dengan @State dapat diubah (dimutasi), meskipun View adalah tipe nilai. @ObservableObject — untuk kelas dengan properti @Published, yang perubahannya secara otomatis memberi tahu SwiftUI tentang perlunya penggambaran ulang.

@Binding dan hubungan orangtua-anak

@Binding menciptakan koneksi dua arah dengan sumber data yang terletak di view induk. Induk meneruskan $variable (projected value), anak membaca dan menulis nilai melalui binding. Ini memungkinkan pemindahan input teks atau sakelar ke komponen terpisah, sambil mempertahankan status di induk. Tanpa @Binding, setiap perubahan memerlukan penutupan callback untuk meneruskan nilai baru ke atas.

Navigasi di SwiftUI: NavigationStack dan NavigationLink

Sebelum iOS 16, navigasi di SwiftUI dibangun di atas NavigationView — API usang dengan perilaku kompleks di iPad (split view, double column). Mulai iOS 16, Apple merekomendasikan NavigationStack — alternatif yang disederhanakan dengan rute yang aman tipe. Pengembang mendefinisikan enum dari rute yang mungkin, dan NavigationStack secara otomatis mengelola tumpukan layar dengan dukungan untuk tautan dalam dan kembali ke akar.

enum Route: Hashable {
    case detail(id: Int)
    case settings
}

struct ContentView: View {
    var var body: some View {
        NavigationStack {
            List {
                NavigationLink("Layar detail",
                               value: Route.detail(id: 42))
                NavigationLink("Pengaturan",
                               value: Route.settings)
            }
            .navigationDestination(for: Route.self) { route in
                switch route {
                case .detail(let id): DetailView(id: id)
                case .settings: SettingsView()
                }
            }
        }
    }
}

Rute bertipe Route: Hashable memungkinkan penggunaan tipe data apa pun untuk meneruskan parameter. navigationDestination(for:destination:) menghubungkan tipe rute dengan view tujuan. Keuntungan dibandingkan navigasi UIKit — penggambaran ulang tidak diperlukan saat menambahkan rute baru: cukup tambahkan case di enum dan handler di switch. Tautan dalam diproses melalui processDeepLink pada NavigationStack.

Navigasi Terprogram

Untuk transisi terprogram (setelah login, timer, atau respons server) digunakan @State dengan inisialisasi NavigationLink: NavigationLink(isActive: $isActive). Saat mengatur isActive = true, transisi terjadi tanpa sentuhan pengguna. Alternatifnya — binding array $path di NavigationStack: $path.append(Route.detail(id: 1)).

View Modifier — konfigurasi tampilan

Modifier adalah metode yang mengembalikan salinan view yang dimodifikasi. Tidak seperti UIKit, di mana konfigurasi properti dilakukan melalui mutasi view yang ada, SwiftUI membuat nilai baru dengan perubahan yang diterapkan. Rantai pengubah (chaining) membangun antarmuka akhir dari transformasi berurutan: font → spasi → warna → bayangan → gerakan.

Apple menyediakan lebih dari 200 pengubah bawaan. Yang paling umum adalah: .font(), .foregroundColor(), .padding(), .background(), .cornerRadius(), .shadow(), .opacity(), .offset(). Urutan pengubah itu penting: .padding() sebelum .background() mewarnai area dengan spasi, setelahnya — hanya area dalam. Pengubah kustom dibuat melalui protokol ViewModifier.

Pengubah bersyarat dan animasi

Pengubah dapat diterapkan secara bersyarat melalui operator ternary: .foregroundColor(isError ? .red : .primary). Untuk animasi digunakan .animation(.easeInOut, value: state) — pengubah animasi terikat pada properti status tertentu. Saat properti ini berubah, SwiftUI menganimasikan transisi antara nilai lama dan baru. Animasi bekerja dengan opacity, offset, scale, rotation, ukuran, dan warna — untuk setiap properti ditentukan AnimatableParameter yang sesuai.

Untuk animasi kustom tersedia .transition (muncul/hilang) dan .matchedGeometryEffect (transisi mulus elemen antara dua wadah). Yang terakhir digunakan untuk animasi hero dalam daftar: ikon di sel daftar berubah mulus menjadi gambar besar di layar detail.

SwiftUI vs UIKit: perbandingan pendekatan

Pilihan antara SwiftUI dan UIKit adalah salah satu dilema pertama pengembang iOS. Kedua framework didukung oleh Apple, tetapi menyelesaikan tugas membangun antarmuka dengan cara yang fundamental berbeda: SwiftUI secara deklaratif, UIKit secara imperatif. Perbedaannya terlihat dalam manajemen status, navigasi, kinerja, dan kompatibilitas.

Untuk proyek baru dengan versi minimal iOS 17, Apple merekomendasikan SwiftUI sebagai framework utama. UIKit tetap diperlukan untuk antarmuka yang memerlukan kontrol halus atas rendering (UICollectionViewLayout kustom, skena CAAnimation kompleks) atau dukungan untuk iOS 12–14. Banyak proyek menggunakan pendekatan hibrida: SwiftUI melalui UIHostingController disematkan ke dalam aplikasi UIKit, dan UIViewRepresentable memungkinkan penggunaan komponen UIKit di dalam hierarki SwiftUI.