Mobil Uygulamada Minimum iOS ve Android Sürümü Seçimi

Müşterileri için bir sipariş uygulaması, kendi teslimat şoförleri için de ayrı bir uygulama yaptıran bir toptancı düşünün. Projenin başında bir geliştirici kısa bir soru soruyor: "Minimum iOS ve Android sürümü ne olsun?" İş tarafında kimse sorunun ne anlama geldiğini bilmiyor; cevap "siz en iyisini bilirsiniz" oluyor. Geliştirici önceki projesinden makul bir değer seçiyor, bir yapılandırma dosyasına yazıyor ve konu bir daha açılmıyor.

Yayından altı ay sonra iki şey oluyor. Birkaç müşteri uygulamayı mağazada bulamadığını yazıyor. Şoförlerin birkaç yıl önce toplu alınmış şirket telefonlarının da geliştiricinin seçtiği sınırın hemen altındaki bir Android sürümünde çalıştığı ortaya çıkıyor. İkisi de hata değil. İkisi de varsayılan olarak verilmiş bir karardan geliyor.

Minimum işletim sistemi sürümü, uygulamanızı kimin kurabileceğini, her sürümün ne kadar test gerektirdiğini ve hangi özelliklerin ucuza yapılabileceğini belirler. Bu yüzden teknik cevabı olan bir iş kararıdır ve projenin başında bir saatlik bir konuşmayı hak eder.

1. Genel grafiklerden değil, kendi kullanıcılarınızdan başlayın

Platform geneli istatistikler ortalama telefonun neyle çalıştığını söyler. Sizin kullanıcılarınız ortalama değildir. Tek bir ülkede genç kullanıcılara yönelen bir tüketici uygulaması neredeyse herkesi yeni bir sürümde bulabilir. Daha yaşlı müşterilerin ya da şirketin verdiği cihazları kullanan çalışanların kullandığı bir B2B uygulamasında tablo çok farklı olabilir.

Seçmeden önce elinizdeki veriyi toplayın. Bir web siteniz varsa, analitiği mobil ziyaretçilerin işletim sistemlerini gösterir. Daha önce bir uygulamanız varsa, mağaza konsolu kurulumları işletim sistemi sürümüne göre gösterir. Uygulama kendi çalışanlarınız içinse, bilgi işlemden fiilen kullanılan cihazların listesini isteyin; kimsenin telefon diye düşünmediği depo el terminallerini ve tabletleri de dahil edin. Sonra bu kullanıcıların ne kadarını dışarıda bırakmayı kabul ettiğinize karar verin ve o sayıyı yazın.

2. Her eski sürümün maliyetini bilin

Eski bir sürümü desteklemek bedava değildir ve bu maliyet ilk tahminde nadiren görünür. Her ek sürüm, test listesine cihaz ya da simülatör ekler. Belirli bildirim seçenekleri, widget'lar ya da gizlilik izinleri gibi yeni sistem özellikleri eski sistemlerde yedek bir yol gerektirebilir; bu da aynı işi yapan iki ayrı kod demektir. Üçüncü taraf kütüphaneler ve SDK'lar kendi minimumlarını belirler; bağlı olduğunuz bir ödeme, harita ya da analitik SDK'sı eski bir sürümü bırakırsa, ya onun eskimiş sürümünde kalırsınız ya da onu izlersiniz.

Bunların hiçbiri her zaman yalnızca en yeni sürümleri desteklemeniz gerektiği anlamına gelmez. Takasın görünür olması gerektiği anlamına gelir. "Bir Android sürümünü daha desteklemek her yayında şu kadar test ekliyor ve şu özelliği dışarıda bırakıyor" sorusunu iş tarafı cevaplayabilir. "Minimum sürüm ne olsun?" sorusunu cevaplayamaz.

3. Minimumu hedeften ayırın

İki platformda da iki farklı sayı vardır ve sık sık karıştırılır.

Android'de minimum SDK, uygulamayı hangi cihazların kurabileceğini belirler. Hedef SDK ise sisteme uygulamanın hangi sürümün davranışına göre yapıldığını söyler. Google Play, yeni uygulamaların ve güncellemelerin yakın tarihli bir API düzeyini hedeflemesini şart koşar; yani minimumunuz yerinde dursa bile hedefin düzenli olarak ilerlemesi gerekir.

