# Mobil uygulama yaptırma — iOS ve Android, tek kod tabanı

> Tek kod tabanından her iki platforma yayınlanan mobil uygulamalar. Mağaza yayın süreçleri, sürüm yönetimi ve güncelleme akışı dâhil.

Kaynak: https://flatinium.com/mobil-uygulama-yaptirma · Flatinium, Ankara

## Kapsam

- **Tek kod tabanı** — iOS ve Android için ayrı ekip yerine ortak geliştirme. Geliştirme maliyeti ve sonraki her güncellemenin yükü belirgin biçimde düşüyor.
- **Mağaza süreci** — App Store ve Google Play yayın gereklilikleri, gizlilik beyanları ve red durumunda revizyon yönetimi.
- **Arka uç** — Uygulamanın konuştuğu servisler, bildirim altyapısı ve yönetim paneli birlikte kurulur.

## Uygulama mı, mobil site mi?

Bu soruyu dürüst cevaplamak bize her zaman iş kazandırmıyor ama doğru olan bu. Karar tek soruya bakıyor: kullanıcı bunu haftada kaç kez açacak?

Mobil uygulama, kullanıcının **tekrar tekrar** kullandığı işlerde anlamlı: sipariş, rezervasyon, sadakat, saha ekibi. Yılda birkaç kez ziyaret edilen bir hizmet için mobil uyumlu web sitesi hem yeterli hem çok daha ucuz; tek seferlik veya seyrek kullanımda uygulama indirtmek gereksiz bir engel oluyor.

Bunu baştan söylüyoruz çünkü yapılan uygulamaların önemli bir kısmı indirilip bir kez açılıyor ve siliniyor.

| Durum | Daha uygun olan |
|---|---|
| Kullanıcı haftada birkaç kez ya da her gün giriyor | Uygulama |
| Bildirim göndermek işin merkezinde | Uygulama |
| Cihaz donanımı gerekiyor (kamera, konum, sensör) | Uygulama |
| Çevrimdışı çalışması gerekiyor | Uygulama |
| Yılda birkaç kez kullanılıyor | Mobil site |
| Amaç yeni müşteriye ulaşmak | Mobil site |
| Bütçe sınırlı, öncelik görünürlük | Önce web, sonra uygulama |

Yeni müşteri satırına dikkat edin: yeni müşteri kazanmak için uygulama yaptırmak yaygın bir hata. Sizi tanımayan biri uygulama indirmiyor. Uygulama, mevcut müşteriyle ilişkiyi derinleştiren bir araç.

## Tek kod tabanı ne kazandırıyor?

iOS ve Android için ayrı ekip yerine ortak geliştirme yapıyoruz; tek kod tabanı çoğu proje için doğru tercih.

**Kazandırdıkları.** Geliştirme süresi ve maliyeti belirgin şekilde düşüyor. Sonraki her güncellemenin yükü de azalıyor, çünkü her değişiklik iki kez değil bir kez yazılıyor ve iki platforma birden yansıyor. Bakım tek yerden yürüyor.

**Sınırı.** Oyun gibi yoğun grafik işlemi veya platforma çok özgü donanım kullanımı gerektiren uygulamalarda yerel geliştirme hâlâ üstün. Standart iş uygulamalarında bu sınıra genellikle hiç yaklaşılmıyor ve performans farkı hissedilmiyor.

Hangi yaklaşımın uygun olduğunu proje analizinde belirliyoruz ve gerekçesini yazılı veriyoruz.

## Mağaza süreci

Yayın, geliştirmenin bitmesiyle bitmiyor; geliştirmeden bağımsız bir süreç ve baştan planlanması gerekiyor. Kapsama dâhil olanlar:

- App Store ve Google Play hesap kurulumu
- Gizlilik beyanları ve veri toplama bildirimleri
- Ekran görüntüleri, açıklama metinleri, anahtar kelime alanı
- İnceleme sürecinin takibi ve red durumunda revizyon

**Hesaplar.** Geliştirici hesapları işletmeniz adına açılıyor ve bu pazarlık konusu değil. Uygulama mülkiyetinin sizde kalması için zorunlu; ajans hesabından yayınlanan bir uygulama ayrılık durumunda sorun çıkarıyor.

