Wat we ermee bouwen
Er zijn iOS-oppervlakken waarin een Flutter-engine eenvoudigweg niet draait, en met SwiftUI bouwen we die. Widgets op het beginscherm en het vergrendelscherm, Live Activities, App Clips, deel- en notificatie-extensies, watch-apps — elk daarvan is een apart target met een eigen proces en een eigen UI, en elk moet native geschreven worden.
SwiftUI is declaratief en gestuurd door state, en dus conceptueel dicht bij Flutter, wat in de praktijk telt: een engineer die tussen beide beweegt denkt in dezelfde vormen in plaats van de imperatieve view controllers van UIKit opnieuw te leren.
Waar het past
Rondom een Flutter-app in plaats van in plaats daarvan, geschreven in Swift en data delend met de hoofdapp via een app group. Het App Clip-werk waarover we schreven heeft precies deze vorm — een kleine native ervaring die zonder installatie start en overdraagt aan de volledige app.
Wanneer we het aanraden
Voor die extensietargets, waar geen alternatief bestaat, en voor volledig native iOS-apps waar het product alleen voor Apple is.
Niet voor de hoofd-UI van een cross-platform product. De primaire interface twee keer bouwen — SwiftUI op iOS en iets anders op Android — zijn precies de kosten die Flutter bestaat om weg te nemen, en allebei doen betekent dat elk scherm twee keer wordt ontworpen, gebouwd en gerepareerd.
Goed om te weten: SwiftUI heeft nog gaten die je voor specifieke besturingselementen terugsturen naar UIKit, en het gedrag verandert merkbaar tussen iOS-versies. Volwassen genoeg om op te bouwen, niet volwassen genoeg om aan te nemen.
