KVKK uyumlu mobil uygulama geliştirme, uygulamanın sonuna bir aydınlatma metni eklemekten çok daha geniş bir konudur. Kullanıcı kaydı, profil ekranı, ödeme, konum izni, bildirim, mesajlaşma, dosya yükleme, analitik ve yapay zekâ özellikleri daha tasarım aşamasında kişisel veri perspektifiyle ele alınmalıdır.
Özellikle üyelik, sağlık, eğitim, finans, emlak, e-ticaret, topluluk ve kurumsal saha operasyonu gibi alanlarda mobil uygulama geliştiren şirketler için KVKK uyumu doğrudan ürün mimarisine bağlıdır. Formda hangi alanların istendiği, verinin hangi API üzerinden taşındığı, loglarda neyin tutulduğu, kimlerin admin panelinden hangi kayda eriştiği ve kullanıcının rızasını nasıl geri alabildiği aynı sistemin parçalarıdır.
Atalay Tech olarak mobil uygulama, web platformu, yönetim paneli, API entegrasyonu ve yapay zekâ destekli yazılım projelerinde gördüğümüz kritik nokta şudur: KVKK uyumu hukuk ekibinin hazırladığı metinlerle başlar, fakat mühendislik ekibinin doğru veri mimarisi kurmasıyla sürdürülebilir hale gelir. Bu nedenle mobil uygulama geliştirme süreci planlanırken KVKK, güvenlik ve bakım maddeleri ayrı bir kontrol listesi olarak değil, ürün kararlarının içine gömülü şekilde düşünülmelidir.
Kişisel Verileri Koruma Kurumu, aydınlatma yükümlülüğünde kişisel verisi işlenen kişiye verinin kim tarafından, hangi amaçla, hangi hukuki sebebe dayanarak işlendiği ve kimlere aktarılabileceği gibi bilgilerin sağlanması gerektiğini belirtir. Ayrıca 18.02.2026 tarihli Kurul ilke kararında açık rıza metni ile aydınlatma metninin ayrı ayrı düzenlenmesi gerektiği vurgulanmıştır. Bu iki nokta mobil uygulama arayüzünde doğrudan karşılık bulur: Kullanıcıya tek bir uzun metin okutmak yerine, işlem anına uygun, anlaşılır ve ayrı onay akışları tasarlanmalıdır.
KVKK uyumlu mobil uygulama, kişisel verileri yalnızca hukuka uygun gerekçelerle toplayan, kullanıcıyı açıkça bilgilendiren, gereksiz veri istemeyen, veriyi güvenli biçimde işleyen ve kullanıcının haklarını yönetilebilir hale getiren uygulamadır.
Basit bir örnek üzerinden düşünelim. Bir üyelik uygulaması kullanıcıdan ad, soyad, e-posta, telefon, doğum tarihi, konum, profil fotoğrafı ve meslek bilgisi istiyorsa her alanın gerekçesi aynı değildir. E-posta giriş ve bildirim için gerekli olabilir. Profil fotoğrafı sosyal etkileşim için opsiyonel olabilir. Konum ise yalnızca yakınındaki etkinlikleri göstermek için isteniyorsa kullanıcı bu izni vermeden de temel uygulamayı kullanabilmelidir.
Bu yüzden KVKK uyumu üç katmanda ele alınmalıdır:
Bu üç katmandan biri eksikse uygulama kâğıt üzerinde uyumlu görünse bile pratikte risk üretir. Örneğin uygulamada güzel yazılmış bir aydınlatma metni bulunabilir; fakat admin panelinde tüm çalışanlar kullanıcıların kimlik belgelerine erişebiliyorsa uyum sürdürülebilir değildir.
KVKK ve GDPR aynı konuyu ele alır: kişisel verilerin hukuka uygun işlenmesi. Fakat Türkiye’de faaliyet gösteren, Türkiye’deki kullanıcılara hizmet veren veya Türkiye’de veri sorumlusu olan şirketler için KVKK ayrı bir uyum başlığıdır. Mobil uygulama güvenliği ise bu uyumu teknik olarak destekleyen mühendislik disiplinidir.
OWASP Mobile Application Security Verification Standard, mobil uygulama güvenliği için sektör standardı kabul edilen bir doğrulama çerçevesi sunar. Bu standart; güvenli depolama, kriptografi, kimlik doğrulama, ağ iletişimi, platform etkileşimi ve kod dayanıklılığı gibi başlıkları kapsar. KVKK ise doğrudan “hangi algoritmayı kullanmalısın?” demez; veri sorumlusunun uygun teknik ve idari tedbirleri almasını bekler. Bu nedenle KVKK uyumu ile mobil güvenlik birlikte ele alınmalıdır.
| Başlık | KVKK Uyumu | Mobil Uygulama Güvenliği |
|---|---|---|
| Ana odak | Kişisel verinin hukuka uygun işlenmesi | Uygulamanın teknik olarak korunması |
| Örnek konu | Aydınlatma metni, açık rıza, veri saklama | Token güvenliği, HTTPS, jailbreak/root kontrolü |
| Sorumluluk | Veri sorumlusu ve veri işleyen | Yazılım ekibi, güvenlik ekibi, altyapı ekibi |
| Uygulama anı | Keşif, tasarım, yayın, bakım | Geliştirme, test, yayın, izleme |
| Risk örneği | Gereksiz veri toplama | Token sızıntısı veya yetkisiz API erişimi |
| Birlikte kullanım | Veri minimizasyonu | Güvenli veri taşıma ve saklama |
Bir fitness uygulaması düşünelim. Kullanıcıdan boy, kilo, yaş, fotoğraf ve antrenman geçmişi alıyorsa bu bilgiler kişisel veri niteliği taşır. Bu verilerin hangi amaçla işlendiği KVKK konusudur; mobil cihazda şifresiz saklanmaması, API’ye yetkisiz erişim olmaması ve tokenların güvenli yönetilmesi ise mobil güvenlik konusudur.
KVKK uyumlu geliştirme, proje sonunda yapılan “hukuki kontrol” değildir. Süreç keşif aşamasında başlar, tasarımda görünür hale gelir, geliştirmede teknik güvence kazanır, testte doğrulanır ve yayın sonrası bakımda sürdürülebilir olur.
Atalay Tech’in mobil uygulama, web platformu ve yönetim paneli projelerinde uyguladığı yaklaşımda KVKK kontrolü özellikle veri akışı, kullanıcı rolleri, API erişimi ve admin panel yetkileri üzerinden değerlendirilir. Çünkü mobil uygulamanın kullanıcı tarafı ne kadar sade görünürse görünsün, risk genellikle arka plandaki veri işleme akışlarında oluşur.
| Aşama | KVKK Açısından Kontrol | Teknik Çıktı |
|---|---|---|
| Keşif | Hangi kişisel veriler toplanacak? | Veri envanteri taslağı |
| UX/UI tasarım | Onay ve bilgilendirme nerede gösterilecek? | Aydınlatma ekranı, izin akışı |
| MVP geliştirme | Gereksiz alanlar kaldırıldı mı? | Minimum veriyle çalışan sürüm |
| Backend/API | Yetki, log, token ve erişim kurgusu doğru mu? | Rol bazlı API mimarisi |
| Test | Rıza, silme, erişim ve hata senaryoları çalışıyor mu? | KVKK + güvenlik test listesi |
| Yayın | Store metinleri, gizlilik bağlantıları hazır mı? | App Store / Google Play uyum paketi |
| Bakım | Yeni özellikler veri riskini artırıyor mu? | Sürüm bazlı uyum kontrolü |
Bu tablo özellikle MVP projelerinde önemlidir. Hızlı çıkmak isteyen ekipler çoğu zaman “şimdilik tüm alanları alalım, sonra bakarız” yaklaşımını seçer. Oysa KVKK uyumlu MVP, daha az veriyle çalışan ve veri işleme amacı net olan üründür.
Keşif aşamasında ilk soru “hangi ekranları yapacağız?” değil, “hangi verileri neden toplayacağız?” olmalıdır. Bir pazar yeri uygulamasında satıcıdan IBAN, vergi bilgisi ve adres almak gerekebilir. Fakat alıcıdan doğum tarihi istemek, eğer yaş doğrulama veya mevzuat gereği yoksa gereksiz risk oluşturabilir.
Bu aşamada şu sorular netleştirilir:
Örneğin kurumsal saha operasyonu uygulamasında personel konumu gerçek zamanlı izleniyorsa bu özellik “teknik olarak yapılabilir” diye doğrudan eklenmemelidir. Konum takibinin amacı, kapsamı, saklama süresi, çalışma saatleriyle sınırlandırılması ve kullanıcı bilgilendirmesi netleşmelidir.
KVKK uyumu yalnızca hukuk metinlerinin varlığıyla ölçülmez; kullanıcının bu metinlere nasıl ulaştığı ve hangi işlem için hangi onayı verdiği de önemlidir. Kişisel Verileri Koruma Kurumu’nun 2026 tarihli ilke kararında açık rıza ve aydınlatma metinlerinin ayrı ayrı düzenlenmesi gerektiği belirtilmiştir. Mobil uygulama tasarımında bu karar, tek checkbox ile tüm izinleri toplama alışkanlığının riskli olduğunu gösterir.
İyi bir akışta kullanıcıya önce aydınlatma yapılır, sonra gerekiyorsa açık rıza ayrı bir seçim olarak sunulur. Pazarlama bildirimi, konum izni, kamera erişimi, rehber erişimi ve özel nitelikli veri işleme aynı onay kutusuna sıkıştırılmamalıdır.
Örneğin bir etkinlik uygulamasında:
Bu akış hem hukuki uyumu hem de dönüşümü iyileştirir. Kullanıcı neye izin verdiğini anladığında uygulamaya güven duyar.
Mobil uygulamalarda KVKK riski yalnızca kimlik veya telefon bilgisiyle sınırlı değildir. Cihaz kimliği, IP adresi, konum, davranış verisi, bildirim tokenı, kullanıcı mesajları, ödeme geçmişi ve dosya yüklemeleri de veri işleme kapsamına girebilir.
Özellikle giriş yapan kullanıcılarla anonim kullanıcıları ayırmak gerekir. Bir haber uygulamasında anonim davranış analitiği ayrı değerlendirilir; üyelik, yorum, abonelik ve kişiselleştirme geldiğinde veri işleme kapsamı büyür.
| Veri Türü | Mobil Örnek | Risk Seviyesi | Uyum Notu |
|---|---|---|---|
| Kimlik bilgisi | Ad, soyad, TCKN | Yüksek | Amaç ve saklama süresi net olmalı |
| İletişim bilgisi | Telefon, e-posta | Orta-yüksek | Bildirim ve pazarlama ayrılmalı |
| Konum verisi | Yakındaki hizmetler | Yüksek | Opsiyonel izin ve açık amaç gerekir |
| Cihaz verisi | Push token, cihaz modeli | Orta | Analitik ve bildirim amacı ayrılmalı |
| Davranış verisi | Tıklama, sepet, izleme | Orta | Çerez/analitik mantığıyla düşünülmeli |
| Dosya/veri yükleme | Kimlik, belge, fotoğraf | Yüksek | Yetki, şifreleme, silme kritik |
| Mesaj içerikleri | Birebir sohbet | Yüksek | Erişim ve moderasyon sınırı net olmalı |
| Ödeme verisi | Sipariş, fatura, tahsilat | Yüksek | PCI ve aracı ödeme kuruluşu ayrımı yapılmalı |
Bir emlak uygulamasında ilan sahibi belge yükleyebilir, kullanıcı favori ilanlarını saklayabilir, danışman ile mesajlaşabilir ve konum bazlı arama yapabilir. Bu tek ürün içinde birden fazla veri kategorisi olduğu için KVKK uyumu modül modül planlanmalıdır.
KVKK uyumu teknik mimaride en çok API, veri tabanı, admin paneli, loglama ve dosya depolama alanlarında görünür. Mobil uygulama yalnızca arayüzdür; kişisel verinin büyük kısmı backend, dosya sunucusu, bildirim servisi, analitik aracı veya üçüncü taraf entegrasyonlarda işlenir.
Bu yüzden API entegrasyonu yapılırken her endpoint için yetki kontrolü, veri minimizasyonu ve log politikası belirlenmelidir. “Kullanıcı kendi profilini görebilir” ile “admin tüm profilleri görebilir” arasında ciddi fark vardır. Rol bazlı erişim bu noktada zorunlu hale gelir.
Teknik tarafta dikkat edilmesi gereken başlıklar:
Örneğin bir sağlık topluluğu uygulamasında vaka tartışması, dosya yükleme ve kullanıcı mesajlaşması varsa yalnızca “giriş ekranı güvenli” demek yeterli değildir. Mesaj içerikleri, dosyalar, bildirim önizlemeleri, admin moderasyon yetkileri ve AI raporlama akışı birlikte tasarlanmalıdır.
Mobil uygulamalarda en sık yapılan hata, aydınlatma metni ile açık rızayı aynı checkbox içine koymaktır. Oysa aydınlatma, kullanıcının bilgilendirilmesidir; açık rıza ise belirli veri işleme faaliyetleri için özgür iradeyle verilen onaydır.
Bu ayrım pratikte şöyle uygulanabilir:
| Senaryo | Aydınlatma Gerekir mi? | Açık Rıza Gerekir mi? | Örnek UX |
|---|---|---|---|
| Üyelik için e-posta alma | Evet | Genellikle hayır | Kayıt ekranında aydınlatma bağlantısı |
| Pazarlama SMS’i gönderme | Evet | Evet | Ayrı checkbox |
| Konumla yakın hizmet gösterme | Evet | Duruma göre evet | İzin öncesi açıklama ekranı |
| Profil fotoğrafı yükleme | Evet | Duruma göre | Opsiyonel alan ve açıklama |
| Analitik/pazarlama takibi | Evet | Çerez/izin yaklaşımı gerekir | Tercih yönetimi ekranı |
| Özel nitelikli veri işleme | Evet | Çoğu durumda açık rıza veya özel şart | Ayrı ve belirgin onay akışı |
Mobil arayüzde kullanıcıyı boğmadan uyum sağlamak mümkündür. En doğru yaklaşım, her izin anında kısa, anlaşılır ve işlemle bağlantılı açıklama sunmaktır. Uzun metin bağlantıyla erişilebilir olmalı; ancak kullanıcının karar verdiği ekran yalın ve anlaşılır kalmalıdır.
Burada KVKK uyumluluğu yalnızca metin sayfasının varlığı değil, uygulama içindeki karar anlarının doğru tasarlanması anlamına gelir.
Ayşe, 28 yaşında freelance tasarımcı. El yapımı ürünlerini satmak için bir mobil pazaryeri uygulamasına kayıt oluyor. Uygulama Ayşe’den ad-soyad, e-posta, telefon, mağaza adı, banka bilgisi, ürün fotoğrafları ve fatura adresi istiyor.
Bu senaryoda KVKK uyumlu ürün akışı şöyle kurgulanmalıdır:
Aynı uygulamada Mehmet adlı alıcı yalnızca ürün geziyor, favorilere ekliyor ve sipariş veriyor olabilir. Mehmet’ten satıcıdaki kadar veri istenmemelidir. Veri minimizasyonu burada devreye girer: farklı kullanıcı rolleri için farklı veri kapsamı tasarlanır.
Bu ayrım yapılmadığında ürün ekibi gereksiz formlar oluşturur, dönüşüm düşer ve KVKK riski artar. İyi tasarlanmış KVKK akışı ise hem kullanıcı güvenini hem de kayıt tamamlama oranını destekler.
KVKK uyumlu mobil uygulama geliştirme maliyeti yalnızca ekran sayısına bağlı değildir. Veri işleme kapsamı, kullanıcı rolleri, admin panel yetkileri, üçüncü taraf entegrasyonlar, dosya yükleme, ödeme, mesajlaşma, bildirim ve raporlama modülleri maliyeti belirler.
Aşağıdaki aralıklar 2026 Türkiye pazarı için tahmini proje kapsamı değerlendirmesidir. Net fiyat; keşif, tasarım, teknik mimari ve entegrasyon sayısına göre değişir. Satın alma niyeti olan ekipler için mobil uygulama fiyatları aracı daha doğru bir ön değerlendirme sağlayabilir.
| Proje Tipi | Kapsam | Tahmini Süre | Tahmini Bütçe |
|---|---|---|---|
| KVKK uyumlu MVP | Üyelik, profil, temel admin, aydınlatma, silme talebi | 6-10 hafta | 250.000 - 600.000 TL + KDV |
| Orta ölçekli uygulama | Rol bazlı panel, bildirim, dosya, ödeme, API entegrasyonları | 10-18 hafta | 600.000 - 1.500.000 TL + KDV |
| Kurumsal mobil platform | Çoklu rol, gelişmiş log, entegrasyon, raporlama, güvenlik testi | 4-8 ay | 1.500.000 - 4.000.000 TL + KDV |
| Regülasyon yoğun proje | Sağlık, finans, üyelik, belge, hassas veri, denetim izi | 6-12 ay | 3.000.000 TL + KDV ve üzeri |
KVKK uyumluluğu maliyeti artıran bir “ekstra” gibi görülmemelidir. Proje başında doğru tasarlanırsa gereksiz veri alanları azaltılır, admin panel karmaşası önlenir ve sonradan yapılacak pahalı revizyonların önüne geçilir.
Her mobil uygulamanın KVKK ihtiyacı aynı değildir. Sadece üyelik ve profil barındıran bir MVP ile ödeme, belge, mesajlaşma ve yapay zekâ analizi içeren kurumsal platform aynı risk seviyesine sahip değildir.
| Kriter | MVP | Orta Ölçek | Kurumsal |
|---|---|---|---|
| Kullanıcı rolü | 1-2 rol | 3-5 rol | Çoklu departman ve yetki |
| Veri kapsamı | Temel üyelik | Profil, ödeme, dosya | Hassas veri, rapor, entegrasyon |
| Admin panel | Basit listeleme | Rol bazlı yönetim | Denetim izi ve detaylı yetki |
| Rıza yönetimi | Temel onaylar | Tercih merkezi | Sürüm bazlı kayıt ve raporlama |
| Güvenlik testi | Temel test | API + mobil test | Penetrasyon ve denetim süreci |
| Bakım ihtiyacı | Düşük-orta | Orta | Yüksek |
Bir girişim ilk sürümde tüm kurumsal özellikleri eklemek zorunda değildir. Fakat ilk sürümde veri mimarisi yanlış kurulursa büyüme aşamasında taşınması zor bir teknik borç oluşur. Bu nedenle mobil uygulama yaptırmak isteyen şirketler için en sağlıklı yaklaşım, MVP’yi küçük tutarken veri modelini ileride büyüyebilecek şekilde tasarlamaktır.
KVKK uyumu geliştirme tamamlandıktan sonra tek seferlik kontrolle bitmez. Mobil uygulamalar sürüm sürüm değişir. Yeni kampanya modülü, yeni analitik aracı, yeni ödeme entegrasyonu veya yeni AI özelliği veri işleme kapsamını değiştirebilir.
Yayın öncesi kontrol listesi şu başlıkları içermelidir:
Örneğin mesajlaşmalı bir uygulamada bildirim önizlemesi kritik bir detaydır. Kullanıcının kilit ekranında özel mesaj içeriği görünüyorsa bu hem kullanıcı güveni hem de mahremiyet açısından sorun oluşturabilir. Basit bir “Yeni mesajınız var” bildirimi çoğu senaryoda daha güvenli tercihtir.
KVKK uyumunda hatalar çoğu zaman kötü niyetten değil, ürün ve teknik ekiplerin konuyu geç ele almasından kaynaklanır. Proje yayın tarihine yaklaşınca metinler eklenir, fakat veri mimarisi çoktan şekillenmiştir.
En sık görülen hatalar şunlardır:
| Hata | Neden Riskli? | Daha Doğru Yaklaşım |
|---|---|---|
| Tüm izinleri tek checkbox ile almak | Rıza özgür ve belirli olmayabilir | Ayrı amaçlar için ayrı seçim |
| Gereksiz veri istemek | Veri minimizasyonuna aykırı risk doğurur | Zorunlu/opsiyonel alan ayrımı |
| Adminlere tam erişim vermek | İç ihlal riskini artırır | Rol ve departman bazlı yetki |
| Loglarda kişisel veri tutmak | Hata kayıtları veri sızıntısına dönüşebilir | Maskeleme ve log politikası |
| Public dosya URL kullanmak | Belgeler tahmin edilebilir veya paylaşılabilir | İmzalı URL ve erişim kontrolü |
| Silme talebini plansız bırakmak | Kullanıcı hakkı yönetilemez | Silme/anomimleştirme akışı |
| Üçüncü tarafları incelememek | Veri aktarımı belirsiz kalır | Entegrasyon bazlı veri analizi |
Bu hatalar özellikle hızlı büyüyen ürünlerde daha görünür hale gelir. İlk 1.000 kullanıcıda fark edilmeyen bir mimari açık, 100.000 kullanıcıda operasyonel ve hukuki probleme dönüşebilir.
Atalay Tech’in mobil uygulama, web platformu, AI entegrasyonu ve yönetim paneli projelerinde benimsediği yaklaşım, KVKK’yı yalnızca “metin ekleme işi” olarak görmemektir. Ürün fikri netleşirken veri akışı çıkarılır, tasarımda izin ve bilgilendirme noktaları belirlenir, backend tarafında rol bazlı erişim ve güvenli API yapısı kurgulanır.
Bu yaklaşım özellikle şu proje türlerinde kritik hale gelir:
KVKK uyumu için hukuk danışmanı, ürün sahibi ve yazılım ekibi birlikte çalışmalıdır. Hukuk metni doğru olsa bile ürün ekranı yanlış kurgulanmışsa kullanıcı neye onay verdiğini anlamaz. Teknik mimari doğru olsa bile saklama süresi ve veri işleme amacı belirsizse uyum eksik kalır.
KVKK uyumlu mobil uygulama geliştirme sürecinde yalnızca blog yazıları veya genel tavsiyelerle ilerlemek yeterli değildir. Resmi kurum sayfaları, güvenlik standartları ve sektör araştırmaları birlikte değerlendirilmelidir.
Başlangıç için yararlanılabilecek otoriter kaynaklar:
Cisco’nun 2026 Data Privacy Benchmark Study çalışması 12 pazardan 5.200’den fazla teknoloji, güvenlik ve gizlilik profesyonelinin katılımıyla hazırlanmıştır. Bu tür araştırmalar gizlilik yatırımının yalnızca uyum değil, güven ve iş sürekliliği meselesi olduğunu gösterir.
KVKK uyumlu mobil uygulama geliştirme sürecinde hukuk danışmanı güçlü şekilde önerilir; çünkü veri işleme amacı, hukuki sebep, açık rıza ihtiyacı, saklama süresi ve veri aktarımı gibi konular teknik ekibin tek başına karar vermesi gereken başlıklar değildir. Yazılım ekibi uygulamanın veri mimarisini, API güvenliğini, rol bazlı erişimini ve kullanıcı hakları akışını kurar. Hukuk tarafı ise bu akışların mevzuatla uyumlu çerçevesini belirler. En sağlıklı model, hukuk danışmanı ile ürün ve yazılım ekibinin keşif aşamasından itibaren birlikte çalışmasıdır.
Hayır. Aydınlatma metni kullanıcıyı bilgilendirmek için gereklidir, fakat tek başına yeterli değildir. Kullanıcıdan hangi verinin neden alındığı, hangi işlemlerde açık rıza gerektiği, rızanın nasıl geri alınacağı, hesabın nasıl silineceği, verilerin hangi sistemlerde saklandığı ve kimlerin erişebildiği de tasarlanmalıdır. Örneğin pazarlama bildirimi için ayrı onay alınmadan sadece genel üyelik metnine dayanmak risk oluşturabilir. KVKK uyumlu uygulama; metin, arayüz, backend, admin panel, loglama ve bakım süreçlerinin birlikte doğru çalışmasıyla oluşur.
Konum verisi mobil uygulamalarda dikkatli ele alınması gereken veri türlerinden biridir. Yakındaki restoranları, etkinlikleri, şubeleri veya saha ekiplerini göstermek için konum kullanılabilir; fakat kullanıcının konumu sürekli izleniyorsa risk seviyesi artar. Uygulama yalnızca işlem anında konum istiyorsa izin ekranı ve amaç açıklaması net olmalıdır. Sürekli arka plan konumu gerekiyorsa amaç, süre, saklama politikası ve kullanıcı kontrolü daha sıkı tasarlanmalıdır. Kullanıcı konum izni vermediğinde temel uygulama deneyiminin mümkün olduğunca çalışması da iyi bir ürün yaklaşımıdır.
Başlangıçta küçük bir analiz ve tasarım maliyeti ekleyebilir; fakat uzun vadede projeyi ucuzlatabilir. Çünkü doğru KVKK planı gereksiz veri alanlarını, fazla karmaşık admin yetkilerini, sonradan yapılacak silme/anomimleştirme revizyonlarını ve güvenlik açıklarını azaltır. En pahalı senaryo, uygulama yayına çıktıktan sonra veri mimarisinin yanlış kurulduğunu fark etmektir. Bu durumda veri tabanı, API, panel, log sistemi ve kullanıcı arayüzü yeniden düzenlenebilir. KVKK uyumunu ilk sprintten itibaren düşünmek hem teknik borcu hem de operasyonel riski azaltır.
Evet, push bildirimleri özellikle içerik ve pazarlama amacı açısından değerlendirilmelidir. İşlemsel bildirimler, örneğin “siparişiniz hazırlanıyor” veya “randevunuz yaklaşıyor” gibi kullanıcı hizmetiyle bağlantılı olabilir. Pazarlama bildirimleri ise farklı bir onay ve tercih yönetimi gerektirebilir. Ayrıca bildirim içeriğinde hassas bilgi göstermemek önemlidir. Mesajlaşma uygulamasında “Ahmet size yeni mesaj gönderdi” ile mesajın tamamını kilit ekranında göstermek aynı risk seviyesinde değildir. Kullanıcıya bildirim tercihlerini yönetebileceği bir ekran sunmak iyi bir uygulamadır.
Hesap silme veya veri silme talebi yönetimi KVKK açısından önemlidir, fakat her veri aynı anda tamamen silinmeyebilir. Örneğin e-ticaret uygulamasında kullanıcının hesabı kapatılsa bile fatura, sipariş ve finansal kayıtlar yasal saklama yükümlülükleri nedeniyle belirli süre korunabilir. Bu nedenle teknik sistemde “hesabı sil” butonu yalnızca veriyi fiziksel olarak kaldırmak şeklinde kurgulanmamalıdır. Kişisel verilerin silinmesi, anonimleştirilmesi, pasifleştirilmesi veya yasal saklama kapsamına alınması ayrı kurallarla yönetilmelidir. Kullanıcıya bu süreç açık ve anlaşılır şekilde anlatılmalıdır.
Evet. Mobil uygulamada kullanılan analitik, bildirim, harita, ödeme, canlı destek, hata izleme, dosya depolama ve yapay zekâ servisleri kişisel veri aktarımı açısından değerlendirilmelidir. Örneğin hata izleme aracına kullanıcı e-postası, cihaz bilgisi veya ekran görüntüsü gidiyorsa bu veri işleme zincirine dahil olur. Aynı şekilde ödeme servisleri, SMS sağlayıcıları ve harita servisleri de veri akışında yer alabilir. Bu nedenle entegrasyon listesi proje başında çıkarılmalı, hangi servise hangi verinin aktarıldığı belgelenmeli ve gerekli sözleşmesel/teknik tedbirler değerlendirilmelidir.
Evet. App Store ve Google Play uygulama yayın sürecinde gizlilik politikası bağlantısı, veri toplama beyanları, izin açıklamaları ve hesap silme gibi alanlar önemlidir. Uygulama kamera, konum, mikrofon, rehber, fotoğraf galerisi veya bildirim izni istiyorsa bu izinlerin neden kullanıldığı açıkça belirtilmelidir. Mağaza tarafındaki açıklama ile uygulamanın gerçek davranışı çelişmemelidir. Örneğin uygulama konum verisi topluyor fakat mağaza beyanında bunu belirtmiyorsa yayın veya güncelleme sürecinde sorun yaşanabilir. KVKK uyumlu teknik plan, mağaza uyumunu da kolaylaştırır.
Mobil uygulamada teknik borç; hızlı teslim, eksik test, zayıf mimari ve plansız bakım yüzünden uygulamanın zamanla pahalı, kırılgan ve yavaş geliştirilir hale gelmesidir. Bu rehber; teknik borcu önlemek için mimari, test, sürümleme, bakım ve maliyet kararlarını somut örneklerle açıklar.
Mobil uygulama güncelleme süreci yalnızca yeni sürüm yüklemek değildir. Kapsam analizi, sürüm notu, test, mağaza onayı, kademeli dağıtım, hata takibi ve bakım planı birlikte yönetildiğinde uygulama daha stabil, güvenli ve sürdürülebilir olur.
Mobil uygulama bakım ve destek süreci; yayındaki bir uygulamanın güvenli, hızlı, güncel ve kullanıcı beklentilerine uygun kalmasını sağlar. Bu rehberde bakım kapsamını, destek seviyelerini, maliyet aralıklarını, mağaza uyumluluğunu, güvenlik kontrollerini ve Atalay Tech'in proje sonrası yaklaşımını pratik örneklerle in
