Mobil Uygulama Bakımı: İşletim Sistemi Güncellemeleri ve Sürekli Destek

Uygulamanız mağazada, kullanıcılarınız memnun ve kimse kodun tek satırına dokunmuyor. Bir yıl sonra yeni bir iPhone modeliyle gelen müşteri ekranın kaydığını söylüyor, Google Play’den “uygulamanızı güncellemeniz gerekiyor” e-postası geliyor, ödeme ekranı ise sessizce hata vermeye başlıyor. Bunların hiçbiri kötü yazılmış koddan kaynaklanmaz; sebep, düzenli mobil uygulama bakımı yapılmamasıdır. Bu yazıda bir uygulamanın neden zamanla eskidiğini, bakımın neleri kapsadığını ve bütçe planlarken neye dikkat etmeniz gerektiğini anlatıyorum.

Uygulama neden kendiliğinden eskir?

Web sitesinde sunucuyu siz kontrol edersiniz; mobil uygulama ise başkalarının kurallarıyla yaşayan bir ortamda çalışır. Kod değişmese bile etrafındaki her şey değişir:

• İşletim sistemi sürümleri: Apple ve Google her yıl iOS ve Android’in yeni ana sürümlerini yayımlar. İzinler, bildirimler, arka plan çalışma kuralları ve ekran davranışları değişebilir.
• Yeni cihazlar: Farklı ekran oranları, çentikler, katlanabilir ekranlar ve tabletler arayüzün yeniden kontrol edilmesini gerektirir.
• Mağaza kuralları: Google Play uygulamaların belirli bir süre içinde güncel Android sürümlerini hedeflemesini şart koşar; Apple da belirli aralıklarla yeni geliştirme araçlarıyla derleme ister. Bu şartlara uymayan uygulamalar yeni kullanıcılara gösterilmeyebilir ya da güncelleme yayımlanamaz.
• Kütüphaneler ve SDK’lar: Ödeme, harita, bildirim ve analiz için kullanılan paketler güncellenir; eski sürümler desteklenmez hâle gelebilir.
• Arka uç ve entegrasyonlar: Bağlı olduğunuz bir servis API’sini değiştirdiğinde uygulamanın ilgili bölümü çalışmayı bırakabilir.

Mağaza kurallarının güncel ayrıntılarını Apple ve Google’ın geliştirici sayfalarından takip etmek gerekir; tarihler ve şartlar her yıl değişebiliyor.

Mobil uygulama bakımı neleri kapsar?

Bakım yalnızca “bir şey bozulunca düzeltmek” değildir. Sağlıklı bir bakım planı genellikle şu kalemlerden oluşur:

Kalem	Ne yapılır?	Sıklık
İşletim sistemi uyumu	Yeni iOS ve Android sürümlerinin beta ve kararlı sürümlerinde test, gerekli düzeltmeler	Yıllık ana sürümler ve ara güncellemeler
Hedef sürüm ve derleme güncellemesi	Mağaza şartlarına uygun hedef sürüm ve araçlarla yeniden derleme	Mağaza takvimine göre
Bağımlılık güncellemeleri	Flutter, paketler ve SDK’ların güncel ve güvenli sürümlere taşınması	Periyodik
Hata takibi	Çökme raporlarının izlenmesi, tekrar eden hataların giderilmesi	Sürekli
Güvenlik	Bilinen açıkları olan paketlerin değiştirilmesi, sertifika ve anahtar yenilemeleri	İhtiyaç anında
Arka uç bakımı	Sunucu, veritabanı, yedekleme ve API uyumu	Sürekli
Küçük iyileştirmeler	Kullanıcı geri bildirimine göre metin, akış ve ekran düzenlemeleri	Anlaşmaya göre

Çökme ve hata raporlarını izlemek

Kullanıcıların çoğu bir hata gördüğünde size yazmaz, uygulamayı kapatır ya da siler. Bu yüzden uygulamaya bir çökme raporlama aracı eklemek ve raporları düzenli okumak bakımın temelidir. Hangi cihazda, hangi sürümde, hangi ekranda sorun yaşandığını görmek, sorunu kullanıcı şikâyetinden önce yakalamayı sağlar.

Sertifikalar ve hesaplar

iOS tarafında bildirim ve dağıtım için kullanılan sertifika ve anahtarların süresi dolabilir; geliştirici hesaplarının yenilenmesi unutulursa uygulama mağazadan kaldırılabilir. Bu tür idari işler küçük görünür ama aksadığında doğrudan kullanıcıyı etkiler. Hesapların kimin adına açıldığını ve yenileme tarihlerini kayıt altında tutmak gerekir; mağaza hesabı süreçlerini uygulamayı mağazaya yükleme yazısında anlattım.

Bakım yapılmazsa neler olur?

