Vi tog beslutet att bygga vår app i SwiftUI på riktigt – inte bara i prototyper eller på en isolerad inställningsskärm. Ett år och flera releaser senare sitter jag med en betydligt mer nyanserad bild. Här är vad som höll, vad som skavde, och vad jag skulle göra igen utan att tveka.
Tänk i tillstånd, inte i vyer
Det stora skiftet är mentalt, inte tekniskt. I UIKit manipulerar du vyer för hand: visa den här, dölj den där, uppdatera den texten. I SwiftUI beskriver du i stället hur gränssnittet ska se ut för ett givet tillstånd, och ramverket sköter alla uppdateringar åt dig.
När du väl släpper vanan att peta på vyer direkt blir koden dramatiskt enklare och mindre buggig. Men det tar några veckor att verkligen tänka om, och i den perioden känns allt klumpigt. Ge teamet den tiden.
En källa till sanning
Den vanligaste källan till buggar vi såg var samma tillstånd som levde på flera ställen samtidigt. Bestäm tidigt var ett visst data ”bor”, och låt resten observera det. När två delar av appen har varsin kopia av samma sanning är det bara en tidsfråga innan de glider isär.
Vad som fungerade riktigt bra
Utvecklingshastigheten är märkbart högre, särskilt för listor, formulär och layouter som ska anpassa sig efter olika skärmstorlekar. Xcodes förhandsvisningar gör att man itererar på sekunder i stället för att bygga om och navigera fram till skärmen varje gång.
Tillgänglighet (VoiceOver, dynamisk textstorlek) fungerar dessutom förvånansvärt bra med minimal extra ansträngning – något som är lätt att slarva med men viktigt på en svensk marknad med höga krav.
Vad som fortfarande skavde
Komplexa, finkorniga animationer och vissa specialiserade, äldre UIKit-komponenter krävde fortfarande att vi gick ner i UIKit. Lösningen var pragmatisk: bädda in UIKit-komponenten där den behövdes via en wrapper, i stället för att slåss mot SwiftUI.
Räkna med en hybrid, inte en ren värld. Det är inget nederlag – det är så de flesta seriösa appar ser ut idag.
Skulle jag göra det igen?
Ja, utan tvekan – för nästan alla skärmar. Den ökade hastigheten och den enklare koden väger tungt. Det jag skulle göra annorlunda är att lägga ännu mer tid i början på att rita upp tillståndsflödet, innan vi skrev den första vyn.
Sammanfattning
SwiftUI är moget för produktion för de allra flesta gränssnitt. Bygg i tillstånd, håll källan till sanning samlad, och var pragmatisk nog att falla tillbaka på UIKit i de få fall det verkligen behövs. Då får du både utvecklingsglädje och en app som håller.