Kurumsal mobil uygulama geliştirme: bayi, saha ve katalog senaryoları
Kurumsal mobil uygulama geliştirme, bir iş sürecinin telefona taşınması ve o yazılımın mağazada yayında tutulmasıdır. Bayi siparişi, saha servisi, stok takibi ve ürün kataloğu senaryolarını; uygulamayı ve web sitesini aynı içerik kaynağından besleyecek şekilde kuruyoruz.
Kurumsal bir uygulamada hangi iş kimin sorumluluğunda?
Kurumsal mobil uygulamalarda üç iş düzenli olarak sahipsiz kalır: uygulama ile web içeriğinin aynı kaynaktan beslenmesi, mağaza listeleme metinlerinin ve görsellerinin yönetimi, işletim sistemi ile mağaza şartları değiştiğinde sürüm planlaması. Bu üçünü sözleşmede ada yazıyoruz; pazarlama ajansı ile yazılım ekibi arasındaki boşlukta bırakmıyoruz.
| Sorumluluk | Pazarlama ajansı | Yazılım ajansı | Baki Bilişim |
|---|---|---|---|
| Uygulama içeriği ile web sitesi içeriği tek kaynaktan beslenir mi? | Kapsam dışı | Kısmen | Evet |
| Mağaza listeleme metni, ekran görselleri ve gizlilik beyanı kimin işi? | Kısmen | Kapsam dışı | Evet |
| İşletim sistemi ve mağaza şartı değiştiğinde sürümü kim planlar? | Kapsam dışı | Kısmen | Evet |
Bu iş bölümünün neden tek sözleşmede toplandığını Neden Baki Bilişim sayfasında ayrıntısıyla açıklıyoruz.
Mobil uygulama olmadan bu işler nerede birikiyor?
Bayi siparişi telefonla ve mesajlaşma uygulamalarından, saha raporu kâğıttan, stok bilgisi tablo dosyalarından yürüdüğünde veri sisteme sonradan elle giriliyor. Kayıp iki yerde birikiyor: veri girişinde harcanan saatler ve gecikmiş, doğrulanmamış veriyle alınan kararlar. Kurumsal uygulama bu akışı kaynağında dijitalleştirir, sonradan toplamaz.
Bayi sipariş ve katalog
Bayi; kendine tanımlı fiyat listesini, cari durumunu ve stok görünürlüğünü uygulamada görür, katalogdan sipariş oluşturur, geçmiş siparişini tekrarlar, sevkiyatı izler. Kritik ayrım şudur: fiyat ve stok verisi uygulamada tutulmaz, ERP'den okunur. Katalog metinleri web sitesindeki ürün sayfalarıyla aynı kaynaktan beslendiğinde iki kanalda iki farklı ürün açıklaması oluşmaz.
Saha ekibi ve teknik servis
Servis teknisyeni iş emrini uygulamada alır, cihaz veya seri numarasını okutur, arıza formunu doldurur, fotoğraf ekler ve müşteri onayını ekrandan alır. Tesis içinde şebekenin zayıf olduğu noktalarda çevrimdışı çalışma ve bağlantı geri geldiğinde senkronizasyon zorunludur. Bu gereksinim, teknoloji seçimini doğrudan belirleyen ilk maddedir.
Üretim ve stok takibi
Depoda ve üretim sahasında barkod veya QR okutarak giriş-çıkış, sayım ve üretim adımı kaydı yapılır. Burada belirleyici olan ekran sayısı değil, okutma hızı ve veri doğruluğudur. Elde terminal yerine telefonla çalışılacaksa kamera tabanlı okuma performansı ve dayanıklı cihaz uyumu, geliştirme başlamadan gerçek sahada test edilir.
Kurumsal iletişim ve eğitim
Çok lokasyonlu şirketlerde duyuru, prosedür, eğitim içeriği ve form akışları tek uygulamada toplanır. İçerik yönetimi kurum içi ekipte kalır; her duyuru için yeni sürüm çıkılmaz. İçerik uygulamanın içinden güncellenir, mağaza güncellemesi yalnızca işlev değiştiğinde gerekir. Bu ayrım baştan kurulmazsa iletişim ekibi her metin değişikliği için yazılım ekibine bağımlı kalır.
Uygulamayı yayınlamak kadar sürdürmek de bir yükümlülüktür
iOS ve Android her yıl yeni bir büyük sürüm yayınlar; mağazalar hedef API düzeyi, izin gerekçeleri ve gizlilik beyanı şartlarını bu takvime göre günceller. Bakım planı olmayan uygulama önce bildirimlerde, kamera ve konum izinlerinde bozulmaya başlar, ardından mağaza şartlarını karşılayamaz duruma gelir.
1 yıl
Google Play, yeni uygulamaların ve güncellemelerin, en son büyük Android sürümünden en fazla bir yıl geride bir hedef API düzeyi kullanmasını şart koşuyor. Şartı karşılamayan uygulamalar için yeni sürüm yayınlanamıyor.
Kaynak: Android Developers — Google Play hedef API düzeyi şartı (yeni sekmede açılır) · Erişim: 2026-07-29
Kurumsal bir mobil uygulama projesinde tam olarak ne teslim edilir?
Dokuz kalem teslim edilir: senaryo ve ekran envanteri, teknoloji seçim kararı, veri modeli ve API sözleşmesi, arayüz tasarımı ve token dosyası, iki platformun kaynak kodu, test dağıtımı, mağaza yayın dosyası, ölçüm kurulumu, bakım ve devir dokümanı. Her kalemin formatı ve teslim haftası sözleşmede yazılıdır.
| # | Teslimat | Format | Ne zaman |
|---|---|---|---|
| 01 | Senaryo, kullanıcı rolleri ve ekran envanteri | Doküman + ekran listesi | 2. hafta |
| 02 | Teknoloji seçim kararı ve gerekçesi | Karar notu | 3. hafta |
| 03 | Veri modeli ve API sözleşmesi | OpenAPI şeması | 5. hafta |
| 04 | Arayüz tasarımı ve tasarım token'ları | Tasarım dosyası + token dosyası | 6. hafta |
| 05 | iOS ve Android uygulama kaynak kodu | Müşteri hesabındaki depoya erişim | Sprint sonlarında sürekli |
| 06 | Test dağıtımı ve cihaz test raporu | Davetli test sürümü + rapor | 9. haftadan itibaren |
| 07 | Mağaza yayın dosyası: listeleme metinleri, ekran görselleri, gizlilik ve veri güvenliği beyanları | Müşterinin mağaza hesabında hazır | Yayından 2 hafta önce |
| 08 | Ölçüm kurulumu: çökme raporlama, sürüm ve performans izleme | Panel erişimi | Yayın öncesi |
| 09 | Bakım planı, sürüm takvimi ve teknik devir dokümanı | Yazılı plan + devir oturumu | Teslimde |
Native mi cross-platform mı, karar neye göre veriliyor?
Karar dört ölçüte bağlıdır: cihaz API ihtiyacı, güncelleme sıklığı, uygulamayı sürdürecek ekip ile bütçe ve takvim. Yoğun sensör kullanımı, çevrimdışı senkronizasyon ve arka plan işleri native tarafa; form, liste, katalog ve sipariş akışları tek kod tabanına işaret eder. Kararı gerekçesiyle yazılı veriyoruz.
| Karar ölçütü | Native tarafa işaret eder | Tek kod tabanı yeterlidir |
|---|---|---|
| Cihaz API'si | BLE, NFC, arka plan konumu, kamera üzerinde işleme | Standart kamera, bildirim, konum ve dosya erişimi |
| Güncelleme sıklığı | Yılda birkaç büyük sürüm, platforma özel yenilikler | Sık ve küçük sürümler, iki platforma aynı anda |
| Ekip ve devralma | İç ekipte iOS ve Android geliştiricisi var | Tek ekip iki platformu birlikte sürdürecek |
| Bütçe ve takvim | İki ayrı kod tabanı ve iki ayrı bakım bütçesi ayrılabiliyor | Tek bütçe; mağaza farkları için ayrı efor planlanır |
| Performans profili | Sürekli sensör, yoğun grafik, uzun süreli arka plan işi | Form, liste, katalog ve sipariş ekranları |
| Uzun vadeli sahiplik | Platform yol haritasına doğrudan bağlı kalınabiliyor | Çatı sürüm yükseltmeleri bakım planına yazılır |
Proje hangi aşamalardan geçiyor?
Altı aşama var: senaryo ve kapsam, mimari ve teknoloji kararı, arayüz ve tasarım sistemi, geliştirme ve entegrasyon, test ve mağaza hazırlığı, yayın ile sürüm yönetimi. Her aşamanın kendi teslimatı, ölçüm kriteri ve sorumlu tarafı vardır; hiçbiri “sonra bakarız” diye bırakılmaz.
-
01
Senaryo ve kapsam
Uygulamayı kimin, hangi işi yaparken kullanacağı rol bazında yazılır. Bayi veya saha tarafında yerinde gözlem yaparız; kapsam dışı listesi ilk aşamada açıkça belirlenir.
-
02
Mimari ve teknoloji kararı
Native ya da tek kod tabanı kararı dört ölçütle verilir. ERP, stok ve kimlik doğrulama tarafındaki entegrasyon yüzeyi ile çevrimdışı çalışma gereksinimi bu aşamada netleşir.
-
03
Arayüz ve tasarım sistemi
Ekranlar, iki platformun kendi arayüz kılavuzuna uyacak biçimde tasarım token'ları üzerinden kurulur. Kurumsal kimliğiniz varsa token dosyası oradan gelir, yoksa bu projede üretilir.
-
04
Geliştirme ve entegrasyon
İki haftalık ritimle çalışırız; her ritim sonunda test sürümü çıkar. ERP ve stok bağlantısı, kimlik doğrulama, çevrimdışı depolama ve senkronizasyon bu aşamada uygulanır.
-
05
Test ve mağaza hazırlığı
Cihaz matrisi üzerinde test yapılır; saha veya bayi tarafında gerçek kullanıcıyla kapalı test açılır. Mağaza dosyaları ve gizlilik beyanları yayından iki hafta önce hazır olur.
-
06
Yayın, bakım ve sürüm yönetimi
Yayın kademeli açılır, çökme ve performans verisi ilk günden izlenir. İşletim sistemi sürümleri ve mağaza şartları değiştikçe sürüm planı güncellenir; kararı siz verirsiniz.
App Store ve Play Store yayın süreci adım adım
Yayın yedi adımda ilerler: hesap açılışı, uygulama kaydı, gizlilik beyanları, listeleme dosyası, kapalı test, inceleme gönderimi ve kademeli yayın. Mağaza hesapları her aşamada müşterinin tüzel kişiliği adına kalır; biz hesaba yalnızca yetkilendirilmiş geliştirici olarak ekleniriz.
- Hesap açılışı. Apple Developer Program ve Google Play Console üyelikleri sizin tüzel kişiliğiniz adına açılır. Apple, kuruluş kaydında D-U-N-S numarası ister; Google Play kuruluş hesaplarında kimlik doğrulaması yapar. Bu adım bazen bir haftadan uzun sürer, bu yüzden projenin ilk aylarında başlatılır.
- Uygulama kaydı ve paket kimliği. Uygulama adı, paket kimliği ve imzalama sertifikaları oluşturulur. Sertifikalar müşteri hesabında üretilir; ajans hesabında saklanmaz.
- Gizlilik ve veri güvenliği beyanları. Hangi verinin hangi amaçla toplandığı iki mağazanın kendi formatında beyan edilir ve KVKK aydınlatma metniniz ile birebir tutarlı tutulur. Beyan ile uygulamanın gerçek davranışı ayrıştığında ret gelir.
- Listeleme dosyası. Başlık, alt başlık, açıklama, arama terimleri, ekran görselleri ve tanıtım metni hazırlanır; çok dilli yayın yapılacaksa her dil için ayrı ayrı.
- Kapalı test. TestFlight ve Play kapalı test kanalları üzerinden gerçek kullanıcıya dağıtılır. Bayi ve saha senaryolarında bu adım, gerçek şebeke koşullarını görmek için atlanmaz.
- İnceleme gönderimi. En sık ret sebepleri: inceleme ekibine demo hesabı verilmemesi, izin gerekçelerinin açıklanmaması ve gizlilik beyanı ile davranışın uyuşmaması. Bu üç maddeyi gönderimden önce kontrol listesiyle geçiyoruz.
- Kademeli yayın. Sürüm önce kullanıcıların bir bölümüne açılır; çökme oranı ve hata kayıtları izlenir, sorun görülmezse yayın genişletilir.
%90
Apple, App Store'a gönderilen uygulamaların ortalama yüzde 90'ının 24 saatten kısa sürede incelendiğini bildiriyor. Takvimi belirleyen inceleme değil, öncesindeki hesap ve beyan hazırlığıdır.
Kaynak: Apple Developer — App Review (yeni sekmede açılır) · Erişim: 2026-07-29
Uygulama hangi ölçütlerle kabul edilir?
Yedi ölçütle: çökmesiz oturum oranı, uygulama yanıt vermeme oranı, soğuk açılış süresi, indirme boyutu, mağaza inceleme ret sayısı, erişilebilirlik uyumu ve veri beyanı tamlığı. Her ölçütün eşiği ve ölçüm aracı sözleşmede yazılıdır; teslim raporuna aracın çıktısı eklenir.
| Kriter | Eşik | Ölçüm aracı |
|---|---|---|
| Çökmesiz oturum oranı | ≥ %99,5 | Çökme raporlama paneli · Play Console Android vitals |
| Uygulama yanıt vermeme (ANR) oranı | ≤ %0,3 | Play Console Android vitals |
| Soğuk açılış süresi (orta seviye Android cihaz) | < 2,0 sn | Play Console Android vitals · cihaz üstü ölçüm |
| İndirme boyutu | ≤ 40 MB | App Store Connect · Play Console |
| Mağaza inceleme ret sayısı (ilk yayın) | ≤ 2 | Mağaza inceleme kaydı |
| Erişilebilirlik: kontrast ve dokunma hedefi | WCAG 2.1 AA | Accessibility Scanner · Accessibility Inspector |
| Veri güvenliği beyanı ve izin gerekçeleri | Eksiksiz | Play veri güvenliği formu · Apple gizlilik etiketleri |
5 sn
Google Play Console, soğuk açılışı 5 saniye ve üzerinde olan oturumları “aşırı” olarak işaretliyor. Bu, kabul edilebilir sınırın tavanıdır; biz kabul eşiğini 2 saniyenin altına çekiyoruz.
Kaynak: Android Developers — Uygulama başlatma süresi (yeni sekmede açılır) · Erişim: 2026-07-29
Bu eşikler, kurumsal web tarafındaki Core Web Vitals kabul kriterlerinin mobil karşılığıdır: ölçülemeyen bir hedef sözleşmeye yazılmaz.
Hangi sektörlerde mobil uygulama karşılığını buluyor?
Tekrarlayan günlük kullanımın olduğu her yapıda: bayi ağları, üretim tesisleri, mağaza zincirleri, ihracatçı sanayi ve çok şirketli holdingler. Ortak nokta uygulamanın tanıtım değil, günlük bir işi taşıyor olmasıdır. Aşağıdaki beş sayfada her segmentin kendi senaryosu ayrıntılı yazılıdır.
- 01 Üretim ve Fabrika Saha ve depo verisi kâğıttan uygulamaya taşındığında üretim adımı, sayım ve sevkiyat kaydı aynı gün sisteme düşer.
- 02 Mağaza Zincirleri ve Perakende Personel için stok sorgulama ve sipariş, müşteri için sadakat ve mağaza bulucu; üçü de aynı mağaza kaydını okur.
- 03 Bayilik ve Franchise Ağı Sipariş, fiyat listesi ve kampanya duyurusu tek uygulamada toplanır; merkez hangi bayinin neyi göreceğini yönetir.
- 04 İhracatçı Sanayi Çok dilli ürün kataloğu ve teknik doküman, fuarda ve saha ziyaretinde bağlantı olmadan da açılabilir olur.
- 05 Kurumsal Holding Farklı iştiraklerin duyuru, prosedür ve eğitim akışları tek uygulamada, yetki ayrımı korunarak yönetilir.
Mobil uygulama hangi hizmetlerle birlikte alınır?
Uygulama tek başına da yapılır; ancak içeriğini bir yerden okuması gerekir. En sık birlikte alındığı dört hizmet şunlardır: kurumsal web sitesi, bayi ve şube ağı yönetimi, kurumsal kimlik, e-ticaret. Ortak gerekçe aynı: veri ve tasarım kararlarının tek yerde tutulması.
- 01 Kurumsal Web Sitesi Uygulamanın okuduğu ürün, doküman ve duyuru içeriği sitede yönetiliyorsa iki kanal aynı veriyi gösterir.
- 02 Bayi ve Şube Ağı Yönetimi Bayi uygulaması ile lokasyon sayfaları aynı kayıttan beslendiğinde adres, yetki ve iletişim bilgisi tek yerde güncellenir.
- 03 Kurumsal Kimlik ve Markalaşma Renk, tipografi ve boşluk kararları token dosyası olarak teslim edildiğinde uygulama ile site aynı görsel sistemi paylaşır.
- 04 E-ticaret B2B sipariş akışı hem bayi portalında hem uygulamada çalışacaksa fiyat, cari ve stok mantığı tek yerde kurulur.
Kurumsal mobil uygulama hakkında sıkça sorulanlar
Native mi cross-platform mı seçmeliyim?
Karar dört ölçütle verilir: cihaz API ihtiyacı, güncelleme sıklığı, uygulamayı kimin sürdüreceği, bütçe ve takvim. Yoğun sensör kullanımı, çevrimdışı senkronizasyon ve arka plan işleri varsa native; form, liste, katalog ve sipariş akışı ağırlıklıysa tek kod tabanı yeterlidir. Kararı gerekçesiyle yazılı veririz; ölçütler değişirse karar da yeniden yazılır.
App Store ve Play Store süreci ne kadar sürer?
İnceleme genellikle bir iş günü içinde sonuçlanır; Apple, gönderimlerin yüzde 90'ını 24 saatten kısa sürede incelediğini bildiriyor. Asıl süre incelemede değil hazırlıkta geçer: hesap açılışı ve kimlik doğrulama, gizlilik beyanları, listeleme metinleri ve ekran görselleri. Bu hazırlığı yayından iki hafta önce tamamlıyoruz. İlk gönderimde ret alınması olağandır, gerekçe giderilip yeniden gönderilir.
Mağaza hesapları kimin adına açılır?
Mağaza hesapları müşterinin tüzel kişiliği adına açılır. Apple Developer Program kaydında kuruluşlardan D-U-N-S numarası istenir, Google Play Console kuruluş hesaplarında kimlik doğrulaması yapılır. Biz hesaba yetkilendirilmiş geliştirici olarak ekleniriz. Uygulama, imzalama sertifikaları ve mağaza varlıkları hiçbir aşamada ajans hesabında tutulmaz.
Uygulama bakım ve sürüm maliyeti nasıl hesaplanır?
Bakım üç kalemden oluşur: platform zorunlulukları, hata giderme ve yeni işlev geliştirme. Platform zorunlulukları uygulamayı yayında tutmak için gereklidir ve sabit bir aylık ritimle planlanır; yıllık işletim sistemi sürümleri, hedef API düzeyi ve gizlilik beyanı güncellemeleri bu kalemdedir. Yeni işlev geliştirme talep geldikçe ayrı planlanır. Mağaza üyelik ücretleri doğrudan müşterinin hesabından ödenir.
Mevcut ERP veya stok sistemimize bağlanabilir mi?
Evet, ancak bağlantı doğrudan veritabanına değil tanımlı bir API üzerinden kurulur. ERP tarafında hazır bir servis yoksa uygulama ile ERP arasına bir ara katman yazılır. Stok, fiyat, cari ve sipariş verisi ERP'de kalır; uygulama yalnızca okur ve yazar. Hangi alanın hangi yöne aktığı API sözleşmesinde satır satır yazılıdır.
Uygulama olmadan mobil web yeterli olur mu?
Çoğu kurumsal ihtiyaç için yeterlidir. Uygulama şu üç koşuldan en az biri varsa gerekçelidir: tekrarlayan günlük kullanım, cihaz yeteneği zorunluluğu ya da kimliği doğrulanmış kapalı kullanıcı grubu. Yalnızca tanıtım ve katalog amacıyla yapılan uygulama, indirme ve güncelleme yükü nedeniyle iyi kurulmuş bir mobil siteden daha az verim verir. Bunu projeye başlamadan söyleriz.
Mevcut dijital varlığınızın ölçülmüş durumunu 5 iş günü içinde görün.
Denetim ücretsizdir ve karşılığında bir çalışma zorunluluğu doğurmaz. Raporda beş eksenin bulguları madde madde yer alır: AEO cevaplanabilirliği, yapay zekâ tarayıcı erişimi, Core Web Vitals laboratuvar ölçümü, yapılandırılmış veri geçerliliği ve otomatik erişilebilirlik taraması.
Kurumsal ölçekte, çok lokasyonlu veya çok dilli yapılarla çalışıyoruz. Tek seferlik küçük işler kapsamımız dışında; bu durumda daha küçük ölçekli stüdyolara yönlendiriyoruz.