Kurumsal mobil uygulama geliştirme süreci nasıl işler?
Kurumsal mobil uygulama; keşif, prototip, ilk sürüm kapsamı, mimari ve arka uç, kısa döngülerle geliştirme, test, dağıtım ve bakım aşamalarından geçer. Tüketici uygulamasından farkı ekranlarda değil, ekranların arkasındadır: kurumsal kimlik doğrulama, ERP veya CRM entegrasyonu, cihaz yönetimi, verinin cihazda nasıl korunacağı, sahada bağlantısız çalışma ve uygulamanın çalışanlara nasıl dağıtılacağı. Bu kararların çoğu projenin başında verilir ve sonradan değiştirmek pahalıdır.
| Aşama | Ne yapılır? | Çıktı | Karar noktası |
|---|---|---|---|
| 1. Keşif | Kullanıcılar, kullanım anları, bağlanılacak sistemler, cihazlar ve güvenlik gereksinimleri çıkarılır | Kapsam notu, entegrasyon envanteri, risk listesi | Uygulama gerçekten gerekli mi, mobil uyumlu web yeterli mi? |
| 2. Prototip | Ana akışlar tıklanabilir bir prototiple gerçek kullanıcılara gösterilir | Onaylanmış akışlar | Akışlar sahadaki işe uyuyor mu? |
| 3. İlk sürüm kapsamı | İlk sürümün işlevleri, kabul ölçütleri ve sonraya kalanlar yazılır | Kapsam belgesi | Teknoloji, dağıtım kanalı ve güvenlik profili |
| 4. Mimari ve arka uç | API, kimlik doğrulama, bildirim, yönetim paneli ve eşitleme tasarlanır | API sözleşmesi, mimari kararlar | Mevcut arka uç kullanılabilir mi? |
| 5. Geliştirme | Kısa döngüler; her döngü sonunda test cihazlarına kurulabilen bir sürüm | Çalışan sürümler | Öncelikler her döngü sonunda gözden geçirilir |
| 6. Test | Cihaz ve işletim sistemi matrisi, zayıf ağ, çevrim dışı durum, reddedilen izinler, güvenlik testi | Test raporu | Yayın ölçütleri karşılandı mı? |
| 7. Dağıtım | Mağaza kayıtları ya da kurumsal dağıtım, gizlilik beyanları, aşamalı açılış | Yayındaki sürüm | Önce pilot bir gruba mı açılacak? |
| 8. İşletim ve bakım | Çökme izleme, işletim sistemi ve mağaza kuralı güncellemeleri, yeni sürümler | Sürüm planı | Eski sürümler ne kadar desteklenecek? |
Native mi, çapraz platform mu, mobil web mi?
Teknoloji, uygulamanın cihazdan ne istediğine ve bakımını kimin yapacağına göre seçilir. Swift (iOS) ve Kotlin (Android) ile native geliştirme, platform özelliklerine en doğrudan erişimi verir. Flutter veya React Native gibi çapraz platform araçlar tek kod tabanıyla iki platformu hedefler; cihaza özgü bir özellik gerektiğinde native bir modülle tamamlanır. Mağazaya hiç girmeyen mobil uyumlu bir web uygulaması da bazı kurumsal ihtiyaçlar için yeterlidir.
| Durum | Daha uygun seçenek | Not |
|---|---|---|
| İki platformda aynı akışlar, form ağırlıklı bir iş uygulaması | Çapraz platform | Native modül ihtiyacı baştan listelenmeli |
| Kamera, Bluetooth, arka planda konum veya barkod okuyucu yoğun kullanılıyor | Native ya da native modüllü çapraz platform | Cihaz üreticisinin yazılım kitinin hangi platformları desteklediğini kontrol edin |
| Kurumun tüm cihazları tek platformda, örneğin yalnızca Android el terminalleri | O platform için native | İkinci platform ihtiyacı doğarsa karar yeniden değerlendirilir |
| Uygulama nadiren açılıyor, kurulum bir engel | Mobil uyumlu web uygulaması | Çevrim dışı çalışma ve bildirim ihtiyacını ayrıca değerlendirin |
| Sağlıklı çalışan bir native uygulama zaten var | Mevcut kod tabanında devam | Yeniden yazmak ayrı bir karardır |
Karar verirken iki soru daha sorun: Uygulamanın bakımını kim yapacak ve o ekip hangi teknolojide yetkin? Kullanılacak güvenlik, cihaz yönetimi ve kimlik kütüphaneleri seçilen teknolojide destekleniyor mu?
Kurumsal uygulama nasıl dağıtılır: mağaza mı, kurum içi mi?
Müşteriye dönük uygulamalar App Store ve Google Play'den, yalnızca çalışanların kullanacağı uygulamalar ise çoğu zaman özel dağıtım kanallarından yayımlanır. Android tarafında yönetilen Google Play'deki özel uygulamalar yalnızca belirlenen kuruluşlara görünür; bir uygulama en fazla 1.000 kuruluşla sınırlandırılabilir ve Play Console'dan ya da kurumun EMM (kurumsal mobilite yönetimi) konsolundan yayımlanır. Apple tarafında standart Apple Developer Program, kurumun kendi çalışanlarına özel uygulamaları Apple Business üzerinden özel (custom) uygulama olarak ya da Ad Hoc yoluyla dağıtmasına ve test sürümlerini TestFlight'tan vermesine izin verir. Apple Developer Enterprise Program ise yalnızca bu yolların karşılamadığı belirli kurum içi kullanım durumları içindir; en az 100 çalışan, tüzel kişilik ve D-U-N-S numarası ister ve Apple'ın doğrulama görüşmesinden geçmeyi gerektirir.
Mağaza kuralları kapsamı doğrudan etkiler. Bunları tasarıma baştan eklemek, inceleme aşamasındaki gecikmeleri önler:
- Hesap silme: App Store İnceleme Yönergeleri (5.1.1(v)), hesap açılabilen uygulamalarda hesabın uygulama içinden silinebilmesini ister. Google Play buna ek olarak, kullanıcının hesap ve veri silme talep edebileceği bir web bağlantısı da ister.
- İnceleme için çalışan arka uç: Apple yönergeleri (2.1), giriş gerektiren uygulamalar için demo hesap bilgisi verilmesini ve arka uç hizmetinin açık olmasını ister. Kurumsal kimlik doğrulaması olan uygulamalarda bu demo hesabın nasıl sağlanacağı baştan planlanmalıdır.
- Veri kullanımı beyanı: Apple yönergeleri (5.1.2), kişisel verinin üçüncü taraflarla, üçüncü taraf yapay zekâ servisleri dahil, nerede paylaşılacağının açıkça bildirilmesini ve önceden açık izin alınmasını ister. Uygulamaya eklenen her analitik ya da yapay zekâ servisi bu beyanı etkiler.
- Hedef API düzeyi şartı: Google Play'in hedef API düzeyi şartına göre 31 Ağustos 2026'dan itibaren yeni uygulamalar ve güncellemeler Android 16'yı (API 36) hedeflemelidir; mevcut uygulamaların daha yeni Android sürümlerindeki yeni kullanıcılara görünmeye devam etmesi için en az Android 15'i (API 35) hedeflemesi gerekir. Yalnızca belirli bir kuruluşun kullanıcılarına sınırlandırılmış, kalıcı olarak özel uygulamalar bu şartın istisnaları arasındadır; yani dağıtım kanalı seçimi bakım yükünü de etkiler.
- Hesap türü: Google Play, 13 Kasım 2023'ten sonra açılan kişisel geliştirici hesaplarında, uygulama yayına alınmadan önce en az 12 test kullanıcısıyla en az 14 gün kesintisiz kapalı test ister. Kurumsal uygulamalarda hesabı şirket adına açmak, uygulamanın ve kullanıcı değerlendirmelerinin sahipliğini de şirkette tutar.
Ekipte hangi roller olmalı?
Kurumsal mobil projede kişi sayısından çok rollerin eksiksiz olması önemlidir; bir kişi birden fazla rolü üstlenebilir ama hiçbir rol boş kalmamalıdır. Bazı roller tedarikçiden, bazıları mutlaka kurumdan gelir.
| Rol | Sorumluluk | Kimden? | Eksikse ne olur? |
|---|---|---|---|
| Ürün sorumlusu | Öncelikleri belirler, kapsam kararlarını verir, kabulü yapar | Kurum | Kararlar gecikir, kapsam kayar |
| İş analisti | Akışları, kuralları ve istisnaları yazılı hâle getirir | Tedarikçi veya kurum | Geliştirme varsayımlarla ilerler |
| UX/UI tasarımcı | Akışları, prototipi ve arayüzü platform alışkanlıklarına uygun tasarlar | Tedarikçi | Kullanıcılar uygulamayı benimsemez |
| Mobil geliştirici | iOS ve Android uygulamasını ya da çapraz platform kodunu geliştirir | Tedarikçi | Uygulama yazılamaz |
| Arka uç geliştirici | API, kimlik, bildirim, eşitleme ve yönetim panelini geliştirir | Tedarikçi | Uygulama veri bekleyen bir kabuk olarak kalır |
| Test uzmanı | Cihaz matrisi, regresyon, çevrim dışı ve güvenlik senaryolarını yürütür | Tedarikçi; kabul testinde kurum | Hatalar sahada bulunur |
| Yayın ve altyapı | Derleme hattı, imzalama, mağaza veya EMM yayını, izleme | Tedarikçi | Her sürüm elle ve riskli çıkar |
| Kurum BT ve güvenlik | Kimlik sağlayıcı, cihaz yönetimi, ağ ve güvenlik politikası | Kurum | Entegrasyonlar son ana kalır |
| Veri sorumlusu ve hukuk | KVKK aydınlatma metni, açık rıza ihtiyacı, saklama süreleri | Kurum | Gizlilik soruları yayından hemen önce çıkar |
| Pilot kullanıcılar | Prototipi ve test sürümlerini gerçek işte dener | Kurum | Uygulama masa başında doğru, sahada yanlış olur |
Mobil uygulama güvenliği nasıl planlanır?
Güvenliği planlamanın en pratik yolu, teklif aşamasında hedef güvenlik profilini OWASP MASVS'ye göre yazmaktır. OWASP MASVS (Mobil Uygulama Güvenliği Doğrulama Standardı), mobil saldırı yüzeyini sekiz kontrol grubuna ayırır. OWASP'ın MAS test profilleri de tehdit modeline göre seçilen varsayılan seviyeler sunar: MAS-L1'de cihazdaki diğer uygulamalar saldırgan kabul edilir; MAS-L2'de işletim sistemine güvenilmez ve saldırganın cihaza fiziksel erişimi olabilir; MAS-R'de cihazın kullanıcısı da saldırgan olabilir; MAS-P ise kişisel verinin korunmasına odaklanır. OWASP, mümkünse uygulamaya özel bir tehdit modeli yapılmasını, değilse bu varsayılan profillerin kullanılmasını önerir.
| MASVS grubu | Sorulacak soru | Tipik tasarım kararı |
|---|---|---|
| MASVS-STORAGE | Hangi veri cihazda kalacak, ne kadar süre? | Hassas veri en aza indirilir; anahtarlar iOS Keychain ve Android Keystore'da tutulur |
| MASVS-CRYPTO | Şifreleme nerede ve hangi anahtarla yapılıyor? | Platformun kriptografi altyapısı kullanılır; anahtar uygulama paketine gömülmez |
| MASVS-AUTH | Kimlik doğrulama ve yetki nerede denetleniyor? | Kurumsal kimlik sağlayıcıyla tek oturum; yetki sunucuda denetlenir |
| MASVS-NETWORK | Trafik nasıl korunuyor? | Tüm trafik şifreli; sertifika sabitleme (pinning) tehdit modeline göre kararlaştırılır |
| MASVS-PLATFORM | Uygulama sistemle ve diğer uygulamalarla nasıl etkileşiyor? | İzinler gerektiği anda istenir; derin bağlantılar ve paylaşım akışları denetlenir |
| MASVS-CODE | Bağımlılıklar ve girdiler nasıl yönetiliyor? | Bağımlılıklar düzenli güncellenir; desteklenen en eski işletim sistemi sürümü yazılır |
| MASVS-RESILIENCE | Tersine mühendislik ve kurcalama gerçek bir risk mi? | Yalnızca tehdit modeli gerektiriyorsa eklenir |
| MASVS-PRIVACY | Hangi kişisel veri, hangi amaçla toplanıyor? | Veri en aza indirilir; üçüncü taraf yazılım kitleri listelenir ve beyanlarla uyumlu tutulur |
Profili tehdit modeli belirler. Örneğin cihazlar kaybolabiliyor ve üzerinde müşteri verisi kalıyorsa MAS-L2'ye, uygulamadaki iş mantığının kullanıcı tarafından kötüye kullanılması bir riskse MAS-R'ye bakmak gerekir. Seçilen profil teklifte yazılı olmalıdır; aksi hâlde tedarikçiler farklı güvenlik işlerini fiyatlar.
Kurumsal mobil uygulamanın maliyet kalemleri nelerdir?
Maliyeti ekranlardan çok arka uç, entegrasyonlar, cihaz ve işletim sistemi kapsamı, güvenlik profili ve yayından sonraki bakım belirler. Fiyat vermiyoruz; teklifte ayrı satır olarak görmeniz gereken kalemler şunlardır:
| Kalem | Neye bağlıdır? | Tek seferlik mi, sürekli mi? |
|---|---|---|
| Keşif ve UX tasarımı | Kullanıcı grupları, akış sayısı, prototip testleri | Tek seferlik; büyük sürümlerde tekrar |
| Mobil uygulama geliştirme | Platform sayısı, akış sayısı, native modül ihtiyacı | İlk sürüm ve her yeni sürüm |
| Arka uç, API ve yönetim paneli | Mevcut arka ucun durumu, roller, raporlar | İlk sürüm ve bakım |
| Entegrasyonlar | ERP, CRM, kimlik sağlayıcı, ödeme, harita | İlk sürüm; karşı sistem değiştikçe tekrar |
| Çevrim dışı çalışma ve eşitleme | Veri hacmi ve çakışma kuralları | Tek seferlik; kurallar değişirse tekrar |
| Test | Cihaz ve işletim sistemi listesi, otomasyon düzeyi | Her sürümde |
| Güvenlik testi | Seçilen MAS profili, bağımsız test ihtiyacı | İlk yayında ve büyük sürümlerde |
| Dağıtım | Geliştirici hesapları, mağaza kayıtları, EMM yapılandırması | Kurulum bir kez; yayın her sürümde |
| Üçüncü taraf servisler | Bildirim, harita, SMS, analitik, çökme raporlama | Kullanıma göre sürekli |
| Barındırma | Arka uç trafiği, depolama, ortam sayısı | Sürekli |
| Bakım | İşletim sistemi sürümleri, hedef API şartı, bağımlılık ve güvenlik güncellemeleri | Sürekli |
| Kurumun kendi zamanı | Ürün sorumlusu, BT ekibi, pilot kullanıcılar | Proje boyunca |
Teklif aşamasında en sık unutulan iki kalem, desteklenecek cihaz ve işletim sistemi listesi ile yayın sonrası bakımdır. Listeyi genişletmek her sürümde test yükünü artırır; bakımı kapsam dışı bırakmak ise uygulamayı mağaza şartlarının gerisinde kalma riskiyle karşı karşıya bırakır.
Yayından sonra bakım neden zorunludur?
Mobil uygulama, üzerinde çalıştığı platform sürekli değiştiği için hiçbir zaman tam anlamıyla "bitmiş" bir ürün değildir. Google'ın ifadesiyle her yeni Android sürümü güvenlik ve performans değişiklikleri getirir; mağazaya açık uygulamalar hedef API şartına uymak zorundadır, Apple ve Google mağaza kurallarını günceller, kütüphaneler güvenlik yamaları yayımlar ve arka uçtaki değişiklikler sahada eski sürümü kullanan cihazları etkiler. Bakım anlaşmasında şu maddeleri arayın:
- İşletim sistemi takvimi: Yeni iOS ve Android sürümlerinin beta döneminde uygulamanın test edilmesi.
- Zorunlu güncellemeler: Hedef API ve mağaza kuralı değişikliklerinin kimin sorumluluğunda olduğu; özel dağıtılan uygulamada bile yeni işletim sistemi sürümleriyle uyumun nasıl korunacağı.
- Bağımlılık ve güvenlik güncellemeleri: Kütüphanelerin hangi sıklıkla gözden geçirileceği.
- Eski sürüm politikası: API değiştiğinde sahadaki eski sürümlerin nasıl destekleneceği ve zorunlu güncellemenin nasıl tetikleneceği.
- İzleme: Çökme ve hata raporlarının kişisel veri içermeden toplanması ve kimin takip edeceği.
- Hesap ve anahtar sahipliği: Geliştirici hesaplarının, imza anahtarlarının ve sertifikaların kurum adına tutulması.
- Gizlilik beyanları: Yeni bir yazılım kiti eklendiğinde mağaza beyanlarının güncellenmesi.
Varsayımsal örnek: saha servis ekibi için iş emri uygulaması
Bu örnek varsayımsaldır; gerçek bir müşteriyi anlatmaz. Bir ekipman servis şirketi, teknisyenlerinin iş emirlerini kâğıt form yerine mobil uygulamayla kapatmasını istiyor. Teknisyenlerin bir kısmı şirketin verdiği dayanıklı Android cihazları, bir kısmı şirket iPhone'larını kullanıyor; servis noktalarının bir bölümünde bağlantı yok. Uygulama iş emrini ERP'den almalı, fotoğraf ve müşteri imzası eklemeli, kapanan işi ERP'ye geri yazmalı.
| Karar | Seçim | Gerekçe |
|---|---|---|
| Teknoloji | Çapraz platform; kamera ve barkod için native modül | İki platformda aynı, form ağırlıklı akış; donanım ihtiyacı sınırlı |
| Dağıtım | Android'de yönetilen Google Play özel uygulaması, iOS'ta Apple Business üzerinden özel uygulama | Uygulama yalnızca çalışanlar için ve cihazlar EMM ile yönetiliyor |
| Kimlik | Şirketin kimlik sağlayıcısıyla tek oturum | Ayrılan çalışanın erişimi merkezi olarak kapatılır |
| Çevrim dışı | İş emri cihaza önceden indirilir, kapanış kuyruğa yazılır | Bağlantısız noktada veri kaybolmaz; çakışma kuralı yazılı |
| Güvenlik profili | MAS-L1 temel alınır, cihazda kalan müşteri verisi için MAS-L2 kontrolleri eklenir | Kaybolan cihaz senaryosu tehdit modelinde |
| Test kapsamı | Sahadaki cihaz modelleri ve desteklenen en eski işletim sistemi sürümleri | Test matrisi gerçek cihaz envanterinden çıkarılır |
Uygulama kalıcı olarak şirkete özel dağıtıldığı için Google Play'in hedef API şartının istisnası kapsamındadır; yine de yeni Android ve iOS sürümleriyle uyum testi bakım planında kalır. Bu örnekte maliyeti en çok etkileyen iki kalem ekranlar değil, çevrim dışı eşitleme ve ERP entegrasyonudur. Keşifteki ilk soru da buna göre şekillenir: ERP'nin iş emri için bir API'si var mı, test ortamı kimde? Şirkette eski bir saha uygulaması varsa, yeniden yazmak ile aşamalı yenilemek arasındaki seçimi uygulama modernizasyonu karar rehberimizde anlattık.
Teklif isterken tedarikçiye hangi soruları sormalı?
- Geliştirici hesapları, imza anahtarları ve kaynak kod kimin adına tutulacak?
- Hangi MAS profili hedefleniyor ve nasıl doğrulanacak?
- Desteklenecek cihaz ve işletim sistemi listesi nedir, test hangi gerçek cihazlarda yapılacak?
- Çevrim dışı çalışmada çakışan kayıtlar için hangi kural geçerli olacak?
- Arka uç ve yönetim paneli teklife dahil mi?
- Bakım anlaşması zorunlu platform güncellemelerini ve mağaza kuralı değişikliklerini kapsıyor mu?
- Mağaza ya da EMM yayını, gizlilik beyanları ve inceleme süreci kimin sorumluluğunda?
- Proje bittiğinde hangi belgeler teslim edilecek, başka bir ekip uygulamayı nasıl devralacak?
Çıkış ve devir maddeleri için tedarikçi seçimi yazımızdaki sorular mobil projelere de uygulanır.
Hatson Tech kurumsal mobil projeleri nasıl yürütüyor?
Uygulamayı, arkasındaki arka uç ve yönetim paneliyle birlikte tasarımdan mağaza yayınına ve yayından sonraki bakıma kadar tek ekip olarak teslim ediyoruz. Geliştirici hesaplarının şirketiniz adına açılmasını öneriyoruz; böylece uygulama, kullanıcılar ve değerlendirmeler sizde kalır. Sabit bir fiyat listemiz yok; ilk görüşme ve keşif ücretsizdir, sonraki aşamaların teklifi kapsam netleştikten sonra yazılı olarak verilir. Ayrıntılar mobil uygulama geliştirme sayfamızda. Uygulamanın kimler için, hangi cihazlarda ve hangi sistemlerle çalışacağını anlatırsanız, ilk görüşmede ilk sürümün kapsamını ve platform seçimini birlikte netleştirebiliriz.