iOS'ta dağıtım hedefi (deployment target) uygulamayı çalıştırabilen en eski sürümdür; derlemede kullandığınız SDK ise kullandığınız Xcode sürümünden gelir. Apple da App Store'a gönderilen uygulamaların yakın tarihli bir Xcode ve SDK ile derlenmesini şart koşar.

Pratik sonuç şu: mağaza kurallarına uyarken eski cihazları desteklemeye devam edebilirsiniz, ama yalnızca iki sayı ayrı ayrı izlenirse ve hedefi her yıl ilerletmek birinin sorumluluğundaysa.

4. Geride bıraktığınız kullanıcılara ne olacağına karar verin

Minimumu yükseltmek uygulamayı eski telefonlardan silmez. Uygulamayı zaten kurmuş kullanıcılar kurulu sürümlerini korur; iOS'ta App Store, gereksinimi artık karşılamayan cihazlara son uyumlu sürümü sunabilir, Android'de ise yeni minimumun altındaki cihazlar yalnızca güncelleme almayı bırakır.

Bu, sunucu tarafında sessiz bir sorun yaratır. Eski uygulama sürümleri arka ucunuzu çağırmaya devam eder. Bir API cevabını değiştirir, bir alanın adını değiştirir ya da bir uç noktayı kaldırırsanız, bu kullanıcılar bir mesaj yerine hata görür. Alt sınırı yükseltmeden önce arka ucun eski uygulama sürümlerine ne kadar süre hizmet vereceğine karar verin ve API değişikliklerini eski istemciler ya çalışmaya devam edecek ya da açık bir mesaj alacak şekilde tasarlayın.

5. İlk sürümde bir sürüm kontrolü yayınlayın

Sürüm kontrolü eklemenin en ucuz anı, uygulama henüz kimsenin elinde değilken. Fikir basit: uygulama açılınca sunucuya desteklenen en düşük uygulama sürümünü sorar. Kurulu uygulama daha eskiyse, güncelleme gerektiğini açıklayan ve mağazaya bağlantı veren bir ekran gösterir. Daha yumuşak bir türü güncellemeyi önerir ama kullanıcının devam etmesine izin verir.

Bu kontrol olmadan, eskimiş uygulamadaki kullanıcılara ulaşmanın tek yolu eski sürümlerini sonsuza kadar çalışır tutmak ya da bozulmasına izin vermektir. Kontrol varsa eski sürümleri kendi takviminizle emekliye ayırabilirsiniz. Kontrolün kendisi hoşgörülü olmalı: sunucuya ulaşılamıyorsa uygulama kullanıcıyı kilitlemek yerine normal açılmalıdır.

6. Alt sınırı yılda bir, takvime bağlı olarak gözden geçirin

Minimum sürümler, bir şey değişikliği zorlayana kadar konuldukları yerde kalma eğilimindedir: bir kütüphane güncellemesi, bir mağaza kuralı, eski sistemlerde çalışmayan bir özellik. Baskı altında yapılan değişiklikler aceleye gelir ve kullanıcılar önceden uyarılmaz.

Büyük iOS ve Android sürümlerinden birkaç hafta sonrasına yıllık bir gözden geçirme koyun. Kurulum verilerinize yeniden bakın, bağlı olduğunuz SDK'ların minimumlarını kontrol edin ve sınırı taşıyıp taşımayacağınıza karar verin. Taşıyacaksanız, onları dışarıda bırakacak güncellemeden önce eski sistemlerdeki kullanıcılara uygulama içinde duyurun ki şaşırmasınlar.

Kısaca

Minimum işletim sistemi sürümünü genel grafiklerden değil, kendi kullanıcılarınızın cihazlarından seçin. Her eski sürümün maliyetini görünür kılın, minimum ve hedef sürümleri ayrı tutun, eski sürümde kalacak kullanıcıları planlayın, ilk yayından önce bir sürüm kontrolü ekleyin ve kararı yılda bir gözden geçirin. Böyle verildiğinde minimum sürüm bir yapılandırma dosyasındaki satır olmaktan çıkar, sahibi olan bir karara dönüşür.

Mobil projelerimizde minimum sürümleri projenin başında, müşterinin kendi cihaz ve analitik verileriyle birlikte belirliyor ve ilk sürüme sunucu taraflı bir sürüm kontrolü ekliyoruz.