Üç Dilde Yerel Yazdıktan Sonra Flutter’a Geçmek

2023 ile 2025 arasında yayınladığım uygulamaların hepsinde aynı şeyi yaptım: aynı ürünü iki kez yazdım. iOS tarafını Swift ile, Android tarafını önce Java sonra Kotlin ile. 2026'da Flutter'a geçtim ve ilk kez tek kod tabanıyla çalışmaya başladım. Bu yazı, o geçişin bana ne kazandırdığını ve karşılığında neyi bıraktığımı olabildiğince dürüst anlatma denemesi.

Kısa cevabı baştan vereyim: kazandığım şey zaman, kaybettiğim şey doğrudan temas. Asıl ilginç kısım, bu takasın nerede işe yaradığı ve nerede canımı yaktığı.

İki kez yazmanın asıl maliyeti satır sayısı değil

Aynı uygulamayı iki dilde yazmanın bedeli genelde “iki kat kod” diye özetleniyor. Benim deneyimimde asıl maliyet bu değildi. Kod bir noktadan sonra kas hafızasına dönüşüyor; bir ekranı Swift'te kurup sonra Kotlin'de tekrar kurmak, düşünmeyi ikinci kez yapmak anlamına gelmiyor. Tasarım kararı zaten verilmiş oluyor, ikinci yazım daha çok çeviri gibi geçiyor.

Asıl maliyet iki uygulamayı aynı hizada tutmak. Cepte Perakende'de taksit seçeneklerinin ve iade koşullarının nasıl hesaplanacağını, 6502 kapsamındaki bilgilendirme metinlerinin hangi adımda görüneceğini iki ayrı yerde tanımladım. ArenaX'te yarışmaya katılım kontrolleri iki kod tabanında da duruyordu. Social Connect'te sekiz farklı tanışma platformunun akışı iki tarafta da ayrı ayrı vardı.

Bu yapının ürettiği tuzak şu: bir hatayı Android tarafında fark edip düzeltiyorsunuz, aynı hatanın iOS'ta da durduğunu haftalar sonra hatırlıyorsunuz. Ya da tersi. İki kod tabanı zamanla birbirinden sessizce ayrışıyor ve bunu size gösteren bir uyarı yok. Ayrışmayı fark etmenizi sağlayan tek şey, kullanıcının “Android'de böyle değildi” diye yazması oluyor.

Aynı ekran, iki farklı “doğru”

Yerel yazmanın hoşuma giden bir tarafı da vardı: iki platform aynı ekranı aynı şekilde istemiyor. Android'de geri hareketi sistemin bir parçası, iOS'ta kenardan kaydırma başka türlü çalışıyor. İzin akışları farklı; bir platformda bir kez sorulup geçilen izin, diğerinde reddedildikten sonra kullanıcıyı ayarlara yönlendirmeyi gerektirebiliyor. Klavye açıldığında ekranın nasıl davranacağı bile aynı değil.

Ayrı ayrı yazarken bu farkları görmezden gelemiyorsunuz, çünkü zaten platformun kendi bileşenleriyle çalışıyorsunuz. Uygulama “oraya ait” hissettiriyor. Tek kod tabanına geçtiğimde ilk kaybettiğim şey bu oldu: bu kararları artık platform benim yerime vermiyor, hepsini ben veriyorum.

Flutter'da ilk fark ettiğim şey: arayüz tamamen bana ait

Flutter ekranı platformun bileşenleriyle değil, kendi çizim katmanıyla oluşturuyor. Pratikteki sonucu şu: düzeni bir kez kuruyorsunuz ve iki platformda da aynı çıkıyor. Yerelde “iOS'ta yazı biraz büyük görünüyor”, “Android'de kart kenarı farklı kırpılıyor” diye giden hizalama uğraşı ortadan kalkıyor.

Bedeli ise hiçbir şeyin varsayılan olarak platforma benzememesi. Vakti Geçmeden ve Hadi Yapalım'da zamanımın kayda değer bir kısmı, iki platformda da doğal hissettiren geçişleri, dokunma tepkilerini ve kaydırma davranışını ayarlamaya gitti. Yerelde bedava gelen şeyi burada elle kuruyorsunuz.

Ne kazandım

İş	Yerel (iki kod tabanı)	Flutter (tek kod tabanı)
Yeni ekran eklemek	İki kez kurulum, iki kez test	Bir kez
Hata düzeltmek	İki yerde bulup iki yerde düzeltmek	Tek yerde
Tasarım tutarlılığı	Elle hizalanır, zamanla ayrışır	Doğal olarak aynı
Platforma özel davranış	Doğrudan, tam kontrol	Eklenti veya platform kanalı üzerinden
Mağaza yayını	İki ayrı süreç	Yine iki ayrı süreç

Tablodaki son satır önemli: mağaza tarafı hiç değişmiyor. İki ayrı geliştirici hesabı, iki ayrı inceleme süreci, iki ayrı sürüm notu, iki ayrı imzalama düzeni. Flutter kod yazma süresini kısaltıyor; yayına çıkma süresini kısaltmıyor. Geçişten önce bunun aksini bekleyen biriyseniz, hayal kırıklığı tam orada oluyor.

Ne kaybettim: derinlik ve eklenti bağımlılığı

