Mobil Uygulama Nasıl Yapılır? Fikirden Yayına Süreç ve Proje Kapsamı

Bir işletme için mobil uygulama nasıl yapılır sorusunun cevabı kodlamadan önce verilen kararlarla başlar: uygulamanın hangi sorunu çözeceği, kimin kullanacağı, ilk sürümde hangi özelliklerin olacağı ve yayından sonra kimin bakacağı. Ardından tasarım, geliştirme, test ve mağaza yayını gelir. Aşağıda fikirden yayına sekiz adımı, her adımda sizin hazırlamanız gereken bilgi ve çıktılarla birlikte bulacaksınız.

Mobil uygulama nasıl yapılır: geliştirme aşamalarına genel bakış

Aşama	Cevaplanan soru	Sizden beklenen	Çıktı
1. Fikir ve hedef kullanıcı	Neden uygulama, kim kullanacak?	İş hedefi, kullanıcı bilgisi	Kısa proje özeti
2. Kapsam ve özellik listesi	İlk sürümde ne olacak?	Öncelik kararları	Özellik listesi, şartname
3. Teknoloji seçimi	Hangi yöntemle geliştirilecek?	Bütçe ve bakım tercihi	Mimari karar
4. Tasarım ve prototip	Ekranlar nasıl işleyecek?	Geri bildirim ve onay	Akışlar, tıklanabilir prototip
5. Geliştirme ve arka uç	Veri nereden gelip nereye gidecek?	Entegrasyon bilgileri, erişimler	Çalışan ara sürümler
6. Test	Doğru ve sorunsuz çalışıyor mu?	Kabul testleri	Test kayıtları, düzeltmeler
7. Mağaza yayını	Nasıl ve kimin adına yayımlanacak?	Geliştirici hesapları, mağaza metinleri	Mağazada yayında uygulama
8. Yayın sonrası	Nasıl güncel ve güvenli kalacak?	Bakım kararı	Güncellemeler, raporlar

1. Fikir ve hedef kullanıcı

Mobil uygulama yapmak isteyen bir işletmenin ilk sorması gereken soru, bu işin neden bir uygulama gerektirdiğidir. Kullanıcı ürünü haftada birkaç kez mi kullanacak, yoksa yılda bir mi? Bildirim, kamera, konum ya da çevrimdışı çalışma gibi cihaz özelliklerine ihtiyaç var mı? Bu soruların cevabı çoğunlukla hayırsa mobil uyumlu bir web uygulaması daha doğru bir başlangıç olabilir.

Bu aşamada netleşmesi gerekenler:

• Uygulamanın çözdüğü sorunun tek cümlelik tanımı.
• Birincil kullanıcı grubu: müşteri, bayi, saha personeli ya da çalışan.
• Başarının nasıl ölçüleceği: tekrar sipariş, aktif kullanım, saha raporlarının tamamlanma süresi gibi.
• Uygulamanın mevcut süreçlere ve sistemlere nasıl bağlanacağı.

Şirket içinden bir proje sorumlusu belirlemek de ilk adımın parçasıdır. Tasarım onayları, test geri bildirimleri ve kapsam kararları tek bir kişide toplanmazsa proje farklı birimlerin çelişen talepleri arasında yavaşlar. Proje sorumlusunun teknik bilgisi olması şart değildir; işi, kullanıcıyı ve önceliği bilmesi yeterlidir.

2. Proje kapsamı ve özellik listesi

Özellik listesi, projenin maliyetini ve süresini en çok etkileyen belgedir. İlk sürümde her şeyi yapmak yerine uygulamanın temel işini gören özellikleri ayırmak ve geri kalanını sonraki sürümlere bırakmak riski azaltır. Pratik bir yöntem, her özelliği üç gruba ayırmaktır:

• Zorunlu: Uygulama bu özellik olmadan işini göremez; giriş, sipariş oluşturma, ödeme gibi.
• Önemli: Değer katar ama ilk sürüm onsuz yayına çıkabilir; favoriler, gelişmiş filtreler gibi.
• Sonraya: Kullanıcı geri bildirimiyle değerlendirilecek fikirler.

Kullanıcı rollerini (müşteri, yönetici, bayi), ekran listesini ve iş kurallarını yazılı hale getirmek, farklı firmalardan karşılaştırılabilir teklif almanın da ön koşuludur. Bu belgenin nasıl hazırlanacağını teknik şartname nasıl hazırlanır yazısında adım adım anlattık. Birden fazla firmadan resmî teklif toplayacaksanız RFP nedir yazısı süreci planlamanıza yardım eder.

