Mobil Uygulamada Design System: Flutter ile Tek Kod, Tek Dil
Aynı uygulama, iki platform, iki ekip. Aynı buton farklı boşlukla, farklı gölgeyle ve biraz farklı bir renkle çıkıyor.
Kullanıcı buna “iki kod tabanı” demez. Tutarsız bir marka der.
Sorun iki platform değil, iki ayrı gerçeklik
iOS ve Android ayrı ayrı geliştirildiğinde her bileşen iki kez var olur. Her ekip kendi küçük kararlarını verir ve fark her sürümde biraz daha açılır.
- Bir tasarım değişikliği iki kez yapılır.
- Her özellik iki kez yazıldığı için yol haritası yavaşlar.
- QA aynı senaryoyu iki farklı uygulamada test eder.
- İki uygulama her ay biraz daha birbirinden uzaklaşır.
Flutter’da bileşen sistemi tek yerde yaşar
Flutter, arayüzünü tek bir kod tabanından kendisi çizer. Bu da onu design system için doğal bir yuva yapar: token’lar tek temada, bileşenler tek ortak pakette, tek bir değişiklik iki platforma birden ulaşır.
Mobilde tutarlılık, iki ekibin aynı şeyi iki kez doğru yapmasıyla değil, tek bir şeyi bir kez doğru yapmasıyla gelir.
Nasıl yapılır? Beş adım
Hepsini bir anda kurmanız gerekmez. 1. ve 2. adımla başlayıp en çok kullandığınız beş altı bileşeni paketleyin. Bu, MVP yaklaşımıdır.
1. Token’larınızı tek bir tema katmanında toplayın
Flutter’da renk ve tipografi zaten ThemeData içinde durur (colorScheme, textTheme). Boşluk ve köşe yuvarlaklığı gibi kendi değerleriniz için tema eklentisi (ThemeExtension) kullanın:
- Boşluk, radius ve gölge değerlerini taşıyan AppTokens gibi bir sınıf tanımlayın. Tema eklentisi copyWith ve lerp metotlarını ister; açık ve koyu tema geçişinin yumuşak animasyonla yapılmasını lerp sağlar.
- Bunu ThemeData.extensions içine ekleyin.
- Ekranlarda değerleri temadan okuyun. Widget kodunda ham sayı ya da Color(0xFF…) yazmayın.
2. Bileşenleri ayrı bir pakete taşıyın
- Projede ayrı bir paket açın (örneğin packages/app_ui) ve tüm bileşenleri tek bir dosyadan dışa aktarın.
- Bileşenler yalnızca anlamsal seçenekler alsın: “primary ya da secondary”, “aktif ya da pasif” gibi. Renk ya da boyut doğrudan verilmesin.
- Her bileşenin içinde tema değerlerini kullanın. Ham renk olmasın.
- Bileşenleri canlı görmek için Widgetbook gibi bir katalog aracı kullanın.
3. Platform farklarına bilinçli karar verin
Neyin ortak kaldığını, neyin platforma uyduğunu yazın ve bunu ekipçe bir kez kararlaştırın:
- Ortak kalanlar: renk, tipografi, boşluk, ikon seti, buton ve input’un görünümü.
- Platforma uyum sağlayanlar: geri hareketi ve sayfa geçişleri, tarih ve saat seçiciler, açma kapama anahtarı gibi sistem kontrolleri.
- Flutter’daki .adaptive kurucuları (örneğin Switch.adaptive) bu uyumu hazır sunar. Platformu Theme.of(context).platform ile okuyabilirsiniz.
- Kural: markayı değil, davranışı uyarlayın.
4. Tasarım ve kod aynı adları konuşsun
- Figma’daki değişken adlarını koddaki token adlarıyla birebir eşleyin; böylece Figma’daki “color/action/primary” kodda da aynı anlama gelir.
- Token’ları tek bir kaynakta (örneğin bir JSON dosyası) tutup Style Dictionary gibi bir araçla hem tasarım hem kod tarafına üretin. Bu, değerleri elle kopyalamayı bitirir.
- Tasarım değişikliğini önce token’da yapın, sonra ekranlara yansısın.
5. Tutarlılığı testlerle koruyun
- Bileşenleriniz için golden test yazın. Flutter bileşenin çizdiği görüntüyü referansla karşılaştırır, istemeden olan değişiklik hemen ortaya çıkar.
- Bu testleri CI’da çalıştırın.
- Kod incelemesinde tek soru sorun: “Bu ekran paketteki bileşenlerle mi yazıldı?”
Sonuç
Bir mobil uygulamanın gücü kaç ekranı olduğu değil, her cihazda tek bir ürün gibi hissettirmesidir.
Tek kod tabanı ve tek bileşen sistemi, bir kez tasarlayıp iki platformda doğru çalışmasını sağlar.
