mobil uygulama geliştirme
Mobil Uygulama Geliştirme
iOS ve Android mobil uygulama ihtiyacını kullanıcı davranışı, cihaz yetenekleri, backend, güvenlik, mağaza yayını ve bakım kararlarıyla ele alıyor; ilk sürümden canlı işletime kadar sürdürülebilir mobil ürünler geliştiriyoruz.
Önce problem, kullanıcı ve ilk faz sınırı. Sonra teknoloji.
Uygunluk
Bu hizmet sizin için doğru başlangıç mı?
Kullanıcının ana işi telefonda gerçekleşiyor; kamera, konum, bildirim, çevrimdışı kullanım veya mağaza dağıtımı ürünün merkezindeyse ayrı mobil uygulama doğru seçenek olabilir. Yalnız telefondan erişim gerekiyorsa mobil uyumlu web daha sade bir başlangıç olabilir.
Kamera, konum, bildirim, biyometri veya çevrimdışı kullanım ihtiyacı olan ürün ekipleri
iOS ve Android uygulamasını backend, yönetim paneli ve entegrasyonlarla birlikte kurmak isteyen girişimler
Çözülen sürtünme
Masaüstü ekranını küçültmeyin; kullanıcının hareket halindeki işini yeniden tasarlayın.
- 01
Müşteri hesabı, sipariş, rezervasyon veya üyelik işlemleri sunan mobil ürün
- 02
Saha ekibinin görev, fotoğraf, imza, konum ve kapanış kaydı tuttuğu uygulama
- 03
SaaS veya dijital ürünün iOS ve Android kullanıcı deneyimi
- 04
Mevcut ERP, CRM, ödeme veya operasyon sistemine bağlı mobil iş akışı
Çalışan mobil iş akışı kanıtı
Telefon bağlamındaki görevi çalışan ürün akışında inceleyin.
Saha servis demosu; teknisyenin telefonda görev, kontrol listesi, parça, fotoğraf ve kapanış adımlarını yönetim akışıyla aynı kayıt üzerinde nasıl ilerletebildiğini gösterir.
Gerçek iç ürün vakası
CanlıdaÇalışan demo platformu
ODTÜ’lüden Yazılım'ın kendi web sitesinde geliştirdiği bu iç ürün; teklif, saha servis, yönetim, AI destek ve SaaS aktivasyon operasyonunu yalnız ekran görüntüsüyle değil, sonuna kadar ilerleyen beş çalışan karar akışıyla görünür hale getiriyor.
Bu bir müşteri projesi, anonim müşteri referansı veya başarı hikâyesi değildir. Kendi ürünümüz üzerinde verdiğimiz kapsam, mimari, güvenlik, SEO, dönüşüm ve canlı işletim kararlarını doğrulanabilir çıktılarıyla anlatan gerçek bir iç ürün geliştirme vakasıdır.
Gerçek geliştirme vakasını okuyunDEMO 01 Çalışıyor
Saha servis operasyon merkezi
Mobil teknisyen görevini, izin ve saha verisini masaüstü planlama ile aynı iş emri yaşam döngüsünde ele alan responsive ürün akışını gösterir.
Çalışan demoyu açınBu canlı demo responsive web üzerinde çalışan kurgusal bir saha akışıdır; App Store veya Google Play'de yayınlanmış native uygulama kanıtı değildir. Kanıtlanan şey mobil görev tasarımı, sunucu taraflı durum yönetimi ve masaüstü–mobil veri sürekliliğidir.
Karar ve risk
Kod başlamadan önce hangi kararlar netleşmeli?
Mobil uygulamada ekran listesi kapsamı anlatmaya yetmez. Hedef cihazlar, işletim sistemi desteği, izinler, çevrimdışı davranış, backend/API, mağaza hesapları, analitik, hata izleme ve sürüm bakımı kod başlamadan görünür olmalıdır.
01
Karar noktası
Mobil gereklilik
Kullanıcının işi gerçekten telefonda mı gerçekleşiyor; kamera, konum, bildirim, biyometri, çevrimdışı kullanım veya mağaza dağıtımı ürün için zorunlu mu? Yalnız küçük ekranda açılmak ayrı uygulama gerektirmeyebilir.
02
Karar noktası
Native veya çapraz platform seçimi
Performans, cihaz özelliği, ekip yetkinliği, iki platformdaki deneyim farkı ve bakım bütçesi birlikte değerlendirilmeden teknoloji kararı verilmemelidir.
03
Karar noktası
Backend ve veri güvenliği
Mobil uygulama verinin ana kaynağı değildir. API yetkisi, oturum, cihazda saklanan veri, şifreleme, silme ve denetim izi backend ile birlikte tasarlanmalıdır.
04
Karar noktası
İzin ve bağlantı davranışı
Kullanıcı kamera, konum veya bildirim iznini reddederse; internet zayıflar ya da kesilirse ana görevin nasıl devam edeceği baştan tanımlanmalıdır.
05
Karar noktası
Mağaza ve hesap sahipliği
Apple ve Google geliştirici hesapları, sertifikalar, paket kimliği, gizlilik beyanları, ekran görüntüleri ve inceleme yanıtları teklif içinde açık sorumluluklara dönüşmelidir.
06
Karar noktası
Sürüm ve bakım modeli
İşletim sistemi güncellemeleri, cihaz farklılıkları, crash izleme, güvenlik yamaları, kullanıcı geri bildirimi ve yeni sürüm takvimi canlı sonrası planlanmalıdır.
Mobil ürün kapsamı
Mobil uygulama şirketi seçerken ekranı değil, teslim zincirini karşılaştırın.
Aynı mobil uygulama talebi; mobil uyumlu web, çapraz platform ürün, native iOS/Android uygulaması veya mevcut sisteme bağlı saha aracı anlamına gelebilir. Teklifleri karşılaştırmadan önce kanal, cihaz yeteneği, backend ve yayın sorumluluğunu ayırmak gerekir.
Ürün yolu karşılaştırması
İhtiyacınız hangi mobil ürün yoluna daha yakın?
01
Mobil uyumlu web veya PWA
Kullanıcı tarayıcıdan erişebilir; form, panel ve temel cihaz özellikleri ilk faz için yeterlidir.
Kapsam sınırı: Yoğun çevrimdışı kullanım, arka plan işlemleri ve bazı cihaz yetenekleri tarayıcıya göre sınırlı kalabilir.
02
Çapraz platform mobil uygulama
Ortak ürün akışı iOS ve Android'de tutarlı ilerler; tek ekip ve paylaşılan kod tabanı önemli avantaj sağlar.
Kapsam sınırı: Platforma özgü davranışlar, eklenti olgunluğu ve performans ihtiyacı ayrıca test edilmelidir.
03
Native iOS veya Android
Platforma özgü deneyim, ileri cihaz entegrasyonu veya performans ana ürün değerinin parçasıdır.
Kapsam sınırı: İki platform için ayrı geliştirme ve bakım maliyeti doğabilir; ortak özelliklerin eş zamanlı ilerlemesi planlanmalıdır.
04
Web panel + mobil saha uygulaması
Yönetim bilgisayardan planlama ve raporlama yaparken saha ekibi telefonda kısa görevler tamamlar.
Kapsam sınırı: İki yüzeyin ortak veri, yetki, senkronizasyon ve sürüm sözleşmesi birlikte kurulmalıdır.
Mağaza ve canlı işletim
Mağazaya yüklemek, mobil ürünü tek başına canlıya çıkarmak değildir.
Mobil ürün; mağaza kaydı kadar hesap sahipliği, veri güvenliği, cihaz uyumu ve canlı izleme katmanlarıyla birlikte işletilir. Bu sınırlar teklif ve kabul planında görünür olmadığında ilk sürüm yayınlansa bile bakım riski açık kalır.
01
Hesap, sertifika ve mağaza kaydı
Geliştirici hesabı, paket kimliği, sertifika/provisioning, gizlilik bilgisi, ekran görüntüsü, açıklama ve inceleme iletişimi.
02
Cihaz, izin ve erişilebilirlik
Hedef ekranlar, işletim sistemi sürümleri, kamera/konum/bildirim izinleri, klavye, dinamik yazı ve dokunma alanı testleri.
03
Backend, oturum ve veri
API yetkilendirmesi, token saklama, cihazdaki hassas veri, senkronizasyon, hata tekrarı, silme ve hesap kapatma davranışı.
04
Yayın, ölçüm ve bakım
Test dağıtımı, kademeli yayın, crash ve performans izleme, analitik, kullanıcı geri bildirimi, geri dönüş ve yeni sürüm takvimi.
Teklif ve kabul
Mobil uygulama teklifinde bulunması gereken kabul başlıkları
- 01
Ana görevin hedef iOS ve Android cihazlarda uçtan uca tamamlanması
- 02
İzin reddi, zayıf bağlantı, çevrimdışı durum ve senkronizasyon davranışı
- 03
Kimlik doğrulama, oturum, hassas veri ve API güvenliği kontrolleri
- 04
Hedef cihaz/işletim sistemi matrisi, erişilebilirlik ve performans sınırı
- 05
Mağaza hesabı, paket kimliği, sertifika, gizlilik ve inceleme sorumluluğu
- 06
Crash izleme, analitik, sürüm geri dönüşü, kaynak kod devri ve bakım planı
İlk sürüm sırası
İlk sürümü dört görünür teslim kararıyla ilerletin.
- 01
Mobil görev kanıtı
Ana kullanıcı, telefon bağlamı, kritik görev, izinler ve başarının nasıl ölçüleceği prototipte doğrulanır.
- 02
Cihazda çalışan kesit
Gerçek API, oturum ve gerekli cihaz özelliğiyle tek ana akış hedef cihazlarda çalışır.
- 03
Kabul ve mağaza hazırlığı
Hata/izin/bağlantı senaryoları, cihaz matrisi, güvenlik, mağaza içeriği ve hesap sahipliği tamamlanır.
- 04
İzlenen sürüm
Test kullanıcıları veya kademeli yayınla crash, performans, davranış ve geri bildirim izlenir; sonraki sürüm kararı verilir.
Kontrollü ilerleme
Mobil ürünü kritik kullanıcı davranışı ve gerçek cihaz koşulları etrafında geliştiririz.
Önce tek bir mobil görevi ve başarı ölçüsünü doğrular; ardından gerçek API, izin, bağlantı ve cihaz senaryolarıyla çalışan dar bir sürüm çıkarırız. Mağaza ve bakım kararlarını son güne bırakmayız.
- 01
Mobil görev ve kanal kararı
Kullanıcının telefonda tamamlayacağı ana işi, hedef cihazları ve mobil web, çapraz platform veya native uygulama seçeneklerini birlikte sınırlarız.
- 02
Akış, izin ve cihaz prototipi
Kritik ekranları; boş, hata, izin reddi, zayıf bağlantı ve erişilebilirlik durumlarıyla gerçek cihazlarda doğrularız.
- 03
Çalışan mobil kesit
Kimlik doğrulama, gerçek API, ana işlem, bildirim veya gerekli cihaz yeteneğini tek uçtan uca akışta çalıştırırız.
- 04
Test, mağaza ve izlenen yayın
Cihaz/işletim sistemi matrisini, güvenliği, analitiği, hata izlemeyi, mağaza hazırlığını, geri dönüşü ve bakım sorumluluğunu kabul senaryolarıyla tamamlarız.
Teslim edilebilir çıktılar
Proje sonunda ne görünür ve devredilebilir olur?
Mobil kullanıcı akışları ve ilk sürüm kapsam notu
iOS ve Android için test edilebilir mobil uygulama
Kimlik doğrulama, rol, izin ve güvenli oturum modeli
Backend/API, yönetim paneli ve gerekli entegrasyonlar
Hedef cihaz, işletim sistemi ve kabul testi matrisi
Mağaza yayını, analitik, hata izleme ve sürüm planı
Kaynak kod, hesap sahipliği, teknik devir ve bakım dokümanı
Kısa brief
İlk mesajda dört kısa bilgi yeterli.
Uzun teknik doküman hazırlamanız gerekmez. Eksik kalan kararları ilk görüşmede birlikte tamamlarız.
- 01
Bugün hangi iş zor ilerliyor?
Müşteri hesabı, sipariş, rezervasyon veya üyelik işlemleri sunan mobil ürün
- 02
Kim kullanacak?
Müşterisinin veya ekibinin ana işi telefon üzerinden tamamlamasını isteyen şirketler
- 03
Hangi veri veya sistem var?
Excel, mevcut yazılım, API, doküman veya manuel kayıt varsa ilk mesajda belirtin.
- 04
İlk sürüm başarılı sayılması için ne değişmeli?
Mobil kullanıcı akışları ve ilk sürüm kapsam notu
Örnek teslim çıktıları
Mobil Uygulama Geliştirme sürecinde hangi çıktılar somutlaşır?
Mobil Uygulama Geliştirme ihtiyacında önce konuşmayı somutlaştıran karar notu, kapsam sınırı ve risk listesi oluşmalıdır. Aşağıdaki formatlar gerçek müşteri belgesi değil, ilk görüşme ve ilk fazı nasıl görünür tuttuğumuzu anlatan örnek yapılardır.
Bu bölüm temsili formatları anlatır; gerçek müşteri belgesi, garanti sonuç, referans veya başarı metriği değildir.
01
Görüşme
İlk görüşme karar notu
Talebi ekran listesi olmaktan çıkarıp problem, kullanıcı, veri ve sonraki adım olarak okunabilir hale getirir.
Örnek format
Örnek format: mevcut süreç, ilk faz adayı, açık risk, sonraki adım.
- Problem cümlesi
- Kullanıcı rolleri
- Mevcut veri veya sistem
- Önerilen başlangıç rotası
02
Kapsam
Kapsam notu
Şimdi yapılacakları, sonraki faza kalacakları ve ilk sürümü şişirecek istekleri ayrı ayrı görünür yapar.
Örnek format
Örnek format: ilk faz kapsamı, faz dışı istekler, kabul sınırı.
- İlk faz ana akışı
- Faz dışı modüller
- Kabul edilebilir sınır
- Açık kalan kararlar
03
Risk
Risk listesi
Veri, entegrasyon, kullanıcı alışkanlığı, bakım ve yapay zekâ hata sınırı gibi konuları teklif öncesinde konuşulur hale getirir.
Örnek format
Örnek format: risk, etkisi, ilk kontrol adımı, karar sahibi.
- Veri belirsizliği
- Entegrasyon bağımlılığı
- Kullanım alışkanlığı
- Bakım ve devretme noktası
04
İlk faz
İlk faz planı
İlk sürümde hangi akışın hangi sırayla çıkacağını sadeleştirir; ürünün küçük ama test edilebilir kalmasına yardım eder.
Örnek format
Örnek format: hafta, ana çıktı, geri bildirim noktası, sonraki karar.
- Öncelikli kullanıcı akışı
- Ara çıktı sırası
- Test ve geri bildirim
- Sonraki faz sinyali
Sonraki adım
Bu çıktıları kendi ihtiyacınıza uyarlayalım
Uzun brief hazırlamanız gerekmez. Mevcut süreci birkaç cümleyle yazın; ilk görüşmede hangi çıktının gerçekten gerekli olduğunu birlikte ayıralım.
Sık Sorulanlar
Karar vermeden önce netleşen sorular
Kapsam, fiyat, ilk sürüm ve yapay zekâ uygunluğu gibi konularda en sık gelen soruları kısa ve dürüst cevaplarla topluyoruz.
iOS ve Android mobil uygulama geliştiriyor musunuz?
Evet. iOS ve Android için mobil uygulama geliştiriyoruz. Native, çapraz platform veya mobil web kararını; hedef kullanıcı, cihaz yetenekleri, performans, iki platformdaki deneyim ve uzun dönem bakım ihtiyacına göre veriyoruz.
Native uygulama mı çapraz platform mu daha doğru?
Tek bir doğru yoktur. İleri cihaz entegrasyonu ve platforma özgü deneyim kritikse native yaklaşım; iki platformda ortak akış ve daha merkezi geliştirme önemliyse çapraz platform uygun olabilir. Karar prototip, teknik risk ve bakım planıyla doğrulanmalıdır.
Mobil uygulama yerine mobil uyumlu web yeterli olur mu?
Kullanıcı tarayıcıdan ana işi rahatça tamamlayabiliyor; yoğun çevrimdışı kullanım, arka plan işlemi veya ileri cihaz özelliği gerekmiyorsa yeterli olabilir. Ayrı uygulama yalnız daha profesyonel göründüğü için seçilmemelidir.
Mobil uygulamayla birlikte backend ve yönetim paneli de geliştirilir mi?
İhtiyaca göre evet. Kullanıcı, içerik, işlem, rol, rapor veya entegrasyon yönetilecekse mobil uygulamanın yanında güvenli API ve uygun bir yönetim yüzeyi gerekir. Bunlar teklif içinde ayrı teslim ve kabul başlıkları olarak görünmelidir.
App Store ve Google Play yayın süreci kapsama dahil olabilir mi?
Olabilir. Geliştirici hesabı ve mağaza varlıklarının mümkün olduğunca müşteri sahipliğinde kalmasını; paket kimliği, sertifika, gizlilik bilgileri, ekran görüntüleri, test dağıtımı ve inceleme yanıtlarının sorumluluk matrisiyle yürütülmesini öneriyoruz.
Mobil uygulama geliştirme maliyeti nasıl belirlenir?
Kullanıcı akışı, platform sayısı, native veya çapraz platform yaklaşımı, backend/API, entegrasyon, çevrimdışı çalışma, cihaz özellikleri, güvenlik, test matrisi, mağaza yayını ve bakım kapsamı maliyeti birlikte belirler. Bu yüzden yalnız ekran sayısına göre sağlıklı teklif oluşmaz.
Mobil uygulamanın kaynak kodu ve mağaza hesapları kime ait olur?
Sahiplik teklif ve sözleşmede açıkça yazılmalıdır. Kaynak kod deposu, geliştirici hesapları, paket kimliği, sertifikalar, backend ve analitik hesapları mümkün olduğunca müşteri kontrolünde kurulmalı; devir ve erişim adımları teslim planına eklenmelidir.
Sonraki adım
Mobil Uygulama Geliştirme için doğru kapsamı birlikte çıkaralım.
Problemi, kullanıcıyı ve beklenen ilk değişimi anlatın. İlk görüşmede teknik riski ve ilk sürüm sınırını görünür hale getirelim.
Projenizi anlatın