Kapsamda sık unutulan bir parça da yönetim panelidir. İçerikleri, siparişleri, kullanıcıları ve bildirimleri kimin, nereden yöneteceği baştan yazılmazsa proje ortasında yeni bir iş kalemi olarak ortaya çıkar.

3. Teknoloji seçimi

Mobil uygulamalar genel olarak üç yöntemle geliştirilir. Doğru seçim uygulamanın ihtiyaçlarına, bütçeye ve uzun vadeli bakım planına göre değişir.

Yöntem	Nasıl çalışır	Güçlü yanı	Dikkat edilecek nokta
Native	iOS için Swift, Android için Kotlin ile ayrı ayrı geliştirilir	Cihaz özelliklerine tam erişim, platforma özgü deneyim	İki ayrı kod tabanı, iki ayrı bakım
Cross-platform	Flutter ya da React Native gibi araçlarla tek kod tabanından iki platform	Ortak kod, tek ekip	Bazı cihaz özellikleri için ek native geliştirme gerekebilir
Web tabanlı (PWA)	Tarayıcıda çalışan, ana ekrana eklenebilen web uygulaması	Mağaza gerektirmez, tek sürüm	Cihaz özelliklerine ve bildirimlere erişim sınırlı olabilir

Karar verirken üç soru yol gösterir: Uygulama yoğun grafik, kamera ya da sensör kullanıyor mu? Aynı ekip iki platformu yıllarca sürdürebilecek mi? Uygulamanın mağazada bulunması şart mı? Bu soruların cevabı teklifte gerekçesiyle yazılmalıdır.

4. Tasarım ve prototip

Tasarım, ekranların görünüşünden önce kullanıcının bir işi hangi adımlarla tamamlayacağını belirlemekle başlar. Tipik sıra şöyledir:

1. Kullanıcı akışları: Giriş, sipariş, ödeme gibi ana işler adım adım çizilir.
2. Tel çerçeveler (wireframe): Ekranların iskeleti, renk ve görsel olmadan hazırlanır.
3. Arayüz tasarımı: Renk, tipografi, bileşenler ve marka dili uygulanır; iOS ve Android'in kendi tasarım kuralları dikkate alınır.
4. Tıklanabilir prototip: Ekranlar birbirine bağlanır ve gerçek kullanıcılarla denenir.

Prototip aşamasında yapılan bir değişiklik, kod yazıldıktan sonra yapılandan çok daha az emek ister. Bu yüzden onay vermeden önce prototipi sahadaki gerçek kullanıcılarla denemek, projenin en verimli adımlarından biridir.

5. Geliştirme ve arka uç

Kullanıcının gördüğü uygulama işin yalnız bir kısmıdır. Çoğu işletme uygulamasının arkasında verileri tutan bir sunucu, uygulamayla bu sunucu arasında veri taşıyan bir API ve içerikleri ya da siparişleri yöneteceğiniz bir panel bulunur. API'nin ne olduğunu ve projede neden bu kadar belirleyici olduğunu API nedir yazısında anlattık.

Bu aşamada netleştirilecek konular:

• Entegrasyonlar: ERP, CRM, muhasebe, ödeme ve kargo sistemleriyle bağlantılar. Mevcut sistemlerin API'si olup olmadığı erken öğrenilmelidir.
• Bildirim altyapısı: Anlık bildirimlerin hangi olaylarda, hangi kullanıcıya gideceği.
• Güvenlik ve kişisel veri: Kimlik doğrulama, verinin şifrelenmesi, KVKK kapsamındaki aydınlatma yükümlülüğü ve gerektiği durumlarda açık rıza.
• Ortamlar ve kaynak kod: Test ve canlı ortamların ayrılması, kaynak kodun nerede tutulacağı ve kimin erişeceği.

Geliştirme genellikle kısa döngülerle ilerler. Her döngü sonunda çalışan bir ara sürüm görmek sorunları erken yakalamanızı sağlar; düzenli demo toplantıları isteyin ve test sürümünü kendi telefonunuzda kullanın.

6. Test

Test, uygulamanın farklı cihazlarda, işletim sistemi sürümlerinde ve bağlantı koşullarında doğru çalıştığını doğrular. Bir test planında şu başlıklar bulunmalıdır:

