SwiftUI: ano ito, mga pangunahing konsepto at View Protocol

Ano ang SwiftUI?

SwiftUI ay isang declarative framework, na ipinakilala ng Apple noong 2019 upang palitan ang UIKit sa mga bagong proyekto. Sa halip na manu-manong gumawa ng mga instance ng UIView at idagdag ang mga ito sa hierarchy, inilalarawan ng developer ang interface sa pamamagitan ng mga estruktura na nagpapatupad ng View protocol. Awtomatikong kinakalkula ng SwiftUI ang pagkakaiba sa pagitan ng kasalukuyan at bagong estado at muling iginuguhit lamang ang mga binagong bahagi gamit ang sarili nitong rendering engine.

Ang framework ay isinulat sa Swift gamit ang value semantics (mga estruktura, hindi mga klase), na ginagawang magaan at thread-safe ang mga UI component. Hindi tulad ng UIKit, kung saan ang UIViewController ay maaaring tumimbang ng 200+ bytes dahil sa Objective-C runtime, ang SwiftUI View ay isang estruktura lamang na ilang bytes ang laki. Ito ay lalong mahalaga para sa watchOS na may limitadong memorya.

Cross-platform ng SwiftUI

Ang parehong paglalarawan ng View ay gumagana sa iPhone, iPad, Mac, Apple Watch, Apple TV at Apple Vision Pro. Inaangkop ng SwiftUI ang interface sa platform: sa iOS — mga galaw ng pagpindot, sa macOS — mga shortcut sa keyboard, sa watchOS — pag-scroll ng Digital Crown. Pinapaikli nito ang oras ng pag-develop para sa mga kumpanyang naglalabas ng mga app sa maraming platform ng Apple, ngunit nangangailangan ng karagdagang konpigurasyon para sa mga tiyak na elemento ng bawat platform.

View Protocol at katawan ng view

Sa SwiftUI, ang bawat screen ay isang estruktura na nagpapatupad ng View protocol na may iisang kinakailangan: computed property body ng uri some View. Ang keyword na some (opaque type) ay nagtatago ng konkretong uri ng view, na nagpapahintulot sa SwiftUI na i-optimize ang rendering. Sa loob ng body, pinagsasama ng developer ang mga handa nang component — Text, Image, Button, List — gamit ang ViewBuilder, na nangongolekta ng maraming view sa iisa.