Yerel yazarken bir platform yeteneğine ihtiyacım olduğunda gideceğim tek yer vardı: platformun kendi API'si. Flutter'da araya bir katman giriyor. İhtiyacınız olan şey için ya hazır bir eklenti buluyorsunuz ya da kendiniz yazıyorsunuz.

Eklenti bulmak kolay kısım. Zor kısım şu sorular: bunu kim sürdürüyor, yeni işletim sistemi sürümü çıktığında ne kadar sürede güncellenecek, iki platformda gerçekten aynı davranıyor mu? Yerelde bir API'yi, işletim sistemi çıktığı gün kullanabiliyordum. Şimdi araya birinin o API'yi sarmalaması gerekiyor ve o kişi ben değilsem takvimi de ben belirlemiyorum.

Eklentisi olmayan bir yetenek gerektiğinde platform kanalı yazıyorsunuz. Dart tarafı kabaca şuna benziyor:

static const _kanal = MethodChannel('uygulama/cihaz');

Future<String?> cihazEtiketi() async {
  try {
    return await _kanal.invokeMethod<String>('cihazEtiketi');
  } on PlatformException {
    // iki platformda da ayrı ayrı ele alınmalı
    return null;
  }
}

Peki kanalın diğer ucunda ne var? Kotlin ve Swift. Yani yerel yazmayı bırakmıyorsunuz, sadece daha azını yazıyorsunuz. Geçişin en çok yanlış anlatılan kısmı bu bence. Flutter, yerel bilgiyi gereksiz kılmıyor; onu daha seyrek ama daha kritik hâle getiriyor.

Yerel bilmek Flutter yazarken neden avantaj

Flutter'a sıfırdan başlayan biriyle, üç dilde yerel yazdıktan sonra başlayan biri aynı yerde durmuyor. Fark, her şey yolunda giderken görünmüyor; bir şey bozulduğunda ortaya çıkıyor.

• Derleme hataları çoğu zaman Dart tarafında değil, Gradle ya da Xcode tarafında çıkıyor. Bu çıktıları daha önce okumuşsanız korkutucu olmuyor, sıradan bir gün oluyor.
• İzin metinleri, arka planda çalışma kısıtları, bildirim kanalları, hedef API seviyesi — hepsi hâlâ yerel kavramlar. Flutter bunları ortadan kaldırmıyor, üzerlerine bir arayüz koyuyor.
• Bir eklenti beklediğiniz gibi davranmadığında içindeki Kotlin veya Swift kodunu açıp okuyabiliyorsunuz. Tek başına bu bile hata ayıklama süresini değiştiriyor.
• Mağaza reddi geldiğinde sebebin nerede olduğunu biliyorsunuz. İzin açıklaması yüzünden gelen bir ret, Flutter'ın değil iOS'un konusu.
• İmzalama, sürüm numaralandırma, test kanalları — bunlar zaten bildiğim işlerdi ve geçişte beni hiç yavaşlatmadı.

Arka uç tarafında ise hiçbir şey değişmedi. Yerel projelerimde de Flutter projelerimde de Firebase kullanıyorum: Firestore, Storage, Cloud Functions, Messaging. Veri modelini nasıl kuracağımı ve güvenlik kurallarını nasıl yazacağımı bilmek, dil değiştirince kaybolmayan bir bilgi oldu. Geçişte en rahat ettiğim yer burasıydı; sorunlar hep istemci tarafında çıktı.

Nerede hâlâ yerele inerim

Social Connect'te görüntülü görüşme vardı ve bunun için JitsiMeet'i kendi sunucumda, DigitalOcean üzerinde barındırdım. Bu tür işlerde — gerçek zamanlı medya, kamera ve mikrofonla derin temas, arka planda sürekli çalışma — yerel tarafa inmekten kaçınmak zor. Flutter kullansam bile o işin bir kısmını yine Kotlin ve Swift ile yazacağımı biliyorum.

Tek platform hedefleyen bir ürün için de yerel hâlâ makul. Yalnızca Android'e çıkacak bir uygulamada Kotlin yazmak, araya bir katman koymaktan daha doğrudan ve daha az sürprizli.

Şu an nerede duruyorum

2026'da Flutter ile üç uygulama yazdım: Vakti Geçmeden, Hadi Yapalım ve mağaza onay sürecinde olan Sinepia. Üçünde de tek kod tabanı, iki mağaza. Aynı işi yerel yazsaydım aynı sürede bu kadarını çıkaramazdım; bunu rahatlıkla söyleyebilirim.

Yine de Flutter'ı “doğru cevap” diye anlatmak istemiyorum. Yerelde geçirdiğim yıllar boşa gitmedi; tam tersine, Flutter'da rahat etmemin sebebi o yıllar. Katmanın altında ne olduğunu biliyorsanız katman size hız kazandırıyor. Bilmiyorsanız, ilk ciddi sorunda aynı katman bir duvara dönüşüyor.

Bugün yeni bir işe başlarken sorduğum soru “hangi teknoloji daha iyi” değil. Şu: bu ürünün platformla ne kadar işi var? Cevap “az” ise tek kod tabanı, “çok” ise yerel ya da karma bir yol. Üç dilde yerel yazmış olmam, bu soruyu tahminle değil deneyimle cevaplamamı sağlıyor.

• Flutter
• Swift
• Kotlin
• Java
• Çapraz Platform
• Mobil