• Fonksiyon testi: Her özellik şartnamede yazıldığı gibi çalışıyor mu?
• Cihaz ve sürüm testi: Farklı ekran boyutları, eski ve yeni işletim sistemi sürümleri.
• Bağlantı testi: Zayıf ağda ya da bağlantı koptuğunda uygulama ne yapıyor?
• Performans ve pil tüketimi: Uygulama cihazı yavaşlatıyor ya da hızla pil tüketiyor mu?
• Kabul testi: Sizin ekibinizin uygulamayı gerçek senaryolarla denemesi.

Apple'ın TestFlight hizmeti ve Google Play'in test kanalları, uygulamayı mağazada herkese açmadan sınırlı bir kullanıcı grubuna dağıtmanıza izin verir. Bu beta döneminde gelen geri bildirimler, yayın öncesi son düzeltmeleri belirler.

7. Mağaza yayını: uygulama yayınlama adımları

Uygulama yayınlama iOS için App Store, Android için çoğunlukla Google Play üzerinden yapılır. İki mağazada da uygulama ve sonraki güncellemeler yayından önce incelemeden geçer.

1. Geliştirici hesaplarını açın. Apple Developer Program üyeliği ve Google Play Console geliştirici hesabı gerekir. Uygulamanın mağazada şirketinizin adıyla görünmesi için hesapları kurum adına açın; kurum hesabında şirket doğrulaması yapılır ve iki platform da bunun için D-U-N-S numarası ister. Google Play, kişisel hesaplarla açılan yeni hesaplarda yayından önce ek test koşulları da arayabilir.
2. Mağaza sayfasını hazırlayın. Uygulama adı, açıklama, ekran görüntüleri, kategori, yaş derecelendirmesi ve destek adresi.
3. Gizlilik bilgilerini doldurun. Gizlilik politikası bağlantısı gerekir. Apple'da uygulama gizlilik bilgileri, Google Play'de veri güvenliği bölümü, uygulamanın hangi verileri topladığını beyan etmenizi ister.
4. İnceleme için test hesabı verin. Giriş gerektiren uygulamalarda inceleme ekibinin kullanabileceği bir hesap sağlanmazsa uygulama reddedilebilir.
5. Mağaza kurallarını kontrol edin. Uygulama içi satın alma, hesabın uygulama içinden silinebilmesi ve kullanıcı içeriğinin denetimi gibi konularda kurallar ayrıntılıdır. Güncel metinler için App Store inceleme yönergelerine ve Google Play Console sayfalarına bakın.
6. Yayın tarihine pay bırakın. İnceleme süresi değişkendir; lansman ya da kampanya tarihini buna göre belirleyin.

Hesabın kimin adına açılacağı küçük bir ayrıntı gibi görünse de önemli bir karardır. Uygulama geliştirici firmanın hesabında yayımlanırsa ileride kendi hesabınıza taşımak ek iş çıkarır; bu konuyu sözleşmeden önce konuşun.

8. Yayın sonrası

Uygulama yayına çıktığında iş bitmez. Apple ve Google düzenli olarak yeni işletim sistemi sürümleri çıkarır, mağaza kuralları değişir, kullanıcılar hata bildirir. Yayın sonrası planda şunlar bulunmalıdır:

• Çökme ve hata raporlarının izlenmesi.
• Kullanım analitiği: Hangi ekranlar kullanılıyor, kullanıcılar hangi adımda uygulamayı bırakıyor?
• İşletim sistemi güncellemelerine uyum ve güvenlik güncellemeleri.
• Sunucu, veritabanı ve bildirim altyapısının barındırılması ve bakımı.
• Kullanıcı geri bildirimine dayanan yeni sürüm planı.

Bakımın kapsamını ve sorumluluğunu proje başında sözleşmeye yazmak, yayından sonra kimin neye bakacağı konusundaki belirsizliği ortadan kaldırır.

Mobil uygulama projelerinde sık yapılan hatalar

Aşağıdaki hatalar projenin teknik zorluğundan değil, erken verilmeyen kararlardan kaynaklanır:

