Swift – iOS programėlės

Kodėl Swift, o ne kas nors kitas?

Jei kada nors galvojai apie iOS programėlės kūrimą, greičiausiai susidūrei su klausimu – kokia kalba rašyti? Atsakymas 2024-aisiais yra gana aiškus: Swift. Bet ne todėl, kad Apple taip pasakė, o todėl, kad ši kalba per pastaruosius kelerius metus tapo tikrai brandi, stabili ir, svarbiausia, maloni naudoti.

Swift atsirado 2014 metais kaip Objective-C pakaitalas. Objective-C buvo… savotiška kalba. Ji veikė, turėjo savo logiką, bet rašyti joje buvo tarsi važiuoti senu sovietiniu autobusu – pasieksi tikslą, bet kelionė nebus maloniausia. Swift pakeitė žaidimo taisykles. Sintaksė tapo švaresnė, klaidos – aiškesnės, o kompiliatorius – protingesnis.

Šiandien Swift naudoja ne tik iOS, bet ir macOS, watchOS, tvOS programėlių kūrimui. Be to, kalba tampa vis populiaresnė serverio pusėje – Swift on Server jau nėra egzotika. Taigi išmokęs Swift, gauni gerokai daugiau nei tik galimybę rašyti iPhone programėles.

Swift kalbos pagrindai – ką reikia žinoti prieš pradedant

Prieš šokant į Xcode ir kuriant pirmąją programėlę, verta suprasti keletą Swift konceptų, kurie iš pradžių gali atrodyti keistai, bet vėliau taps geriausiais draugais.

Optionals – tai vienas iš tų dalykų, dėl kurių žmonės iš pradžių plėšosi plaukus. Idėja paprasta: kintamasis gali turėti reikšmę arba gali jos neturėti (nil). Kitose kalbose tai dažnai sukelia NullPointerException tipo katastrofas. Swift verčia tave aiškiai pasakyti – šis kintamasis gali būti nil, ir tu privalai tai apdoroti. Pavyzdžiui:

var vardas: String? = nil
if let tikrasVardas = vardas {
    print("Labas, \(tikrasVardas)")
} else {
    print("Vardas nežinomas")
}

Type inference – Swift yra stipriai tipizuota kalba, bet tau nereikia visur rašyti tipų. Kompiliatorius pats supranta, kad let skaičius = 42 yra Int, o let tekstas = "labas" yra String. Tai taupo laiką ir kodas atrodo švariau.

Structs vs Classes – Swift labai skatina naudoti struktūras (structs) vietoj klasių, kur tik įmanoma. Struktūros yra value types, tai reiškia, kad jos kopijuojamos, o ne perduodamos kaip nuoroda. Tai sumažina šalutinius efektus ir padaro kodą lengviau suprantamą. Praktinis patarimas: pradėk nuo struct, pereik prie class tik tada, kai tikrai reikia paveldėjimo ar reference semantics.

Closures – tai anoniminės funkcijos, kurias galima perduoti kaip parametrus. Jei naudojai JavaScript, žinai, kas tai yra. Swift closures yra labai dažnai naudojamos asinchroniniame kode, animacijose, duomenų filtravime. Išmok jas gerai – sutaupysi daug laiko.

Xcode – tavo darbo aplinka, kurią reikia pažinti

Xcode yra Apple oficiali kūrimo aplinka ir, tiesą sakant, vienintelė rimta galimybė kuriant iOS programėles. Taip, yra alternatyvų kaip AppCode (kurį JetBrains jau sustabdė), bet praktiškai visi iOS kūrėjai naudoja Xcode.

Pirmą kartą atidarius Xcode, gali apimti lengvas šokas – čia daug visko. Kairėje – projekto failų medis, centre – kodo redaktorius arba Interface Builder, dešinėje – inspektoriai, apačioje – konsolė ir klaidos. Keletas dalykų, kuriuos verta žinoti iš karto:

• Simulator – Xcode turi integruotą iPhone/iPad simuliatorių. Jis leidžia testuoti programėlę be fizinio įrenginio. Simuliatorius nėra tobulas (pvz., jis negali imituoti kameros ar kai kurių jutiklių), bet 90% atvejų jo pakanka.
• Instruments – tai Xcode įrankis programėlės našumui analizuoti. Jei programėlė lėta arba valgo per daug atminties, Instruments padės surasti problemą. Daugelis kūrėjų šio įrankio net nepaliečia, kol neprasideda tikros problemos – tai klaida.
• Breakpoints – derinimo taškai. Spustelėk ant eilutės numerio kodo redaktoriuje ir gausi breakpoint. Kai programėlė pasiekia tą vietą, ji sustoja ir gali tikrinti kintamųjų reikšmes. Tai gerokai efektyviau nei print() visur.

Praktinis patarimas: išmok Xcode klaviatūros trumpinius. Cmd + Shift + O – greita failų paieška, Cmd + B – kompiliavimas, Cmd + R – paleidimas. Šie trys jau sutaupys nemažai laiko.

