Wat we ermee bouwen
Elke Flutter-app heeft onder zijn Android-helft een Gradle-build, en die houdt op onzichtbaar te zijn zodra een product meer dan één variant nodig heeft. Product flavours voor staging en productie, aparte ondertekeningsconfiguraties, applicatie-ID's per flavour, overschreven resources, en welke native SDK's de app ook binnenhaalt.
Daar leven ook de ongemakkelijke problemen: conflicten tussen afhankelijkheden van plug-ins, minificatieregels die iets weghalen wat reflectie nodig had, en builds die alleen in releasemodus falen.
Waar het past
Onder de Android-kant van ons mobiele werk, nauw verbonden met Kotlin wanneer een app native code heeft, en met Fastlane, dat deze builds vanuit CI aanstuurt in plaats van vanaf de machine van een developer.
Het telt het zwaarst bij producten met meerdere doelen. Een white-label-platform dat veel merkapps uit één codebase levert, is net zo goed een Gradle-configuratieprobleem als een Flutter-probleem — elk merk heeft een eigen identifier, assets en ondertekeningsidentiteit nodig, gegenereerd in plaats van met de hand onderhouden.
Wanneer we het aanraden
Voor Android is het niet optioneel; de enige keuze is of je de build als code behandelt. Wij doen dat — flavours die één keer worden gedeclareerd en afgeleid, niet per merk gekopieerd.
Waar we het minimaal houden, zijn eigen Gradle-plug-ins en op maat gemaakte taakgrafieken. Ze zijn krachtig en ze zijn ook precies wat niemand in het team twee jaar later wil debuggen, dus we grijpen er alleen naar als een echt probleem erom vraagt.