• Kapsamı yazmadan fiyat istemek. Özellik listesi olmadan alınan teklifler birbirine benzemez ve karşılaştırılamaz.
• İlk sürüme her şeyi sığdırmak. Yayın tarihi uzar, kullanıcı geri bildirimi gecikir ve bütçe gereksiz özelliklere harcanır.
• Arka ucu ve yönetim panelini unutmak. Uygulamanın ekranları hazır olduğunda verinin nereden geleceği sorusu projeyi durdurur.
• Prototipi atlamak. Akış sorunları ancak kod yazıldıktan sonra fark edilir ve düzeltmesi pahalıya mal olur.
• Gerçek cihazda test etmemek. Emülatörde sorunsuz çalışan uygulama, eski bir telefonda ya da zayıf bağlantıda farklı davranabilir.
• Mağaza hesaplarını son haftaya bırakmak. Kurum doğrulaması ve inceleme süreci lansman tarihini kaydırabilir.
• Yayın sonrasını planlamamak. İşletim sistemi güncellemelerine uyum sağlanmayan bir uygulama zamanla hata vermeye başlar.

Teklif almadan önce netleştirilecek sorular

Aşağıdaki soruların cevabı tekliflerde yazılı olarak yer almalıdır:

• Kaynak kod ve lisans kimde olacak, sözleşmede nasıl tanımlanacak?
• Uygulama hangi geliştirici hesabında yayımlanacak?
• Arka uç, API ve yönetim paneli kapsamda mı?
• Test hangi cihaz ve sürümlerde yapılacak, kabul ölçütleri neler?
• Mağaza reddi durumunda gereken düzeltmeler kapsamda mı?
• Yayın sonrası destek ve güncellemeler nasıl ücretlendirilecek?
• Kapsam değişiklikleri nasıl talep edilip fiyatlanacak?

Granobra'da nasıl çalışıyoruz

Ana işimiz özel yazılım, CRM ve dijital ürünler; mobil uygulama da bu ailenin parçası. Projeye başlarken iş süreçlerinizi ve kullanıcı akışlarını birlikte haritalıyor, kapsamı yazılı hale getiriyoruz. Kaynak kod ve lisans konusu teklifte açıklanır, sözleşmede belirlenir. Çalışma biçimimizi mobil uygulama geliştirme sayfamızda, genel proje adımlarımızı proje aşamaları sayfasında bulabilirsiniz.

Sık sorulan sorular

Mobil uygulama yapmak ne kadar sürer?

Tek bir süre vermek yanıltıcı olur. Süreyi özellik sayısı, entegrasyonların karmaşıklığı, tasarım onay süreci ve mağaza incelemesi belirler. Kapsam netleştikten sonra aşama aşama bir takvim çıkarmak mümkündür; bu takvimi teklifin parçası olarak isteyin.

Kodlama bilmeden uygulama yapılabilir mi?

Kodsuz (no-code) araçlarla basit uygulamalar hazırlanabilir. Ancak özel iş kuralları, mevcut sistemlerle entegrasyon ve büyüme ihtiyacı ortaya çıktığında bu araçların sınırlarına ulaşılabilir. Bu tür ihtiyaçları olan işletme uygulamalarında özel geliştirme daha sürdürülebilir bir yoldur.

Uygulama yayınlama için hangi hesaplar gerekir?

iOS için Apple Developer Program üyeliği, Android için Google Play Console geliştirici hesabı gerekir. Apple yıllık üyelik ücreti, Google Play tek seferlik kayıt ücreti alır; güncel tutarları iki platformun kendi sayfalarından kontrol edin. Kurum hesabında şirket bilgileri doğrulandığı için bu adımı projenin başında başlatın.

Mobil uygulama yapmak için hangi programlama dili kullanılır?

iOS uygulamaları çoğunlukla Apple'ın Xcode ortamında Swift ile, Android uygulamaları Android Studio'da Kotlin ile yazılır. Tek kod tabanından iki platforma çıkmak için Flutter (Dart dili) ya da React Native (JavaScript ve TypeScript) gibi araçlar kullanılır. Hangisinin seçileceği, uygulamanın ihtiyaçlarına ve bakımı yapacak ekibin bilgisine bağlıdır.

Uygulamanın maliyetini neler belirler?

Özellik sayısı ve karmaşıklığı, platform sayısı, tasarımın özgünlüğü, arka uç ve entegrasyonlar, test kapsamı ve yayın sonrası bakım başlıca etkenlerdir. Özellik listesi ne kadar net olursa teklifler de o kadar karşılaştırılabilir olur.

Uygulama fikrinizi kapsamı belli bir projeye dönüştürmek istiyorsanız teklif alın; ihtiyacınızı birlikte konuşalım.