UIKit vs SwiftUI – amžinasis klausimas

Tai turbūt labiausiai diskutuojamas klausimas iOS kūrimo bendruomenėje. UIKit egzistuoja nuo pat iPhone pradžios (2008 m.), SwiftUI pasirodė 2019 m. ir pažadėjo revoliuciją. Kas geriau?

Trumpas atsakymas: priklauso nuo situacijos. Ilgesnis atsakymas:

UIKit yra brandus, stabilus, ir turi milžinišką dokumentacijos bei Stack Overflow atsakymų kiekį. Jei kuri programėlę, kuri turi veikti nuo iOS 13 ar senesnės versijos, UIKit yra būtinas. Be to, daugelis sudėtingų UI komponentų vis dar lengviau realizuojami UIKit. Jei dirbsi komandoje ar prie esamo projekto, tikimybė, kad jis rašytas UIKit, yra labai didelė.

SwiftUI yra deklaratyvus UI karkasas – tu aprašai, kaip turi atrodyti UI, o ne kaip jį sukurti žingsnis po žingsnio. Kodas yra trumpesnis, lengviau skaitomas, ir automatiškai veikia visose Apple platformose. Preview funkcija leidžia matyti UI pakeitimus beveik realiu laiku, be kompiliavimo. Tai labai pagreitina kūrimą.

Mano rekomendacija: jei pradedat naują projektą ir taikote iOS 16+, eikite su SwiftUI. Jei reikia palaikyti senesnes versijas arba turite sudėtingų UI reikalavimų – UIKit arba hibridinis sprendimas. Ir žinok, kad abu gali egzistuoti tame pačiame projekte – SwiftUI vaizdus galima įterpti į UIKit ir atvirkščiai.

// SwiftUI pavyzdys – paprastas ekranas
struct ContentView: View {
    @State private var skaičius = 0
    
    var body: some View {
        VStack {
            Text("Skaičius: \(skaičius)")
                .font(.largeTitle)
            Button("Padidinti") {
                skaičius += 1
            }
            .buttonStyle(.borderedProminent)
        }
    }
}

Palygink su UIKit ekvivalentu – ten reikėtų sukurti ViewController, pridėti Label ir Button programiškai arba per Interface Builder, prijungti IBOutlet ir IBAction… Skirtumas akivaizdus.

Duomenų valdymas ir architektūra – nuo chaoso prie tvarkos

Viena didžiausių klaidų, kurią daro pradedantieji iOS kūrėjai – viską sukišti į ViewController arba SwiftUI View. Iš pradžių atrodo patogu, bet po kelių savaičių kodas tampa nebeįskaitomas ir sunkiai palaikomas.

iOS pasaulyje populiariausios architektūros:

MVC (Model-View-Controller) – tai Apple oficialiai rekomenduojama architektūra UIKit. Teorijoje graži, praktikoje dažnai virsta „Massive View Controller” – ViewController, kuris daro viską. Jei naudoji MVC, bent jau iškelk business logiką į atskiras klases ar struktūras.

MVVM (Model-View-ViewModel) – labai populiari su SwiftUI. ViewModel yra tarpininkas tarp duomenų ir UI. Ji paruošia duomenis rodymui ir apdoroja vartotojo veiksmus. Su SwiftUI ir Combine arba async/await tai veikia labai natūraliai.

TCA (The Composable Architecture) – sukurta Point-Free komandos, ši architektūra yra labai struktūruota ir tinkama dideliems projektams. Mokymosi kreivė statesnė, bet rezultatas – labai testuojamas ir nuspėjamas kodas.

Duomenų saugojimui iOS siūlo keletą variantų:

• UserDefaults – paprastoms nustatymų reikšmėms. Nesaugok čia didelių duomenų kiekių.
• Core Data – Apple ORM sprendimas. Galingas, bet sudėtingas. Tinka sudėtingiems duomenų modeliams su ryšiais.
• SwiftData – naujesnė Core Data alternatyva, pristatyta 2023 m. Gerokai paprastesnė naudoti, bet reikalauja iOS 17+.
• SQLite / GRDB – jei reikia tiesioginio SQL valdymo, GRDB yra puiki biblioteka.
• Keychain – slaptažodžiams ir jautriems duomenims. Niekada nesaugok slaptažodžių UserDefaults.

Tinklo užklausos ir asinchroninis kodas

Beveik kiekviena šiuolaikinė programėlė bendrauja su serveriu. Swift turi integruotą URLSession tinklo užklausoms, o nuo Swift 5.5 – async/await sintaksę, kuri padarė asinchroninį kodą gerokai skaitomesnį.

Anksčiau tinklo užklausa atrodė maždaug taip – completion handler su closure, o jei reikėjo kelių viena po kitos einančių užklausų, gaudavai „callback hell”. Dabar:

func gautiVartotojus() async throws -> [Vartotojas] {
    let url = URL(string: "https://api.pavyzdys.lt/vartotojai")!
    let (duomenys, _) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode([Vartotojas].self, from: duomenys)
}