**İnceleme.** Her iki mağaza da uygulamayı inceleme sürecinden geçiriyor ve bu süreç gün alabiliyor. İlk yayında red alınması olağandışı değil; genellikle eksik bilgi veya politika uyumsuzluğu kaynaklı ve gerekçeye göre düzeltilerek yeniden gönderiliyor.

**Gizlilik bildirimi.** Hangi verinin toplandığı ve nasıl kullanıldığı açıkça beyan ediliyor. Yanlış beyan, uygulamanın kaldırılmasına yol açabiliyor.

**Güncelleme döngüsü.** Her güncelleme yeniden incelemeden geçiyor. Bu, sürüm planlamasını etkiliyor.

> **Dikkat** — Mağaza hesaplarının ajans adına açılması en sık karşılaştığımız sorun. Uygulamanın devri mümkün ama zahmetli; baştan doğru açmak birkaç dakikalık iş, sonradan düzeltmek haftalar alabiliyor.

## Arka uç ve veri

Uygulamanın görünen kısmı buzdağının ucu; uygulama tek başına bir kabuk, asıl iş arka tarafta dönüyor.

Kurulan yapıda bulunanlar: uygulamanın konuştuğu servisler, kullanıcı yönetimi ve kimlik doğrulama, veri saklama ve yedekleme, bildirim altyapısı, yönetim paneli, sürüm yönetimi ve hata izleme.

Son madde özellikle değerli. Kullanıcının karşılaştığı hataları görmeden uygulama iyileştirilemiyor; kullanıcıların büyük kısmı hata bildirmek yerine uygulamayı siliyor.

