Android ve iOS için tek uygulama: Flutter ne zaman doğru seçimdir?

Bir şirket çalışanları ya da müşterileri için bir uygulama geliştirmeye karar verdiğinde, erken bir aşamada şu soru gündeme gelir: Biri Android, diğeri iOS cihazlar için iki ayrı uygulama mı geliştirelim, yoksa her ikisinde de çalışan tek bir uygulama mı?

Bu yalnızca teknik bir soru değildir. Kaç ekibe ihtiyacınız olacağını, aynı özelliğin kaç kez yazılacağını ve canlıya geçişten sonra her değişikliğin ne kadara mal olacağını belirler. Flutter, bu soruyu tek bir uygulamayla yanıtlayan seçeneklerden biridir; bu yazıda ne zaman uygun olduğunu ve ne zaman olmadığını anlatıyoruz.

İki platform için tek kod tabanı ne anlama gelir?

Flutter, Android ve iOS üzerinde çalışan uygulamaları tek bir kod tabanından geliştirmek için kullanılan bir framework’tür; web ve masaüstü platformlarını da destekler. Ekip ekranları ve iş kurallarını bir kez yazar; ardından bunlardan her platform için ayrı bir uygulama derlenir ve o platformun mağazasında yayımlanır.

Bunun karar verici için üç doğrudan etkisi vardır:

• Bir özelliğin büyük bölümü, iki farklı dilde iki kez yazılmak yerine bir kez yazılır ve bir kez test edilir.
• Ayrıntılarda farklı kararlar verebilecek iki ekip yerine, uygulamanın tamamını bilen tek bir ekip çalışır.
• İki platformda aynı davranış: aynı kurallar, alanlarda aynı doğrulama ve kullanıcıya aynı mesajlar.

Bu durum, ilk geliştirmeden çok canlıya geçişten sonraki bakıma yansır. Her hata düzeltmesi ve bir iş kuralındaki her değişiklik bir kez yapılır ve iki platformun kullanıcılarına aynı anda ulaşır; biri diğerinin gerisinde kalmaz.

Maliyet açısından ise tek uygulama, maliyetin kendiliğinden yarıya ineceği anlamına gelmez; ama emeğin büyük bölümünün tekrarlanmayacağı anlamına gelir. Tasarım, iş kuralları, sunucuyla bağlantı ve temel testler bir kez hazırlanır; ek emek yalnızca her platforma özgü kısımlarla sınırlı kalır.

Ancak “tek kod tabanı” tam olarak “tek iş” anlamına gelmez. Her platformun yine kendine ait yayımlama ayarları, mağaza gereksinimleri ve izinleri vardır; uygulamanın da yalnızca birinde değil, her iki platformun cihazlarında test edilmesi gerekir.

Flutter ne zaman uygundur?

Flutter, iş uygulamalarının çoğu için uygundur; çünkü bu uygulamaların ihtiyaç duyduğu şeyler, Flutter’ın sunduklarının özünde yer alır:

• Formlar ve listeler: sipariş girişi, ziyaret kaydı, faturaların ve bakiyelerin görüntülenmesi, ürün arama.
• Tutarlı bir arayüz: Ekranlar iki platformda da aynı görünür ve aynı şekilde çalışır; bu da çalışanlara anlatmayı ve onlara destek vermeyi kolaylaştırır.
• Çevrim dışı veri: Flutter’ın resmî dokümantasyonu, daha sonra sunucuyla senkronize edilen yerel bir veri tabanına dayanan, çevrim dışı çalışan uygulama desenini ele alır.
• Arapça ve yazı yönü: Flutter, resmî yerelleştirme kütüphanesi aracılığıyla birçok dili destekler ve arayüzün yönünü seçilen dile göre sağdan sola ya da soldan sağa ayarlar.
• Şirketin ERP sistemi ya da mevcut satış sistemi gibi sistemleriyle API üzerinden bağlantı.

“İnternet kesildiğinde de çalışan sistemler: Pazarlarımızda neden önemli?” başlıklı makalemizde senkronizasyon ve çakışma çözümüyle ilgili kararları ele almıştık. Flutter’ı seçmek bu kararları değiştirmez; değişen, bu kararların iki platform için bir kez yazılmasıdır.

Arapça arayüz bilinçli bir özen ister

Framework düzeyindeki yazı yönü desteği bir başlangıç noktasıdır, varış noktası değil. İyi bir Arapça arayüz bilinçli kararlar gerektirir: hangi simgelerin yönle birlikte aynalanacağı ve hangilerinin olduğu gibi kalacağı; Latin harfli adların ve kodların Arapça bir metnin içinde nasıl görüneceği; sayıların, tarihlerin ve para birimlerinin nasıl gösterileceği.

Bu yüzden ekranları, uygulama İngilizce olarak tamamlanıp çevrildikten sonra değil, ilk prototipten itibaren Arapça olarak test ediyoruz. Çünkü Arapça metin İngilizce karşılığından daha uzun ya da daha kısa olabilir ve tek bir yön varsayımıyla kurulmuş bir tasarımı bozabilir.

Bir dağıtım şirketinin satış temsilcileri için bir uygulama istediğini varsayalım: Uygulama müşteri ve ürün listelerini gösterecek, siparişleri bağlantı yokken de kaydedecek ve bağlantı geri geldiğinde şirketin sistemine gönderecek. Temsilcilerin bir kısmı Android, bir kısmı iOS cihaz kullanıyor. Bu, Flutter’ın uygun düştüğü bir durumdur: net iş ekranları, Arapça arayüz, yerel veri ve uygulamanın tamamını yöneten tek bir ekip.