Tai skaitoma kaip sinchroninis kodas, bet veikia asinchroniškai. Labai gražu.

Keletas praktinių patarimų darbui su tinklu:

• Visada apdorok klaidas. Tinklas gali neveikti, serveris gali grąžinti netikėtus duomenis. try/catch yra tavo draugas.
• Nekrk tinklo užklausų tiesiogiai View ar ViewController – iškelk jas į atskirą sluoksnį (NetworkService, Repository ir pan.).
• Naudok Codable protokolą JSON dekodavimui. Tai integruotas Swift sprendimas ir jis veikia puikiai.
• Testuodamas galima naudoti URLProtocol mock’inimui – tai leidžia testuoti tinklo kodą be realaus serverio.

Jei projektas sudėtingesnis ir reikia reaktyvaus programavimo, Combine (Apple karkasas) arba RxSwift (trečiųjų šalių biblioteka) gali padėti valdyti duomenų srautus. Tačiau pradedantiesiems rekomenduočiau pirmiausia gerai išmokti async/await – to daugeliu atvejų pakanka.

App Store – kaip patekti ir ko tikėtis

Sukūrei programėlę, ji veikia simuliatoriuje, veikia fiziniame įrenginyje. Ką toliau? App Store publikavimas – tai atskiras procesas su savo taisyklėmis ir reikalavimais.

Pirmiausia reikia Apple Developer Program narystės – ji kainuoja 99 USD per metus. Tai leidžia publikuoti programėles App Store ir testuoti jas fiziniuose įrenginiuose. Yra ir nemokama versija, bet ji labai ribota.

Prieš pateikiant programėlę peržiūrai, reikia:

• Sukurti programėlės įrašą App Store Connect platformoje
• Paruošti ekranvaizdžius (screenshots) visų reikalingų įrenginių dydžiams
• Parašyti aprašymą, raktažodžius, nustatyti kategoriją
• Sukonfigūruoti privatumo politiką (privaloma, jei programėlė renka bet kokius duomenis)
• Archyvuoti programėlę Xcode ir įkelti per Xcode Organizer arba Transporter

Apple peržiūros procesas trunka nuo kelių valandų iki kelių dienų. Peržiūrėtojai tikrina, ar programėlė atitinka App Store gaires. Dažniausios atmetimo priežastys: programėlė crashina, UI yra nebaigta, trūksta funkcionalumo, arba pažeidžiamos privatumo taisyklės.

Praktinis patarimas: prieš pateikdamas, perskaityk Apple Human Interface Guidelines. Tai ne tik taisyklių rinkinys – tai geras vadovas, kaip kurti intuityvias iOS programėles. Peržiūrėtojai tikrina, ar programėlė laikosi iOS dizaino principų.

TestFlight – Apple beta testavimo platforma – leidžia prieš oficialų paleidimą išsiųsti programėlę iki 10 000 beta testerių. Tai labai rekomenduotina – realūs vartotojai suranda klaidų, kurių tu niekada nepamatytum.

Kai programėlė jau gyva – kas toliau?

Daugelis kūrėjų galvoja, kad publikavimas yra finišo linija. Iš tikrųjų tai tik starto pistoleto šūvis. Programėlė gyva tol, kol ji palaikoma, atnaujinama ir tobulinama.

Crash reporting – pirmas dalykas, kurį reikia sukonfigūruoti. Firebase Crashlytics arba Sentry leis matyti, kur ir kodėl programėlė lūžta pas realius vartotojus. Be šito esi aklas.

Analytics – suprasti, kaip vartotojai naudoja programėlę, yra labai svarbu. Mixpanel, Amplitude arba tiesiog Firebase Analytics padės suprasti, kokios funkcijos populiarios, kur vartotojai „iškrenta” ir ką reikia tobulinti.

Kiekvienais metais Apple pristato naują iOS versiją ir naujus iPhone modelius. Tai reiškia, kad reikia atnaujinti programėlę, kad ji veiktų su naujomis API, naujais ekranų dydžiais, naujomis funkcijomis. iOS kūrimas nėra „sukūriau ir pamiršau” – tai nuolatinis procesas.

Swift kalba taip pat nuolat tobulėja. Kiekvienais metais ateina naujos kalbos funkcijos, nauji karkasai. Sekti Swift Evolution pasiūlymus ir Apple WWDC pranešimus yra beveik privaloma, jei nori likti aktualus. WWDC sesijos yra nemokamos ir prieinamos Apple Developer svetainėje – tai vienas geriausių mokymosi šaltinių.

Galiausiai, iOS kūrimas yra nuolatinis mokymasis. Ekosistema keičiasi greitai, bendruomenė aktyvi, o gerų resursų – daugybė. Swift.org, Hacking with Swift (Paul Hudson), Swift by Sundell, Point-Free – tai šaltiniai, kurie tikrai verti laiko. Pradėk nuo mažo projekto, kurk kažką, kas tau įdomu, ir nepasiduok, kai kompiliatorius pirmą kartą parodys 47 klaidas. Visi ten buvo.