Çorum · Android & iOS
Çorum'da Android ve iOS uygulama geliştirme işinin büyük kısmında iki ayrı uygulama yazdırmanıza gerek yok. Flutter ile tek kod tabanı yazıp iki platforma da aynı ürünü çıkarıyorum; ayrı native geliştirme (Kotlin ve Swift) yalnızca ağır 3D, AR, oyun veya derin cihaz donanımı gerektiren işlerde gerçekten mantıklı. İki platformun asıl farkı kod tarafında değil, mağaza tarafında ortaya çıkıyor: Apple Developer Program yıllık 99 USD ve App Store inceleme süreci, Google Play Console'da tek seferlik 25 USD ve yeni geliştirici hesapları için kapalı test şartı. Derleme ve imzalama, test dağıtımı, bildirim altyapısı, gizlilik formları ve sürüm yönetimi de platforma göre değişiyor. Bu sayfada iki platform arasındaki teknik ve operasyonel farkları, yayına çıkarken karşınıza gelecek adımları anlatıyorum.
İlk görüşmelerde en sık gelen soru bu. Kısa cevabı: iki ayrı uygulama yazdırmak teknik olarak mümkün ama işletme uygulamalarının büyük bölümünde gereksiz bir maliyet kalemi. Kotlin ile Android, Swift ile iOS tarafını ayrı yazdırdığınızda aynı ekranı iki kez tasarlamış, iki kez test etmiş ve her değişikliği iki kez yapmış oluyorsunuz.
Flutter'da ise arayüz ve iş mantığı tek yerde duruyor; iki platforma aynı kaynaktan derliyorum, değişiklikleri tek yerde düzeltip iki mağazaya birlikte gönderiyorum. Kamera, konum, bildirim, dosya seçici ve ödeme gibi yaygın cihaz yeteneklerine erişim de mevcut.
Dürüst olmak gerekirse tek kod tabanı her iş için doğru cevap değil. Ağır 3D grafik, artırılmış gerçeklik, oyun motoru gerektiren yapılar ya da cihaz donanımına derin dokunan işler (özel Bluetooth protokolleri, sistem seviyesi entegrasyonlar) native tarafta yazılmaya daha uygun. Böyle bir ihtiyacınız varsa bunu baştan söylerim.
| Kriter | Flutter (tek kod tabanı) | Ayrı native (Kotlin + Swift) |
|---|---|---|
| Geliştirme süresi | Arayüz ve iş mantığı bir kez yazılır; iki platform tek takvimde ilerler | Her platform kendi takvimini ister; toplam süre belirgin şekilde uzar |
| Ekip ihtiyacı | Tek geliştirici iki platformu yürütebilir | Android ve iOS için ayrı uzmanlık; genelde iki kişi ya da iki ekip |
| Güncelleme yükü | Değişiklik tek yerde yapılır, iki mağazaya birlikte gönderilir | Aynı değişiklik iki kod tabanında ayrı ayrı yazılır ve ayrı test edilir |
| Uygun olduğu iş | İşletme, sipariş, rezervasyon, üyelik, içerik ve yayın uygulamaları | Ağır 3D/AR, oyun motoru gerektiren ürünler, derin cihaz donanımı entegrasyonları |
App Store'da yayın yapmak için Apple Developer Program üyeliği gerekiyor; üyelik yıllık 99 USD ve her yıl yenilenmesi lazım, yenilenmediğinde uygulama mağazadan kalkıyor. Şirket adına açılacaksa Apple ek kurumsal doğrulama isteyebiliyor; bu da takvime eklenmesi gereken bir bekleme.
iOS uygulamasının derlenmesi için macOS çalıştıran bir bilgisayar şart, çünkü Xcode yalnızca Mac üzerinde çalışıyor. Bu benim tarafımdaki bir gereklilik; sizin ayrıca cihaz almanız gerekmiyor.
Apple, gönderilen her sürümü insan eliyle inceliyor ve süre sabit değil; dönemsel yoğunluklarda uzuyor. Bu yüzden lansman tarihi verirken inceleme için pay bırakıyorum. Ret yaşanırsa gerekçe yazılı geliyor, düzeltip yeniden gönderiyoruz.
En sık karşılaşılan ret gerekçeleri tahmin edilebilir: uygulamanın çökmesi ya da inceleme sırasında boş ekran vermesi, giriş isteyen bir uygulama için test hesabı verilmemesi, gizlilik politikası bağlantısının olmaması veya çalışmaması, hesap oluşturmaya izin verilip hesap silme yolunun sunulmaması, uygulamanın esasen bir web sitesinin çerçeve içine alınmış hâli olması, izin isterken sebebinin açıklanmaması ve mağaza görsellerinin uygulamanın gerçek içeriğiyle uyuşmaması. Bunların hepsi gönderim öncesinde kontrol edilebilir maddeler.
Yayına çıkmadan önce uygulamayı TestFlight ile dağıtıyorum. Böylece siz ve ekibiniz gerçek cihazlarda, mağazadan indirilmiş gibi test ediyorsunuz. Geri bildirimleri buradan topluyoruz; sürüm mağazaya ancak siz onayladıktan sonra gidiyor.
Google Play tarafında geliştirici hesabı ücreti tek seferlik 25 USD; yıllık yenileme yok. Hesap açılışında kimlik ve adres doğrulaması isteniyor, kurumsal hesaplarda bu adımlar daha uzun sürebiliyor.
Android tarafında son yıllarda değişen en önemli konu kapalı test (closed testing) şartı. Yeni açılan kişisel geliştirici hesaplarında, uygulamayı herkese açık yayına almadan önce belirli sayıda test kullanıcısıyla belirli bir süre kapalı test yapma zorunluluğu bulunuyor. Yani hesabı açıp uygulamayı aynı gün yayına verme dönemi kişisel hesaplar için kapandı.
Google bu şartları zaman zaman güncelliyor; gereken test kullanıcısı sayısı, sürenin uzunluğu ve hangi hesap türlerinin kapsama girdiği değişebiliyor. Bu yüzden burada kesin bir rakam yazmıyorum, planlamayı başvuru anındaki güncel şartlara göre yapıyoruz. Projeye başlarken Play Console'daki yürürlükteki gereklilikleri kontrol edip takvimi ona göre kuruyorum.
Pratikte bunun anlamı şu: mağaza hesabını projenin sonunda değil, geliştirme sürerken açmak gerekiyor. Kapalı test süresi geliştirmeyle paralel işlerse yayın tarihi kaymıyor. Test kullanıcı listesini de baştan hazırlıyoruz; genelde işletmenin kendi ekibi ve yakın çevresi yeterli oluyor.
Play Console'un kanalları kademeli işliyor: kapalı test, açık test ve üretim. Kademeli yayın sayesinde uygulamayı önce kullanıcıların bir bölümüne açıp hata oranını izleyebiliyoruz.
Hangi işletim sistemi sürümlerine kadar destek verileceği, projenin başında verilen ve sonradan değiştirilmesi zahmetli olan bir karar. Çok eski sürümleri desteklemek test yükünü ve kod içindeki istisna sayısını artırıyor; fazla yeniyi taban almak ise bir kısım kullanıcıyı uygulamanın dışında bırakıyor.
Genel yaklaşımım, güncel sürümden birkaç kuşak öncesini kapsayan bir taban belirleyip bunu kullanıcı kitlenize göre ayarlamak; kitlenizde eski cihaz oranı yüksekse tabanı aşağı çekiyoruz. Bu kararı tahminle değil, varsa mevcut web sitenizin ziyaretçi verisiyle veriyoruz.
Mağazalar ayrıca hedef sürüm konusunda kendi alt sınırlarını dayatıyor ve bu sınırı her yıl yukarı çekiyor. Yani uygulamanız hiç değişmese bile, yeni sürüm gönderebilmek için yılda bir hedef sürümü güncellemek gerekiyor.
Ekran boyutu tarafında iş telefonla bitmiyor: büyük ekranlı modeller, tabletler ve katlanabilir cihazlar farklı davranıyor. Arayüzü esnek kuruyorum, sonra emülatörde farklı boyutlarda ve elimdeki gerçek cihazlarda geçiyorum. Belirli bir modelde çalışması kritikse o cihazı test aşamasında temin etmeyi baştan planlıyoruz.
Kod tek olsa da bazı konularda iki platform ayrı ayrı yapılandırma istiyor. Bunlar genelde ürünün görünen yüzünde değil, arka tarafta ve mağaza formlarında karşınıza çıkıyor.
Android bildirimleri Firebase Cloud Messaging üzerinden gidiyor, iOS tarafında ise Apple'ın APNs servisi devrede ve ayrı sertifika/anahtar yapılandırması gerekiyor. Uygulamayı FCM ile tek noktadan yönetiyorum ama iOS için Apple tarafındaki anahtarların kurulması ayrı bir adım.
Kamera, konum, bildirim, fotoğraf erişimi gibi izinlerde iOS her izin için kullanıcıya gösterilecek gerekçe metnini zorunlu tutuyor. Android'de izin akışı ve arka plan konum gibi hassas izinler için ek gerekçelendirme isteniyor. Bu metinleri baştan birlikte yazıyoruz.
Her iki mağaza da hangi veriyi topladığınızı, ne amaçla kullandığınızı ve üçüncü taraflarla paylaşıp paylaşmadığınızı beyan etmenizi istiyor: Apple'da App Privacy, Google'da Data safety formu. Beyanın uygulamanın gerçek davranışıyla birebir uyuşması gerekiyor.
Dijital içerik veya abonelik satıyorsanız mağazanın kendi satın alma sistemini kullanmak ve komisyonunu hesaba katmak gerekiyor. Fiziksel ürün veya yerinde verilen hizmet satışında bu zorunluluk yok; ödemeyi doğrudan ödeme sağlayıcısı üzerinden alabiliyoruz. Sattığınız şeyin hangi kategoriye girdiğini baştan netleştirmek sonradan gelen retleri önlüyor.
Android tarafında imzalama anahtarı, iOS tarafında sertifika ve provisioning profilleri var. Bu anahtarların kaybı ileride ciddi sorun; hesapları sizin adınıza açıp anahtarların yedeğini size teslim ediyorum.
Yayın gecikmelerinin çoğu koddan değil, eksik mağaza materyalinden çıkıyor. Aşağıdaki maddelerden biri eksikse gönderim yapılamıyor ya da inceleme aşamasında ret geliyor. Bu listeyi geliştirme bitmeden paylaşıyorum, iki iş paralel yürüsün.
Problem, kullanıcı ve hedefi konuşup kapsamı netleştiriyorum.
Wireframe, UI ve marka dili — Figma ile hızlı iterasyon.
Flutter ile uçtan uca mobil ürün; Firebase ve API entegrasyonları.
Gerçek kullanım senaryolarına uygun akıllı özellikler ve performans.
Canlıya alma, geri bildirim ve sürekli iyileştirme döngüsü.
Çoğu iş için gerekmez. Flutter ile tek kod tabanı yazıp iki platforma da aynı ürünü çıkarıyorum, böylece ekranlar bir kez yazılıyor ve sonraki değişiklikler tek yerde yapılıyor. Ağır 3D, artırılmış gerçeklik, oyun motoru ya da derin donanım entegrasyonu gerektiren işlerde ayrı native geliştirme daha doğru; böyle bir durumda bunu açıkça söylerim.
Apple Developer Program yıllık 99 USD, Google Play Console ise tek seferlik 25 USD. Apple üyeliği her yıl yenilenmezse uygulama App Store'dan kalkıyor, Google Play tarafında ise yıllık bir yenileme yok. Hesapların sizin adınıza açılmasını öneriyorum; uygulama ve anahtarlar böylece sizin mülkünüzde kalır.
Sabit bir süre yok, iki platform da kendi takvimini dayatıyor. App Store'da her sürüm insan eliyle inceleniyor ve süre dönemsel yoğunluğa göre değişiyor; Google Play'de yeni kişisel geliştirici hesapları için yayın öncesi kapalı test şartı bulunuyor. Bu yüzden mağaza hesaplarını geliştirme sürerken açıyoruz, süreçler paralel ilerlesin.
Yeni açılan kişisel geliştirici hesaplarında, uygulamayı herkese açık yayına almadan önce belirli sayıda test kullanıcısıyla belirli bir süre kapalı test yapma zorunluluğu bulunuyor. Google bu şartları zaman zaman güncellediği için burada kesin rakam vermiyorum; planlamayı başvuru anındaki güncel şartlara göre yapıyoruz. Pratik sonucu, hazır bir test kullanıcı listesine ihtiyaç duymanız.
Ret, sürecin normal bir parçası ve genelde düzeltilebilir bir sebepten kaynaklanıyor. Apple gerekçeyi yazılı olarak bildiriyor; en sık görülenler eksik test hesabı, çalışmayan gizlilik politikası bağlantısı, hesap silme yolunun bulunmaması ve inceleme sırasında oluşan çökmeler. Gerekçeyi giderip sürümü yeniden gönderiyorum, bu iş için ayrıca ücret talep etmiyorum.
Belirlediğimiz sürüm tabanına kadar çalışır. Güncel sürümden birkaç kuşak öncesini kapsayan bir taban seçiyorum ve bunu kullanıcı kitlenize göre ayarlıyoruz; kitlenizde eski cihaz oranı yüksekse tabanı aşağı çekiyoruz. Mağazalar hedef sürüm alt sınırını her yıl yukarı çektiği için bu ayarın yıllık bakımda gözden geçirilmesi gerekiyor.
Uygulamanızın hangi platformda önce çıkacağını, mağaza hesaplarını ve yayın takvimini birlikte netleştirelim. [email protected] adresine yazabilir ya da WhatsApp'tan (+90 539 590 55 19) ulaşabilirsiniz. Çorum'daysanız yüz yüze, başka bir şehirdeyseniz uzaktan görüşüyoruz.
Çorum'da mobil uygulama geliştirme: Flutter ile Android ve iOS uygulaması. Fikirden yayına süreç, süreyi etkileyen faktörler ve teslim sonrası bakım.
Çorum'da Flutter ile iOS ve Android mobil uygulama geliştiriyorum. Tek kod tabanı, Firebase mimarisi ve açık kaynak paket deneyimiyle uçtan uca teslim.
Hizmetlerin tamamı, çalıştığım sektörler ve sık sorulanlar tek sayfada.