Native uygulama ne zaman daha uygun olabilir?

Native uygulama, her platform için o platformun kendi araçları ve diliyle ayrı olarak geliştirilen uygulamadır. Belirli durumlarda daha uygun olabilir:

• Uygulama özünde işletim sistemine derinden bağlı özelliklere dayanıyorsa; örneğin özel cihazlarla sıkı bir entegrasyon ya da her işletim sisteminin kendine özgü kurallar dayattığı arka plan görevleri söz konusuysa.
• Arayüzün her platformun stilini en ince ayrıntısına kadar izlemesi ve Android ile iOS arasında büyük ölçüde farklılaşması gerekiyorsa.
• İşletim sistemindeki yeni özelliklere, Flutter’da bunları kullanmanın hazır bir yolu çıkmadan, yayımlandıkları anda ihtiyaç duyuluyorsa.
• Ekibiniz her platform için native geliştirmede zaten deneyimliyse ve yeniden geliştirilmesi zor olan mevcut uygulamalarınız varsa.

Buradaki maliyet açıktır: İki uygulama geliştirmek, iki ekip ya da iki dilde çalışan bir ekip demektir; her özellik iki kez yazılır ve iki kez test edilir, her değişiklik de iki platforma aynı anda ulaşması için koordinasyon gerektirir. Dolayısıyla bu seçenek, sunduğu şey uygulama için gerekli olduğunda maliyetine değer; genel bir tercih olduğunda değil.

Bu durumlarda bile seçim ya hep ya hiç meselesi değildir. Flutter, belirli bir özellik için her platforma özel kod yazılmasına olanak tanır: Android’de Kotlin ya da Java, iOS’ta Swift ya da Objective-C ile. Uygulama bu kodla platform channels adı verilen iletişim kanalları üzerinden haberleşir. Böylece uygulamanın büyük bölümü paylaşılan kod tabanında kalır, yalnızca özel kısım her platform için ayrıca yazılır.

Önemli olan, bu özel kısımları projenin ortasında değil, başlamadan önce bilmektir. Çünkü her biri iki kez yazılan, test edilen ve bakımı yapılan kod demektir ve en baştan maliyet hesabına katılmalıdır.

Seçimden önce sorulacak sorular

1. Uygulamayı kimler, hangi cihazlarda kullanacak? Cihazlar şirkete mi ait, yoksa herkes kendi cihazını mı kullanıyor?
2. Neyin çevrim dışı çalışması gerekiyor ve cihazda hangi veriler saklanacak?
3. Uygulama, barkod okumak için kamera, konum ya da bağlı bir yazıcıdan çıktı alma gibi cihaza özgü özelliklere ihtiyaç duyuyor mu? Bunların Flutter’da hazır desteği var mı, yoksa her platforma özel kod mu gerekiyor?
4. Arayüz yalnızca Arapça mı, yoksa birden fazla dilde mi olacak; yalnızca sağdan sola mı, yoksa her iki yönde de mi çalışacak?
5. Uygulama mevcut sistemlerinize nasıl bağlanacak ve bu sistemlerin hazır bir API’si var mı?
6. Canlıya geçişten sonra uygulamanın bakımını kim yapacak ve ekibiniz hangi konularda deneyimli?

Bu soruların yazılı yanıtları, tartışmayı teknik tercihlerden net gereksinimlere taşır; seçenekleri ve maliyetlerini bu gereksinimlere göre karşılaştırabilirsiniz.

Yanıtlardan sonra da tereddüt sürüyorsa, uygulamanın en zor özelliğini içeren, bir ya da iki ekranlık küçük bir prototip geliştirmek, projenin tamamı için taahhüde girmeden önce meseleyi sınırlı bir maliyetle karara bağlar.

Uygulamanın daha büyük bir sistemin parçası olduğunu da unutmayın. Fiyatlar, yetkiler ve onaylar gibi temel iş kurallarının yeri uygulama değil, sunucudur. Bu da framework kararını göründüğünden daha az riskli kılar; çünkü sistemin özü bu karara bağlı değildir.

Hızlı karar rehberi

• Android ve iOS kullanıcılarına yönelik, formlar, listeler ve raporlardan oluşan, Arapça arayüzlü bir iş uygulaması: Flutter çoğu zaman uygun bir seçimdir.
• Sahada çevrim dışı çalışan ve merkez sistemle senkronize olan bir uygulama: Flutter, senkronizasyon kurallarının kodlamadan önce netleştirilmesi şartıyla uygundur.
• Cihaza özgü bir ya da iki özelliğe ihtiyaç duyan bir uygulama: Flutter ve yalnızca bu özellikler için her platforma özel kod.
• Özü tek bir platforma derinden bağlı bir özelliğe dayanan bir uygulama: İşe o platform için native uygulamayı değerlendirerek başlayın.
• Arayüzünün her platformun stiline tam olarak uyması gereken bir uygulama: Karar vermeden önce iki seçeneği küçük bir prototiple karşılaştırın.

Flutter’ı seçmek tek başına teknik bir karar değildir; uygulamanın ömrü boyunca geliştirme ve bakım maliyetini, ayrıca ekibin büyüklüğünü belirleyen bir karardır. Durumunuz iki platform için Arapça arayüzlü bir iş uygulamasıysa, tek kod tabanı bir kez yazılan özellikler ve herkese aynı anda ulaşan değişiklikler demektir. Durumunuzu ITS ekibiyle görüşebilirsiniz; Flutter’ın uygulamanız için uygun olup olmadığını ve uygulamanın hangi kısımlarının her platforma özel kod gerektirdiğini birlikte belirleyelim.