Mobil Uygulama Bakım ve Destek

Uygulama mevcut bir React Native projesi veya farklı bir teknolojiyle yapılmış olabilir; bakım kapsamı teknoloji adından önce erişim ve çalıştırılabilirlik üzerinden değerlendirilir. Kaynak kodun bulunması, yeni bir sürüm hazırlanabildiğini tek başına kanıtlamaz. Geliştirme ortamı ve uygulama imzalama bilgileri de gerekir.

Devralma envanterinde mağaza konsolları, kod deposu, backend, veritabanı, bildirim ve analitik araçlarının sahipliği kontrol edilir. İşletmeye ait olması gereken hesaplar ile önceki tedarikçiye bağlı erişimler ayrılır. Hassas anahtarlar açık belgelerde paylaşılmaz; erişim devri güvenli yöntemle planlanır.

İlk incelemede mevcut sürümün nasıl üretildiği ve hangi dış servislere bağlı olduğu anlaşılır. Giriş, temel işlem ve veri güncelleme gibi kritik görevler denenir. Sonuç; devralınabilecek bakım kapsamı, önce çözülmesi gereken engeller ve eksik belgelerin listesidir. İnceleme olmadan her eski projeye aynı bakım taahhüdü verilmez.

Hata verilerini toplamak için Firebase tabanlı araçlar değerlendirilebilir; ancak bir raporun gelmesi sorunun çözüldüğü anlamına gelmez. Crashlytics gibi araçlar çökme ve bazı hata olaylarını gruplandırır. Okunabilir rapor için sürüme uygun sembol veya eşleştirme bilgisi önemlidir.

Bir hatanın önceliği yalnızca tekrar sayısıyla belirlenmez. Kullanıcı hangi işi tamamlayamıyor, hangi sürüm ve cihaz etkileniyor, geçici bir çözüm var mı? Örnek olarak nadir görülen ödeme kaybı, sık görülen küçük görsel hatadan daha öncelikli olabilir. Bu örnek gerçek proje sonucu değil, öncelik kararının mantığıdır.

Destek kaydı için sürüm, cihaz, zaman ve tekrar adımı yeterli ayrıntıyla alınır. Kullanıcı mesajı, çökme verisi ve backend kaydı birlikte değerlendirilir; kişisel bilgi gereksiz loglara eklenmez. Düzeltme sonrası ilgili senaryo ve yakın işlevler denenir. Kayıt, yalnızca “kapandı” işaretiyle değil hangi davranışın doğrulandığıyla tamamlanır.

Bağımlılık güncellemesi örneğin React Native sürüm yükseltme çalışması kadar geniş olabilir. Bakım içinde küçük paket güncellemesiyle eski bir ana sürümden geçiş aynı iş sayılmamalıdır. Hangi bileşenin değişeceği, neden gerektiği ve hangi görevlerin yeniden test edileceği yazılır.

Google Play hedef API koşulları yeni uygulama gönderimi, güncelleme ve mevcut uygulamanın bulunabilirliği için farklı sonuçlar doğurabilir. Uygulama türüne göre istisnalar da vardır. Bu nedenle geçerli gereksinim ve tarih konsol kaydı ile resmî dokümandan kontrol edilir; eski bir blogdaki sürüm numarası bakım kararının temeli olmaz.

Yeni işletim sistemi; izin, bildirim, dosya erişimi veya arayüz davranışını etkileyebilir. Hedef sürümün yanında desteklenecek eski cihazlar da belirlenir. Mağaza inceleme ve onay süresi ekibin kontrolünde değildir. Yayın planı bunu dikkate almalı; teknik hazırlığın tamamlanmasıyla mağaza onayı birbirine karıştırılmamalıdır.

Kullanıcı “uygulama yavaş” dediğinde mobil performans incelemesi ekran, cihaz ve işlem bağlamıyla başlamalıdır. Açılış, liste kaydırma, görsel yükleme ve API yanıtı farklı sorunlardır. Yalnızca genel bir puan üzerinden tüm uygulamanın aynı şekilde çalıştığı sonucuna varılamaz.

Örnek bir randevu uygulamasında takvim geç açılıyorsa mobil kod, bağlantı veya backend sorgusu ayrı ayrı incelenebilir. API yanıtı doğru fakat ekranda eski veri görünüyorsa önbellek ve güncelleme davranışı değerlendirilir. Kullanıcının işini tamamlamasını etkileyen adım, teknik ölçümün anlamını belirler.

Bakım sınırında backend ve üçüncü taraf servislerin kim tarafından yönetildiği belirtilir. Mobil ekip sorunu tespit edebilirken dış sağlayıcı düzeltmeyi üstlenebilir. Giriş, bildirim veya ödeme zincirinde birden çok ekip varsa haber verme ve takip sorumluluğu netleşmelidir. Tüm hizmetleri kontrol etmeden uçtan uca erişilebilirlik sözü verilmez.

Mobil bakımın sürüm ve yayın süreci, değişikliğin riskine göre planlanır. Bir düzeltme diğer platform veya ekranı etkileyebilir. Geliştirme, kabul ve mağaza gönderimi için sorumlular; kullanıcıya ne zaman ve hangi yolla ulaşacağıyla birlikte tanımlanır.

Kritik görev listesi teslim sırasında hazırlanır ve sonraki sürümlerde kullanılır. Örnek görevler giriş, kayıt, ödeme veya uygulamaya özgü ana işlem olabilir. Desteklenen cihaz ve işletim sistemi kapsamı belirtilir. Her cihazı sınamak mümkün olmadığında temsilî cihaz seçiminin gerekçesi açıklanır.

Canlı sürüm sonrası çökme, hata ve görev tamamlama sinyalleri kontrol edilir. Uzaktan içerik veya bazı kod değişiklikleri için farklı yayın yolları bulunabilir; her değişikliğin anında ve mağaza incelemesi olmadan ulaştırılacağı varsayılmaz. Geri dönüş yolu, uygulamanın ve backend'in sürüm uyumuyla birlikte değerlendirilir.

Ürün yol haritasında teknik kararlar için dış kaynak CTO desteği ayrı bir ihtiyaç olabilir. Bakım paketi, tüm ürün yönetimini veya sınırsız yeni özelliği otomatik kapsamaz. Hata müdahalesi ve uyumluluk çalışmaları, yeni özellikler için mobil uygulama geliştirme kapsamından teklifte ayrı gösterilmelidir.

SLA'da bildirim kanalı, çalışma saatleri, öncelik tanımı ve yanıt hedefi bulunur. Yanıt, incelemeye başlandığını bildirir; çözüm süresi sorunun kaynağına ve dış bağımlılıklara bağlı olabilir. Acil müdahale, hafta sonu veya sürekli izleme ancak doğrulanmış kapasite ve anlaşma varsa kapsamda yer alır.

Bakım bütçesi kodun durumu, platformlar, backend, kullanıcı görevleri ve gereken destek düzeyine göre belirlenir. Her uygulamaya aynı yıllık oran uygulanmaz. İlk görüşmeye mağaza bağlantıları, teknoloji bilginiz varsa onun özeti ve sizi en çok zorlayan hata örneğiyle başlayın; inceleme, sürdürülebilir planın temelini oluşturur.