Bakımı ertelemek kısa vadede tasarruf gibi görünür ama maliyet birikerek geri gelir. Sık karşılaşılan senaryolar şunlar:

1. Yeni işletim sistemi sürümünde bildirimler gelmez ya da izin ekranı hiç çıkmaz.
2. Mağaza şartlarına uyulmadığı için acil bir hata düzeltmesi bile yayımlanamaz; önce birikmiş tüm güncellemeleri yapmak gerekir.
3. Kullanılan bir ödeme ya da harita paketi desteklenmez hâle gelir ve ilgili ekran çalışmaz.
4. Birkaç yıl dokunulmamış bir projede bağımlılıklar o kadar eskir ki küçük bir değişiklik bile büyük bir yenileme işine dönüşür.

Son madde özellikle önemlidir. Düzenli küçük güncellemeler, yıllarca biriktirilip bir anda yapılan büyük güncellemeden hem daha ucuz hem daha az risklidir.

Bakım bütçesini ne belirler?

Mobil uygulama bakımı için tek bir rakam vermek doğru olmaz; maliyeti belirleyen etkenleri bilmek daha faydalıdır:

• Uygulamanın büyüklüğü: Ekran sayısı ve iş kurallarının karmaşıklığı.
• Entegrasyon sayısı: Ödeme, kargo, harita, bildirim, muhasebe gibi her dış servis ayrı bir takip noktasıdır.
• Platformlar: Yalnızca Android mi, iOS da mı, tablet desteği var mı?
• Arka uç: Sunucu ve panel bakımı da sözleşmeye dahil mi?
• Yanıt süresi beklentisi: Kritik hatada aynı gün müdahale mi, haftalık planlı çalışma mı?
• Geliştirme talepleri: Bakım içinde yeni özellik geliştirme saati olacak mı?

Bu kalemlerin bir sözleşmede nasıl tanımlanacağını yazılım bakım anlaşması yazısında ayrıntılı anlattım.

Bu işi nasıl birlikte yaparız?

İster benim geliştirdiğim ister başka bir ekibin yaptığı bir uygulama olsun, bakım süreci benzer adımlarla ilerler:

1. Mevcut durum incelemesi: Kaynak koda, kullanılan Flutter veya yerel kod sürümüne, paketlere, mağaza hesaplarına ve sunucuya bakar, riskli noktaları listelerim.
2. Bakım kapsamı ve teklif: Hangi işlerin düzenli, hangilerinin talep üzerine yapılacağını ve yanıt sürelerini birlikte belirleriz.
3. Güncelleme ve test: Gerekli güncellemeleri yapar, gerçek cihazlarda ve test kanallarında denedikten sonra mağazaya gönderirim.
4. Düzenli takip: Çökme raporlarını ve mağaza bildirimlerini izler, işletim sistemi takvimine göre önceden hazırlık yaparız.

Uygulamanızın bakım ihtiyacını değerlendirmek isterseniz iletişim sayfasından bana ulaşabilirsiniz.

Sık sorulan sorular

Başka bir yazılımcının yaptığı uygulamanın bakımını üstlenir misiniz?

Kaynak kodun eksiksiz teslim edilmiş olması ve mağaza hesaplarına erişim sağlanabilmesi şartıyla evet. Önce kodu inceleyip mevcut durumu ve riskleri raporluyorum, ardından bakım kapsamını belirliyoruz.

Her işletim sistemi güncellemesinde uygulamayı güncellemek gerekir mi?

Her ara güncellemede değil, ama yıllık ana sürümlerde mutlaka test yapılmalıdır. Sorun çıkmazsa güncelleme gerekmeyebilir; mağazanın hedef sürüm şartları ise ayrıca takip edilmelidir.

Bakım ile yeni özellik geliştirme aynı şey mi?

Hayır. Bakım, uygulamanın mevcut hâliyle sorunsuz çalışmaya devam etmesini sağlar. Yeni özellikler ayrı bir geliştirme işidir; bazı anlaşmalarda belirli bir saat kotası olarak bakıma eklenebilir.

Uygulama hiç güncellenmezse mağazadan kalkar mı?

Mağaza şartlarına uzun süre uyulmazsa uygulama yeni kullanıcılara gösterilmeyebilir ya da kısıtlanabilir. Kesin kuralları Apple ve Google’ın güncel geliştirici politikalarından kontrol etmek gerekir.

Sonuç

Mobil uygulama bakımı, yayın gününden sonra başlayan ve uygulamanın ömrü boyunca süren bir sorumluluktur; düzenli yapıldığında hem kullanıcı deneyimini hem de yatırımınızı korur. Uygulamanız için sürdürülebilir bir bakım planı oluşturmak isterseniz benimle iletişime geçebilirsiniz.