struct GreetingView: View {
    let name: String

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

Sa halimbawa, ang VStack (vertical stack) ay naglalaman ng Text at Image. Ang halaga ng name ay ipinapasa sa pamamagitan ng initializer ng estruktura — ganito gumagana ang DI (Dependency Injection) sa SwiftUI nang walang panlabas na DI container. Ang bawat modifier ay nagbabalik ng bagong view na may inilapat na pagbabago, nang hindi minu-mutate ang orihinal. Ito ay posible dahil sa immutability ng mga value type.

ViewBuilder at mga kondisyonal

Ang ViewBuilder ay isang result builder, na may anotasyong @resultBuilder, na nangongolekta ng hanggang 10 view sa iisa. Sa loob ng body, maaaring gamitin ang if/else, switch at ForEach nang walang karagdagang pambalot. Ang ForEach ay gumagana sa mga elementong Identifiable — bawat view ay tumatanggap ng natatanging id para sa tamang animasyon kapag naglalagay/nagtatanggal.

Pamamahala ng estado: @State, @Binding, @ObservedObject

Sa SwiftUI, tinutukoy ng estado kung anong nilalaman ang ipinapakita sa screen. Kapag nagbago ang estado, muling nililikha ng SwiftUI ang body ng umaasang view at ikinukumpara ang resulta sa nauna, na inilalapat ang diff algorithm. Para sa pag-iimbak ng estado, ginagamit ang property wrappers — bawat isa ay lumulutas ng sarili nitong gawain: lokal na estado, koneksyon sa anak na view, o panlabas na modelo ng data.

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

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

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

Ang @State ay nag-iimbak ng lokal na simpleng halaga (Int, String, Bool) sa loob ng estruktura ng View. Inililipat ng SwiftUI ang memorya mula sa estruktura patungo sa isang hiwalay na imbakan — kaya ang property na may @State ay maaaring baguhin (i-mutate), kahit na ang View ay isang value type. Ang @ObservableObject — para sa mga klase na may mga @Published na property, na ang mga pagbabago ay awtomatikong nag-aabiso sa SwiftUI tungkol sa pangangailangan ng pag-redraw.

@Binding at relasyon ng magulang-anak

Ang @Binding ay lumilikha ng dalawang-daan na koneksyon sa pinagmumulan ng data na matatagpuan sa magulang na view. Ipinapasa ng magulang ang $variable (projected value), binabasa at isinusulat ng anak ang halaga sa pamamagitan ng binding. Pinapayagan nito ang paglipat ng input ng teksto o switch sa isang hiwalay na component, habang pinapanatili ang estado sa magulang. Kung wala ang @Binding, ang bawat pagbabago ay mangangailangan ng callback closure para ipasa ang bagong halaga pataas.

Nabigasyon sa SwiftUI: NavigationStack at NavigationLink

Bago ang iOS 16, ang nabigasyon sa SwiftUI ay binuo sa NavigationView — isang lumang API na may kumplikadong gawi sa iPad (split view, double column). Simula sa iOS 16, inirerekomenda ng Apple ang NavigationStack — isang pinasimpleng alternatibo na may mga rutang ligtas sa uri. Tinutukoy ng developer ang enum ng mga posibleng ruta, at awtomatikong pinamamahalaan ng NavigationStack ang stack ng mga screen na may suporta para sa malalim na link at pagbabalik sa ugat.

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

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

Ang mga rutang uri ng Route: Hashable ay nagpapahintulot sa paggamit ng anumang uri ng data para sa pagpapasa ng mga parameter. Ang navigationDestination(for:destination:) ay nag-uugnay ng uri ng ruta sa target na view. Bentahe kumpara sa UIKit nabigasyon — hindi kailangan ang pag-redraw kapag nagdadagdag ng bagong ruta: sapat na ang magdagdag ng case sa enum at handler sa switch. Ang malalim na link ay pinoproseso sa pamamagitan ng processDeepLink sa NavigationStack.

Programatikong Nabigasyon

Para sa programatikong transisyon (pagkatapos ng login, timer o tugon ng server) ginagamit ang @State na may NavigationLink initializer: NavigationLink(isActive: $isActive). Kapag itinakda ang isActive = true, ang transisyon ay nangyayari nang walang pagpindot ng gumagamit. Alternatibo — binding ng array na $path sa NavigationStack: $path.append(Route.detail(id: 1)).

View Modifier — konpigurasyon ng hitsura

Ang Modifier ay isang pamamaraan na nagbabalik ng binagong kopya ng view. Hindi tulad ng UIKit, kung saan ang konpigurasyon ng mga property ay ginagawa sa pamamagitan ng pag-mutate ng umiiral na view, ang SwiftUI ay lumilikha ng bagong halaga na may inilapat na pagbabago. Ang kadena ng mga modifier (chaining) ay nagtatayo ng panghuling interface mula sa sunud-sunod na mga pagbabago: font → espasyo → kulay → anino → kilos.

Ang Apple ay nagbibigay ng higit sa 200 built-in na modifier. Ang pinakakaraniwan ay: .font(), .foregroundColor(), .padding(), .background(), .cornerRadius(), .shadow(), .opacity(), .offset(). Mahalaga ang pagkakasunod-sunod ng mga modifier: ang .padding() bago ang .background() ay nagkukulay ng area na may espasyo, pagkatapos — ang panloob na area lamang. Ang custom na modifier ay ginagawa sa pamamagitan ng ViewModifier protocol.

Mga kondisyonal na modifier at animasyon

Ang mga modifier ay maaaring ilapat nang kondisyonal sa pamamagitan ng ternary operator: .foregroundColor(isError ? .red : .primary). Para sa animasyon, ginagamit ang .animation(.easeInOut, value: state) — ang modifier ng animasyon ay nakatali sa isang tiyak na property ng estado. Kapag nagbago ang property na ito, ina-animate ng SwiftUI ang transisyon sa pagitan ng luma at bagong halaga. Ang animasyon ay gumagana sa opacity, offset, scale, rotation, laki at kulay — para sa bawat property ay tinukoy ang kaukulang AnimatableParameter.

Para sa custom na animasyon, available ang .transition (paglitaw/paglaho) at .matchedGeometryEffect (maayos na transisyon ng elemento sa pagitan ng dalawang lalagyan). Ang huli ay ginagamit para sa hero-animasyon sa mga listahan: ang icon sa cell ng listahan ay maayos na nagiging malaking larawan sa screen ng detalye.

SwiftUI vs UIKit: paghahambing ng mga diskarte

Ang pagpili sa pagitan ng SwiftUI at UIKit ay isa sa mga unang dilema ng isang iOS developer. Ang parehong framework ay sinusuportahan ng Apple, ngunit nilulutas ang gawain ng pagbuo ng interface sa magkaibang paraan: ang SwiftUI ay deklaratibo, ang UIKit ay imperatibo. Ang pagkakaiba ay makikita sa pamamahala ng estado, nabigasyon, pagganap at compatibility.

Para sa mga bagong proyekto na may pinakamababang bersyon na iOS 17, inirerekomenda ng Apple ang SwiftUI bilang pangunahing framework. Ang UIKit ay nananatiling kinakailangan para sa mga interface na nangangailangan ng pinong kontrol sa rendering (custom na UICollectionViewLayout, kumplikadong CAAnimation scene) o suporta para sa iOS 12–14. Maraming proyekto ang gumagamit ng hybrid na diskarte: ang SwiftUI sa pamamagitan ng UIHostingController ay naka-embed sa UIKit app, at ang UIViewRepresentable ay nagpapahintulot sa paggamit ng mga UIKit component sa loob ng SwiftUI hierarchy.