Aynı arka uç genellikle web sitesini de besleyebiliyor — bu, iki ayrı sistem yönetmekten hem ucuz hem güvenli. Süreç ve fiyat mantığı [özel yazılım geliştirme](https://flatinium.com/ozel-yazilim-gelistirme) sayfasındakiyle aynı.

## Yayın sonrası takip

Uygulama projelerinde en sık yapılan hata, yayını bitiş çizgisi sanmak. Yayından sonraki ilk üç ay kritik ve takip edilmesi gerekenler şunlar.

**İndirme sayısı.** Kaç kişi indirdi — gurur okşayan ama tek başına anlamsız sayı.

**İlk açılış tamamlama.** Kaç kişi kayıt veya giriş adımını geçti. Buradaki kayıp genellikle en büyüğü.

**Bir hafta sonra kullanım.** En önemli sayı bu: uygulamanın gerçekten işe yarayıp yaramadığını söylüyor.

**Ekran bazlı bırakma.** Hangi ekranda vazgeçiliyor. Sorunun yerini bu gösteriyor.

Bu dördü ölçülmüyorsa, ikinci sürüm tahminle planlanıyor demektir.

> **Örnek senaryo** — Bir işletme uygulaması düşünün: indirme sayısı beklenenin üstünde ama bir hafta sonra kullanmaya devam eden çok az. Ekran bazlı takip, kullanıcıların büyük kısmının kayıt ekranında bıraktığını gösterirse sebep çoğu zaman bellidir; kayıt için istenen bilgiler fazladır. Zorunlu alanları üçe indirmek, uygulamada başka hiçbir şeyi değiştirmeden devam oranını yükseltmenin en kısa yoludur.

## Bütçe nasıl planlanmalı?

Mobil uygulama projelerinde en sık yapılan hata, bütçenin tamamını geliştirmeye ayırmak.

Gerçek maliyet üç kalemden oluşuyor:

**Geliştirme.** Tek seferlik ve en görünür kalem.

**Yayın ve bakım.** Geliştirici hesapları yıllık ücretli, işletim sistemi güncellemeleri düzenli uyum çalışması gerektiriyor. Yılda en az bir kez güncelleme yapılmayan uygulamalar zamanla çalışmaz hâle geliyor.

**Kullanıcı kazanımı.** Uygulama yayınlandığında kendiliğinden indirilmiyor. Mevcut müşterilerinize duyurmak, kanallarınızda tanıtmak ve indirmeye teşvik etmek ayrı bir iş.

Üçüncü kalem hiç hesaba katılmadığında, teknik olarak başarılı ama kimsenin bilmediği bir uygulama ortaya çıkıyor.

## İlk sürüm ne kadar kapsamlı olmalı?

Mümkün olduğunca dar.

Uygulamanın çözdüğü tek bir asıl problem vardır. İlk sürüm onu çözsün, gerisi beklesin.

Sebebi şu: kullanıcıların uygulamayı nasıl kullanacağını teslim etmeden bilemiyorsunuz. Geniş bir ilk sürüm, çoğu hiç kullanılmayacak özelliğe emek harcamak demek.

Dar bir ilk sürüm çıkardıktan sonra hangi ekranın kullanıldığı, nerede bırakıldığı ve neyin eksik olduğu ölçülebiliyor. İkinci sürüm artık tahminle değil veriyle planlanıyor.

> **İpucu** — İlk sürümde en değerli özellik genellikle bildirim değil, giriş kolaylığı. Kayıt ekranında istenen her ek alan doğrudan kullanıcı kaybı üretiyor.

## Web sitesiyle ilişkisi

Uygulama, web sitesinin yerine geçmiyor.

Arama motorlarında görünen şey siteniz; uygulama mağaza aramalarında görünüyor ve bu iki dünya ayrı. Yeni müşteri arama motorundan geliyor, uygulama mevcut müşteriyi elde tutuyor.

Bu yüzden uygulama projelerinde site tarafını da gözden geçiriyoruz. Uygulamayı tanıtan bir sayfa, indirme bağlantıları ve sık sorulan sorular sitede bulunmalı.

Site tarafındaki kapsam [web sitesi geliştirme](https://flatinium.com/web-sitesi-gelistirme) sayfasında yazılı.

## Bakım neden zorunlu

Mobil uygulamalar işletim sistemi güncellemeleriyle uyumsuz hâle gelebiliyor. Yılda en az bir kez güncellenmeyen uygulamalar zamanla çalışmaz duruma düşüyor ve mağazadan kaldırılabiliyor.

Bakım kapsamında uyum güncellemeleri, hata düzeltmeleri ve mağaza gerekliliklerinin takibi yürüyor. Bakım almadan teslim de yapıyoruz; bu durumda sorumluluk sizde oluyor ve sözleşmede yazılıyor.

## Teslimde neler devrediliyor

Kaynak kodun tamamı, mağaza hesapları (sizin adınıza açılmış hâlde), arka uç erişimleri, teknik doküman ve kısa bir kullanım kılavuzu.

Uygulama size ait. Bakımı biz yürütebiliriz, başka bir ekip de devralabilir. Devir sırasında sorun çıkmaması için standart teknolojiler tercih ediliyor.

## Nereden başlıyoruz?

İlk görüşmede sorduğumuz soru şu: kullanıcı bu uygulamayı haftada kaç kez açacak?

Cevap düşükse uygulama yerine mobil site öneriyoruz ve bunun bize bir maliyeti var. Yıllık bakım ve mağaza yükü, seyrek kullanılan bir uygulamada karşılığını vermiyor.

Cevap yüksekse analiz aşamasına geçiyoruz: hangi işlev ilk sürümde olacak, arka uçta ne gerekiyor, mağaza hesapları kimin adına açılacak.

## Bu konuyla ilgili

- [yazılım geliştirme hizmetleri](https://flatinium.com/yazilim-gelistirme) — Kapsamın tamamı.
- [fiyatlandırma yaklaşımımız](https://flatinium.com/web-sitesi-yaptirma-fiyatlari) — Proje bütçesi nasıl kuruluyor.

## Sık sorulan sorular

### Web sitem varken uygulamaya ihtiyacım var mı?

Çoğu işletme için hayır. Uygulama, tekrar eden kullanım olan işlerde (sipariş, rezervasyon, sadakat) anlamlıdır. Yılda birkaç kez ziyaret edilen bir hizmet için mobil uyumlu web sitesi hem yeterli hem çok daha ucuzdur. Bunu baştan söylemeyi tercih ediyoruz.

### Uygulama mağazalarda ne kadar sürede yayınlanır?

Geliştirme tamamlandıktan sonra inceleme süreci genellikle birkaç gün sürer. Red alınması olağandışı değildir; gerekçeye göre revizyon yapılıp yeniden gönderilir.