Mobil uygulama geliştirme firmasını portföy inceleyerek seçemezsiniz. Seçimi belirleyen üç madde sözleşmede: geliştirici hesabı kimin adına açılacak, kaynak kod üzerindeki mali haklar yazılı olarak devredilecek mi, yayından sonraki 12 ayın yükümlülüğü kimde. Bu üçü netleşmeden alınan teklifler birbiriyle kıyaslanamaz; çünkü aynı rakamı yazan iki firmadan biri size bir ürün, diğeri bir kiralama satıyor olabilir. Aşağıda bu üç maddenin teknik gerçeği ve teklif isterken şartnameye koyacağınız somut maddeler var.
Uygulama App Store'da kimin adına görünecek? Bu tek soru sahipliği belirliyor
Apple Developer Program'a kurum olarak kaydolmak için şirketinizin bir D-U-N-S numarası olması ve sözleşme yapabilen bir tüzel kişi olması gerekiyor. Apple bu noktada net: DBA, ticari unvan takma adı ya da şube kabul edilmiyor ve kuruluşun adı uygulamalarınızın App Store'daki satıcı adı olarak gösteriliyor. Kayıt ücreti yıllık 99 USD, hesabı açan kişi ise "Account Holder" oluyor ve kuruluşu hukuken bağlama yetkisine sahip olmak zorunda (bkz. Apple Developer Program Enrollment).
Pratik sonucu şu: ajans kendi hesabından yayınlarsa, App Store listelemesinde satıcı olarak ajansın adı yazar. Kullanıcı yorumları, indirme geçmişi ve sıralama sinyalleri o hesapta birikir. Google Play tarafında da tablo benzer; oradaki geliştirici kaydı tek seferlik 25 USD ile açılıyor.
Doğru kurulum şu: hesaplar sizin şirketinizin adına açılır, ajansa App Store Connect'te "App Manager" / "Developer" rolü, Play Console'da sınırlı erişim verilir. Bu kurulumda ilişki bittiğinde yapılacak iş bir kullanıcıyı silmekten ibarettir.
"Sonra devrederiz" cümlesi Apple'ın devir kriterlerine takılıyor
Ajansın hesabından yayınlanan bir uygulamayı sonradan devralmak teorik olarak mümkün, ama App Transfer'ın sert ön koşulları var ve teklif aşamasında kimse bunları anlatmıyor. Apple'ın devir kriterleri arasında şunlar sayılıyor (bkz. App Store Connect Help, "App transfer criteria"):
- Uygulamanın App Store'a yayımlanmış en az bir sürümü olmalı. Hiç yayına çıkmamış bir uygulama devredilemez.
- Uygulama şu durumlarda olmamalı:
Processing for Distribution,Waiting for Review,In Review,Accepted,Pending Developer Release,Pending Apple Release. Yani devir, güncelleme takviminin arasına sıkıştırılamaz. - Uygulama hiçbir ülkede ön siparişte olmamalı.
- Uygulama içi satın alma ürün kimlikleri, alıcı hesaptaki başka bir uygulamanın ürün kimlikleriyle çakışmamalı. Ajansın onlarca müşteriye
premium_monthlygibi jenerik ürün ID'leri açtığı durumlarda bu madde tek başına devri kilitler. - Her iki hesap da güncel sözleşmeleri kabul etmiş ve beklemede olmayan durumda olmalı.
Devrin geçtiği durumda bile bazı şeyler gelmiyor. Apple'ın kendi devir dokümanında sayılanlardan öne çıkanlar:
| Devirle birlikte gelen | Gelmeyen / bozulan |
|---|---|
| Yorumlar ve puanlar, bundle ID, CloudKit verisi, Sign in with Apple Service ID, webhook'lar | Promosyon kodları (devirden sonra yenisi üretilemiyor) |
| Uygulama App Store'da indirilebilir kalabiliyor | Apple Pay merchant ID (uygulamayla birlikte taşınmıyor) |
| Otomatik yenilenen abonelikler (uygulamaya özel shared secret ile) | Game Center grup üyeliği ve çapraz uygulama eşleşme matrisi |
| — | Keychain paylaşımı: güncelleme gönderirken keychain yeniden kurulmalı, kullanıcılar bir kez yeniden giriş yapmak zorunda kalıyor |
| — | TestFlight: devir öncesi tüm build ve test kullanıcıları temizlenmeli; Xcode Cloud verisi silinmeli |
| — | Gönderen taraf App Analytics geçmişine erişimini kaybediyor; yani tarihsel edinim verisi devirle birlikte size gelmiyor, ajansta da kalmıyor |
Keychain maddesi en pahalıya patlayanı. Oturumu keychain'de tutan bir uygulamada devir sonrası tüm kullanıcılar bir kez çıkış yapmış olur. Kimlik doğrulaması SMS OTP ile çalışan bir uygulamada bu, tek seferlik ama toplu bir OTP maliyeti ve ölçülebilir bir kullanıcı kaybı demektir.
Google Play tarafında devir daha az kırılgan ama bürokratik: her iki hesabın kayıt ücreti işlem kimliği (registration transaction ID) isteniyor ve Google destek talebi genelde iki iş günü içinde yanıtlıyor. Test grupları taşınmıyor, yeniden kurulması gerekiyor; devirden önce oluşmuş siparişlerin iadesi için eski hesaba erişim şart (bkz. Google Play Console Yardım, "Uygulamanızı aktarma").
Kaynak kodu teslim almak, kaynak koda sahip olmak değildir
Türk hukukunda bilgisayar programları 5846 sayılı Fikir ve Sanat Eserleri Kanunu kapsamında korunuyor. Kanunun 52. maddesi mali haklara dair sözleşme ve tasarrufların yazılı olmasını ve devredilen hakların ayrı ayrı gösterilmesini şart koşuyor. "Proje bitince kodlar size teslim edilecektir" cümlesi bu şartı karşılamıyor: teslim bir fiil, devir bir hukuki işlem.
Sözleşmeye yazılması gereken, hangi mali hakların devredildiğinin tek tek sayılması: işleme, çoğaltma, yayma, temsil, umuma iletim. Ayrıca 49. madde gereği bir mali hakkı devralanın bunu üçüncü kişiye devri eser sahibinin yazılı muvafakatine bağlı; yani taşeron kullanan bir ajansta zincirin her halkasında yazılı devir olmalı.
Teklif alırken sorulacak somut soru şu: "Bu işin hangi kısmı taşerona veriliyor ve taşeronla aranızdaki mali hak devri yazılı mı?" Cevap net değilse kodun tamamı üzerinde tek bir sahiplik zinciri yok demektir.
Üçüncü parti bileşenlerin lisansı sizin sorununuz oluyor
Uygulamada kullanılan her paketin lisansı, uygulamanın dağıtım hakkını etkiliyor. Pratikte iki şeye bakın: bağımlılık listesinde copyleft lisanslı (GPL ailesi) bir bileşen var mı, ve ticari lisansla kullanılan bir SDK varsa lisans kimin adına alınmış. İkincisi sık atlanıyor: harita, video oynatıcı, OCR veya push analitik SDK'sının lisansı ajansın adına alınmışsa ilişki bittiğinde uygulamanız lisanssız kalıyor.
Teslim şartnamesine bir LICENSES.md ve makine tarafından üretilmiş bir SBOM (yazılım malzeme listesi) çıktısı koyun. Bu, teslim gününde bir saatlik iş; altı ay sonra tespit edilirse haftalarca sürüyor.
Teklifleri kıyaslanabilir kılan tek şey adam-gün dökümü
Toplam fiyat karşılaştırması yanıltıcı, çünkü kapsam aynı değil. İsteyeceğiniz şey kalem kalem adam-gün: analiz, UI tasarımı, iOS, Android, backend, entegrasyonlar, test, mağaza yayını, proje yönetimi. Bu dökümü veremeyen firma kapsamı çözmemiş demektir.
ininia'nın kendi tahmin modelinde kullandığı birim fiyat bandı 300–400 USD/adam-gün (kıdemli ekip, yapay zeka destekli geliştirme akışı). Bu bandı kendi tekliflerinizi sınamak için kullanabilirsiniz: toplam fiyatı adam-gün sayısına bölün. Çıkan rakam bu bandın çok altındaysa ya kapsam eksik yazılmış ya da ekip kıdemi farklı; çok üstündeyse ajansın araya koyduğu pay yüksek.
| Sözleşme modeli | Ne zaman doğru | Gizli maliyeti |
|---|---|---|
| Sabit fiyat | Kapsam ekran ekran yazılabiliyorsa; entegrasyon sayısı sabitse | Firma riski fiyata gömer; her değişiklik "kapsam dışı" tartışması üretir |
| Adam-gün (T&M) | Kapsam keşifle netleşecekse; MVP ve sonrası iterasyon planlıysa | Tavan konmazsa bütçe öngörülemez; haftalık burn raporu şart |
| Sabit kapsamlı MVP + T&M devam | Çoğu ilk mobil proje | MVP kapsamının sınırı yazılı değilse iki modelin kötü yanı birleşir |
Kendi kapsamınız için bir ön bant görmek isterseniz proje fiyat hesaplama aracı aynı modeli kullanıyor.
Mağaza reddi kimin sorunu? Sözleşmede yazmıyorsa sizin
Uygulama reddedildiğinde takvim kayıyor ve fatura genellikle müşteriye çıkıyor. Reddin büyük bölümü öngörülebilir dört maddeden geliyor; bunları teklif aşamasında kabul kriterine çevirin (bkz. Apple App Store Review Guidelines):
- 2.1(a) App Completeness. Girişi olan uygulamalarda demo hesap bilgisi gönderilmek ve arka uç servisi açık olmak zorunda. Staging kapatılıp gönderilen build reddin en ucuz sebebi.
- 4.2 Minimum Functionality. Bir web sitesinin paketlenmiş hâli kabul edilmiyor. WebView ağırlıklı teslim planlanıyorsa bu riski sözleşmede kimin taşıdığını yazın.
- 4.2.6. Ticarileştirilmiş şablon veya uygulama üretim servisinden çıkan uygulamalar, içeriğin sahibi tarafından gönderilmediği sürece reddediliyor. Ajansın kendi hesabından onlarca müşteri uygulaması yayınlaması tam olarak bu maddenin hedefi.
- 5.1.1(v) Account Sign-In. Hesap oluşturmaya izin veren uygulama, uygulama içinden hesap silmeyi de sunmak zorunda. Bu backend tarafında iş demek; "silme talebi e-posta ile alınır" çözümü geçmiyor.
Dördüncü madde özellikle KVKK tarafıyla birlikte planlanmalı; silme akışının veri saklama politikanızla tutarlı olması gerekiyor. Mobil tarafta bizim yaklaşımımızı mobil uygulama geliştirme sayfasında, güvenlik ve uyum tarafını güvenlik merkezi sayfasında bulabilirsiniz.
Yayın günü projenin sonu değil; 12 aylık yükümlülük kimde?
Her yıl gelen yeni iOS ve Android sürümleri, hedef API seviyesi zorunlulukları ve mağaza politika değişiklikleri bakım işi üretiyor. Somut hâli: 31 Ağustos 2026 itibarıyla Google Play'de yeni uygulamalar ve güncellemeler Android 16 (API 36) ya da üstünü hedeflemek zorunda. Mevcut uygulamaların yeni kullanıcılara açık kalabilmesi için hedefi en az Android 15 (API 35) olmalı.
API 34 ve altını hedefleyen uygulama mağazadan kaldırılmıyor, ama yalnızca kendi hedef sürümü ve altındaki cihazlarda görünüyor. Süre uzatımı Play Console üzerinden 1 Kasım 2026'ya kadar talep edilebiliyor (bkz. Google Play hedef API seviyesi gereksinimleri).
Bunun ticari karşılığı şu: bir yıl bakımsız bırakılan bir uygulama silinmiyor, sessizce yeni cihazlarda görünmez hâle geliyor. Bu düşüşü indirme grafiğinde fark etmeniz aylar alıyor.
Sözleşmeye yazılacak dört şey: garanti süresi ve garantinin neyi kapsadığı (hata düzeltme evet, yeni özellik hayır), yıllık platform uyum bakımının ayrı bir kalem olarak fiyatı, kritik hata için yanıt ve çözüm süresi, ve ekibin ayrılması hâlinde devir dokümantasyonunun kapsamı.
Teklif isterken şartnameye ekleyeceğiniz 8 madde
Aşağıdakini olduğu gibi kopyalayıp teklif talebinize ek yapabilirsiniz. Bu sekiz maddeye net cevap veremeyen firmayı kısa listeye almayın.
- Apple Developer Program ve Google Play Console hesapları bizim tüzel kişiliğimiz adına açılacak; geliştirici ekibe rol bazlı erişim verilecek.
- Kaynak kod, ilk günden itibaren bizim sahipliğimizdeki depoya push edilecek; teslimde tek seferlik zip kabul edilmiyor.
- Mali hak devri sözleşmede ayrı madde olarak, devredilen haklar tek tek sayılarak yazılacak (FSEK md. 52).
- Taşeron kullanılacaksa isimleri ve taşeronla yapılan yazılı mali hak devri beyan edilecek (FSEK md. 49).
- Teslim paketinde bağımlılık lisans listesi ve SBOM bulunacak; ticari SDK lisansları bizim adımıza alınacak.
- Teklif kalem kalem adam-gün içerecek; toplam fiyat tek satır olarak kabul edilmiyor.
- Mağaza reddi riski: 2.1(a), 4.2, 4.2.6 ve 5.1.1(v) maddelerine uyum geliştiricinin sorumluluğunda; bu maddelerden kaynaklanan red, teslim takvimini uzatma sebebi sayılmaz.
- Yayın sonrası 12 ay için platform uyum bakımı ayrı fiyatlandırılacak; kritik hata yanıt süresi yazılacak.
Bu sekiz maddeyi kendi projenizin kapsamına oturtmak isterseniz iletişim sayfasından yazabilirsiniz. Ürünü sıfırdan kuruyorsanız kapsamı önce daraltmak genellikle daha ucuz; o yaklaşımı MVP geliştirme sayfasında anlattık. Uygulamanın arkasındaki servis katmanı için API geliştirme tarafına da bakabilirsiniz.
Bu yazıdaki mağaza kuralları ve devir kriterleri 25 Eylül 2026 tarihinde birincil kaynaklardan doğrulanmıştır: Apple Developer Program Enrollment sayfası, App Store Connect Help "App transfer criteria" ve "Overview of app transfer" sayfaları, App Store Review Guidelines (2.1, 4.2, 4.2.6, 5.1.1), Google Play Console Yardım uygulama aktarma sayfası. Hukuki atıflar 5846 sayılı Fikir ve Sanat Eserleri Kanunu'nun ilgili maddelerinedir ve hukuki görüş yerine geçmez. Adam-gün bandı ininia'nın kendi tahmin modelindeki değerdir (300–400 USD/adam-gün) ve bağlayıcı teklif değildir. Mağaza politikaları sık değişiyor; sözleşme yazmadan önce güncel kılavuzu teyit edin.
