Wat we ermee bouwen
Swift is waar onze Flutter-apps iOS echt ontmoeten. De cross-platform laag dekt het meeste van een product af, maar niet de delen die in het besturingssysteem leven: uitvoering op de achtergrond, notification service extensions, keychain en biometrie, NFC, leveranciers-SDK's die als native framework worden geleverd, en alles wat buiten de app zelf moet verschijnen.
Dat werk schrijven we in Swift achter een platform channel, zodat de Dart-kant een schone API ziet en niets van de iOS-levenscyclus. Het is precies de tegenhanger van wat Kotlin op Android doet, en een platformintegratie betekent meestal dat je allebei schrijft.
Waar het past
Binnen onze Flutter-projecten in plaats van ernaast, dus het verschijnt niet als eigen portfolio-item. Het duikt op waar cross-platform code niet bij kan — bijvoorbeeld de App Clip-helft van het werk aan uitgestelde deep linking waarover we schreven, waarvoor geen overdraagbare implementatie bestaat.
Widgets op het beginscherm, deelextensies en SwiftUI-oppervlakken zijn het andere veelvoorkomende geval: het zijn aparte targets waarin een Flutter-engine niet draait.
Wanneer we het aanraden
Voor de iOS-helft van een platformintegratie, en voor een volledig native iOS-app wanneer het product werkelijk platformspecifiek is — diepe OS-integratie, een publiek dat alleen bij Apple zit, of een team dat daar al in heeft geïnvesteerd.
Niet als standaard voor een product dat ook Android nodig heeft. Twee native codebases betekent twee teams, twee releasecycli en twee sets bugs; tenzij iets dat afdwingt, geeft Flutter met een Swift-laag eronder je dezelfde mogelijkheden voor aanzienlijk minder.
