Süper Uygulama (Super App) Nedir? Türkiye ve Dünya Örnekleri

İçindekiler

• Süper Uygulama Nedir, Klasik Uygulamadan Nasıl Ayrılır?
• Mini Uygulama Mimarisi Nasıl Çalışır?
• Dünyadan Süper Uygulama Örnekleri: WeChat, Grab, Gojek
• Türkiye'de Süper Uygulama Manzarası
• Tek Uygulamada Çoklu Hizmet Ne Zaman Mantıklı?
• Modüler Geliştirme: Süper Uygulamaya Giden Yol
• Platform Kuralları: Apple ve Google Mini Uygulamalara Ne Diyor?
• Riskler: Güvenlik, Veri Yoğunlaşması ve Bakım Yükü
• Sıkça Sorulan Sorular

Süper uygulama (super app), kullanıcıya tek bir uygulama içinde birbirinden bağımsız birden fazla hizmeti — mesajlaşma, ödeme, ulaşım, yemek, alışveriş — çoğu zaman "mini uygulama" adı verilen modüller aracılığıyla sunan platformdur. Dünyanın en büyük örneği WeChat, 1,43 milyar birleşik aylık aktif kullanıcıya ulaştı.

Kavramın cazibesi basit bir aritmetikten geliyor: yeni bir uygulama indirtmek pahalı, var olan bir uygulamaya yeni bir hizmet eklemek ise görece ucuz. Bu yüzden son on yılda Asya'nın en büyük dijital şirketleri tek bir simgenin arkasında onlarca hizmet topladı.

Ama bu modelin Türkiye'deki bir KOBİ için anlamı, Tencent'in ya da Grab'in anlamıyla aynı değil. Bu yazı önce süper uygulamanın ne olduğunu ve mini uygulama mimarisinin teknik olarak nasıl çalıştığını anlatıyor; ardından "biz de her şeyi tek uygulamada toplasak mı?" sorusuna karar verirken bakmanız gereken kriterleri sıralıyor. Mobil tarafta henüz hiç ürününüz yoksa, önce mobil uygulama nasıl yapılır yazısındaki temel süreci okumanızı öneririz; bu yazı bir adım sonrasını, platformlaşmayı konu alıyor.

Süper Uygulama Nedir, Klasik Uygulamadan Nasıl Ayrılır?

Klasik bir mobil uygulama tek bir işi yapar: bankacılık, kargo takibi, yemek siparişi. Süper uygulama ise kendi çekirdek işini yaparken aynı zamanda başka hizmetleri barındıran bir platform hâline gelir. Ayrımın özü teknik değil ticari: bu modelde hizmetlerin bir kısmını siz değil, üçüncü taraflar geliştirir.

Tanımın en net hâli beklenmedik bir yerde, borsa dosyalarında duruyor. Güneydoğu Asya'nın en büyük platformlarından Grab, ABD Menkul Kıymetler ve Borsa Komisyonu'na sunduğu 2025 yıllık raporunda "superapp" terimini şöyle tanımlıyor: tek bir teknoloji platformu ve üçüncü taraf entegrasyonları üzerinden çok sayıda hizmet sunmayı amaçlayan, birçok uygulamanın bütünleşmiş hâli olan mobil uygulama.

Araştırma şirketi Gartner de benzer bir çerçeve kuruyor: süper uygulama, çekirdek özelliklerin yanında bağımsız olarak geliştirilmiş mini uygulamalara erişim veren bir ön yüz platformudur. Gartner'ın sık alıntılanan öngörüsüne göre 2027'ye kadar dünya nüfusunun yarısından fazlası birden fazla süper uygulamanın günlük aktif kullanıcısı olacak.

Aşağıdaki tablo iki modeli karşılaştırıyor.

Pazar tarafında beklenti yüksek. Araştırma şirketi IMARC'ın süper uygulama pazarı analizine göre pazar 2025'te 114,2 milyar dolar büyüklüğündeydi ve 2034'e kadar 595,8 milyar dolara ulaşması, yıllık ortalama %20,15 büyümesi bekleniyor. Aynı analize göre 2025'te pazarın %46,8'i Asya-Pasifik bölgesine ait — yani model hâlâ doğduğu coğrafyada güçlü.

Mini Uygulama Mimarisi Nasıl Çalışır?

Süper uygulamayı "içinde çok sayfa olan büyük uygulama" sanmak en yaygın hata. Teknik olarak olay şu: ana uygulama bir host (barındırıcı) rolüne geçer, hizmetler ise ayrı paketler hâlinde bu hostun içinde çalışır.

W3C'nin MiniApp beyaz kâğıdı süper uygulamayı "diğer uygulamaları (yani MiniApp'leri) barındıran ve platformun kaynaklarını kullanarak çalıştırılmalarını sağlayan yazılım platformu" olarak tanımlıyor. Aynı dokümana göre bir mini uygulama, kök dizininde yapılandırma dosyası, yaşam döngüsü mantığını taşıyan bir uygulama dosyası, sayfa şablonları, CSS ve JavaScript içeren sıkıştırılmış bir arşiv olarak dağıtılır ve bütünlük doğrulaması için dijital imza desteklenir.

Google'ın mini uygulamalar dokümantasyonu pratik tarafı anlatıyor: mini uygulamalar HTML, CSS ve JavaScript'in birer lehçesiyle yazılır, tipik olarak 2-4 MB boyutundadır, işletim sistemi yerine süper uygulamanın içindeki bir WebView'da çalışır ve geliştiricinin kendi sunucusundan değil süper uygulama sağlayıcısından şifreli paket olarak sunulur. Cihaz API'lerine erişim bir JavaScript köprüsü üzerinden verilir. Keşif yolu da farklı: mini uygulamalar genellikle markalı iki boyutlu barkodlarla, uygulama içi aramayla veya sohbet içinde paylaşımla bulunur.

Bu mimarinin bugün en kolay incelenebilen örneği Telegram. Telegram Mini Apps dokümantasyonuna göre geliştirici tek bir telegram-web-app.js dosyasını sayfaya ekler, karşılığında window.Telegram.WebApp nesnesi açılır ve host; tema bilgisi, güvenli alan boşlukları, alt butonlar, geri butonu, ivmeölçer, jiroskop, konum ve biyometrik doğrulama gibi yetenekleri bu nesne üzerinden sunar. Sınırlar da net: kullanıcı başına bulut depolamada 1.024 kayıt, cihaz depolamasında 5 MB, güvenli depolamada 10 kayıt ve bota gönderilen veride 4.096 bayt.

Buradan çıkan üç pratik sonuç var:

• Mini uygulama bir web uygulamasıdır, ama sıradan bir web sayfası değildir; paketlenir, imzalanır, host tarafından denetlenir ve hostun verdiği API'lerle sınırlıdır.
• Host kadar yetenekli olursunuz. Hostun açmadığı bir cihaz özelliğine mini uygulamadan ulaşamazsınız.
• Yayın döngüsü ikiye ayrılır. Çekirdek uygulama mağaza sürecine tabidir, mini uygulamalar ise host politikası çerçevesinde mağaza beklemeden güncellenebilir.

Benzer bir mantığı mağazadan bağımsız dağıtım tarafında da görürsünüz; PWA nedir yazısında web teknolojileriyle uygulama benzeri deneyim kurmanın diğer yolunu ele almıştık.

Dünyadan Süper Uygulama Örnekleri: WeChat, Grab, Gojek

Üç örnek, üç farklı başlangıç noktası gösteriyor: mesajlaşma, ulaşım ve kurye.

WeChat (Tencent, Çin) mesajlaşmadan başladı. Tencent'in 2026 birinci çeyrek sonuç açıklamasına göre Weixin ve WeChat'in birleşik aylık aktif kullanıcı sayısı 31 Mart 2026 itibarıyla 1.432 milyon oldu; bir yıl önce 1.402 milyondu. Aynı açıklamada reklam gelirlerinin mini oyun, mini dizi ve "Mini Shop" reklamverenleriyle büyüdüğü, Mini Shop'ların işlem hacminde hızlı yıllık büyümeyi sürdürdüğü belirtiliyor. Yani mini uygulama ekosistemi artık tek başına bir reklam ve ticaret kanalı.

Grab (Güneydoğu Asya) araç çağırmadan başladı, yemek ve market teslimatı, ödeme, finansal hizmetlerle genişledi. Yıllık raporundaki rakamlara göre aylık işlem yapan kullanıcı sayısı 2023'te 35,5 milyon, 2024'te 41,3 milyon, 2025'te 47,2 milyon oldu. Buradaki metrik seçimi önemli: Grab indirme değil, "ay içinde fiilen işlem yapan tekil kullanıcı" sayısını raporluyor.

Gojek (GoTo Group, Endonezya) motosikletli kurye çağrı merkezi olarak doğdu. GoTo'nun 2025 dördüncü çeyrek ve yıl sonu sonuçlarına göre grubun çekirdek brüt işlem hacmi 2025'te %49 artarak 400 trilyon rupiye, yıllık işlem yapan kullanıcı sayısı %24 artarak 66 milyona ulaştı; finansal teknoloji kolunun aylık işlem yapan kullanıcı sayısı dördüncü çeyrekte 26,2 milyon oldu.

Ölçek tarafında mini uygulama ekosistemlerinin büyüklüğünü W3C dokümanı da örnekliyor: Alipay Mini Program platformunda bir milyonun üzerinde mini program ve 230 milyon günlük aktif kullanıcı, Baidu'nun akıllı mini program platformunda 150 binin üzerinde mini program ve 270 milyon aylık aktif kullanıcı bildiriliyor.

Dikkat çeken ortak nokta: üçünde de platformlaşma bir strateji sonucu değil, yüksek frekanslı bir çekirdek hizmetin sonucu. Günde birden fazla kez açılan bir uygulamanız varsa yanına hizmet eklemek mantıklı; haftada bir açılan bir uygulamaya on hizmet eklemek onu platform yapmaz.

Türkiye'de Süper Uygulama Manzarası

Türkiye, bu model için altyapı açısından hazır bir pazar. TÜİK'in 2025 Hanehalkı Bilişim Teknolojileri Kullanım Araştırması sonuçlarına göre 16-74 yaş grubunda internet kullanım oranı 2024'teki %88,8'den 2025'te %90,9'a çıktı; internetten alışveriş ya da sipariş verenlerin oranı ise %51,7'den %55,7'ye yükseldi.

Finansal taraf daha da yoğun. Türkiye Bankalar Birliği'nin Aralık 2025 verilerine göre aktif dijital bankacılık müşteri sayısı 127,7 milyonu, aktif mobil bankacılık müşteri sayısı ise 126,6 milyonu aştı; yılın son çeyreğinde mobil bankacılıkta 2,76 milyar işlem gerçekleşti. Türkiye'de banka uygulamaları çoktan birer platform adayı: para transferinin yanında fatura ödeme, yatırım, sigorta, kampanya ve sadakat programları aynı ekranda toplanıyor.

Ticaret tarafında Trendyol, pazaryeri çekirdeğinin üzerine market ve yemek teslimatı (Trendyol Go), ikinci el (Dolap) ve ödeme (Trendyol Pay) katmanlarını ekleyerek yerli örneklerin en belirginini oluşturdu. Teslimat tarafında ise konsolidasyon hızlandı: Uber, Getir'in yemek, hızlı market, çarşı ve su teslimat işlerini devralmak üzere anlaştı ve Rekabet Kurulu bu devralmaya 2026 Haziran'ında onay verdi.

KOBİ ölçeğinde çıkarılacak ders şu: Türkiye'de bu yarış yüksek frekanslı üç dikeyde (bankacılık, pazaryeri, teslimat) ve sermaye yoğun biçimde oynanıyor. Buraya dördüncü bir genel amaçlı süper uygulamayla girmek gerçekçi değil. Gerçekçi olan, kendi müşteri tabanınız için dar kapsamlı bir süper uygulama kurmak: bir yapı market zincirinin müşteri uygulamasında sipariş, teslimat takibi, ustabulma ve garanti kaydının toplanması gibi.

Tek Uygulamada Çoklu Hizmet Ne Zaman Mantıklı?

Karar üç soruya indirgenebilir: kullanıcı aynı mı, frekans yeterli mi, hizmetler birbirini besliyor mu? Aşağıdaki matris bu soruları somutlaştırıyor.

Kararı zorlaştıran asıl kalem maliyet değil, bakım ve ürün yönetimi yükü. Tek uygulamada dört hizmet taşımak, dört ayrı backlog'u tek sürüm takvimine sığdırmak demektir. Bir modülün gecikmesi diğer üçünün yayınını bloke ediyorsa mimariniz platform değil, büyük bir monolit.

Frekans eşiğini somutlaştırmak için basit bir ölçüt kullanabilirsiniz: aylık aktif kullanıcılarınızın gün içinde uygulamayı kaç kez açtığına bakın. Günlük aktif kullanıcı sayısının aylık aktif kullanıcıya oranı (DAU/MAU) %20'nin altındaysa, kullanıcı haftada bir buçuk günden az geliyor demektir; bu tabanda ikinci bir hizmetin kendini duyurma şansı düşüktür. Oran %40'ın üzerindeyse çapraz kullanım gerçekçi hâle gelir. Grab ve GoTo'nun raporlarında indirme yerine "ay içinde işlem yapan tekil kullanıcı" metriğini öne çıkarmasının nedeni de bu: platformlaşma kararı kurulum sayısıyla değil, fiili kullanım sıklığıyla verilir. Ölçümü modül bazında kırmazsanız hangi hizmetin diğerini beslediğini de göremezsiniz.

İkinci tuzak: menüye hizmet eklemek hizmet kullandırmak değil. Her yeni modül ana ekranda yer, onboarding'de adım ve ayarlarda izin ister. Dört hizmeti sıkıştırdığınız ana ekran, çekirdek hizmetin dönüşüm oranını düşürüyorsa kazanç net değil. Bu yüzden her modülün kendi başına ölçülmesi gerekir; mobil uygulama analitiği yazısındaki olay tabanlı ölçüm kurulumu burada zorunlu hâle gelir.

Modüler Geliştirme: Süper Uygulamaya Giden Yol

Pratikte hiçbir ekip birinci günde çok hizmetli bir platform yazmaz. Yol şöyle işler: önce tek hizmetle ürün-pazar uyumu, sonra modüler mimariye geçiş, en sonunda üçüncü taraflara açılma.

Aşama 1 — Tek hizmet, net çekirdek. Hedef, bir işi günde birden fazla açılacak kadar iyi yapmak. Bu aşamada kapsamı kasıtlı olarak daraltmak için MVP (minimum uygulanabilir ürün) yaklaşımı uygundur.

Aşama 2 — İç modülerlik. Kod tabanını özellik alanlarına bölün: her modülün kendi ekranları, kendi durum yönetimi, kendi API sözleşmesi olsun. Hedef, bir modülü diğerlerine dokunmadan değiştirebilmek. Web tarafında bu yaklaşımın olgun aracı Module Federation; mobil tarafta da çalışma zamanında modül yükleyen benzer kurgular kullanılıyor.

Aşama 3 — Ortak altyapı katmanı. Kimlik doğrulama, ödeme, bildirim, izin yönetimi ve analitik tek bir çekirdekte toplanır. Modüller bu çekirdeği tüketir. Bu katman doğru kurulmazsa her yeni hizmet kendi giriş ekranını ve kendi ödeme akışını getirir — kullanıcı için en can sıkıcı sonuç budur.

Aşama 4 — Üçüncü taraflara açılma. Mini uygulama platformu kurmak; SDK, denetim süreci, gelir paylaşımı ve destek demektir. Buraya yalnızca talebi kanıtlanmış ekipler girer. Hazırlık adımı neredeyse her zaman bir API stratejisidir; API entegrasyonu yazısı bu sözleşmelerin nasıl kurulacağını anlatıyor.

Bütçe tarafında modüler geliştirme ilk aşamada tek hizmetli bir uygulamadan belirgin biçimde pahalı değildir; fark, her yeni modülün marjinal maliyetinde ortaya çıkar. Kendi kapsamınız için kaba bir bant görmek isterseniz mobil uygulama maliyet hesaplayıcı aracını kullanabilirsiniz. Modüllerin gelir modeli kurgusu için de mobil uygulamadan para kazanma yazısındaki seçenekler işe yarar.

Platform Kuralları: Apple ve Google Mini Uygulamalara Ne Diyor?

Platform planlarının en sık atlanan maddesi mağaza kuralları. Apple'ın App Review Guidelines dokümanında bu konu doğrudan 4.7 maddesinde düzenlenmiş. Özetle uygulamalar, binary'nin içine gömülü olmayan HTML5 ve JavaScript mini uygulamalarını ve mini oyunlarını sunabilir; ancak sunulan tüm yazılımdan geliştirici sorumludur ve kurallara uymayan içerik uygulamanın tamamının reddine yol açar. Alt maddeler şunları şart koşuyor:

• Mini uygulamalar gizlilik kurallarına uymak, uygunsuz içeriği filtreleme yöntemi, içerik bildirme mekanizması ve kullanıcı engelleme yeteneği içermek zorunda (4.7.1).
• Dijital mal ve hizmet satışı 3.1 maddesine, yani uygulama içi satın alma kuralına tabi (4.7.1).
• Apple'ın önceden izni olmadan native platform API'lerini mini uygulamalara açamazsınız (4.7.2).
• Her bir mini uygulamaya veri veya gizlilik izni aktarmak için her durumda açık kullanıcı onayı gerekir (4.7.3).
• Uygulamanızda sunulan tüm yazılımın bir dizinini ve bunlara giden universal link'leri sağlamak zorundasınız (4.7.4).
• Uygulamanın yaş sınıflandırmasını aşan içeriği kullanıcıya belli etmek ve yaş kısıtlaması uygulamak gerekir (4.7.5).

Android tarafında kritik sınır çalışma zamanında kod indirmeyle ilgili: Google Play politikası, uygulamaların Play dışı bir kaynaktan çalıştırılabilir kod (dex, JAR, .so) indirmesini yasaklar; ancak bu kısıtlama sanal makinede çalışan ve Android API'lerine erişimi sınırlı olan kodu — örneğin WebView içindeki JavaScript'i — kapsamaz. Mini uygulama mimarilerinin web teknolojileri üzerine kurulmasının bir nedeni de budur.

Pratik çıkarım: mini uygulama platformu kurmak teknik bir tercih olduğu kadar uyum (compliance) işi. Dizin tutma, içerik denetimi, yaş kısıtı, izin onayı ve ödeme akışı kuralları ürün planına baştan girmezse ilk mağaza incelemesinde takılırsınız. Reddedilme nedenlerinin listesi için App Store uygulama reddi yazısına bakabilirsiniz.

Riskler: Güvenlik, Veri Yoğunlaşması ve Bakım Yükü

Çok hizmetli bir uygulama, saldırı yüzeyini de birleştirir. Yuqing Yang, Chao Wang, Yue Zhang ve Zhiqiang Lin'in süper uygulama güvenliği üzerine sistematik inceleme çalışması, bu platformları "işletim sistemi benzeri" yapılar olarak ele alıyor ve platformlarda 13 güvenlik mekanizması ile 10 güvenlik tehdidi tanımlıyor. Çalışmanın kök neden analizine göre güvenlik varsayımları üç yerde kırılıyor: alttaki sistemlerdeki sorunlar, izolasyonun uygulanış biçimi ve denetim (vetting) süreci.

Bu akademik sonucu ürün diline çevirelim:

• İzolasyon kâğıt üstünde kalabilir. Mini uygulamaların birbirinin verisine ve hostun ayrıcalıklı API'lerine erişemediğini test etmeniz gerekir; varsaymak yetmez.
• Veri yoğunlaşması ihlalin etkisini büyütür. Ödeme, konum, sağlık ve iletişim verisi aynı çatıda toplandığında tek bir açık, hepsini birden açar. KVKK uyumu açısından veri minimizasyonu ve amaç sınırlaması bu mimaride daha zordur; web sitesi KVKK uyumu yazısındaki aydınlatma ve rıza mantığı mobil tarafta modül modül kurulmalıdır.
• Denetim bir süreç, bir kere yapılan iş değil. Üçüncü taraf modülleri kabul ediyorsanız sürekli bir inceleme ve yaptırım hattı kurmanız gerekir.
• Bakım yükü üst üste biner. Her modülün kendi bağımlılıkları, kendi SDK güncellemeleri ve kendi kırılma noktaları olur; yıllık bakım bütçesi tek hizmetli uygulamadan farklı planlanır.

Regülasyon tarafı da bu modele yaklaşıyor. Birleşik Krallık rekabet otoritesinin mobil ekosistemler piyasa çalışması büyük platformların kapı bekçisi konumunu incelerken, benzer tartışmalar uygulama içi uygulama barındıran yapılar için de sürüyor. Tek uygulamada çok hizmet toplamak, kullanıcıyı kilitleme ve geçiş maliyeti tartışmalarını da beraberinde getirir.

Güvenlik tarafını baştan kurmak isteyen ekipler için mobil uygulama güvenliği yazısındaki kontrol listesi, modüler mimariye geçmeden önce kapatılması gereken temel maddeleri sıralıyor.

Sıkça Sorulan Sorular

Süper uygulama ile normal uygulama arasındaki fark nedir?

Normal uygulama tek bir işi yapar ve tüm kodu tek ekip geliştirir. Süper uygulama ise çekirdek hizmetinin yanında başka hizmetleri mini uygulama olarak barındıran bir platformdur; hizmetlerin bir kısmını üçüncü taraflar geliştirir ve bağımsız olarak yayınlanır.

Mini uygulama nedir, nasıl geliştirilir?

Mini uygulama, bir süper uygulamanın içinde çalışan küçük bir web uygulamasıdır. HTML, CSS ve JavaScript lehçeleriyle yazılır, tipik olarak 2-4 MB boyutundadır ve işletim sistemi yerine hostun WebView'ında çalışır. Cihaz özelliklerine erişim, hostun sunduğu JavaScript köprüsüyle sınırlıdır.

Türkiye'de süper uygulama örnekleri hangileri?

En belirgin örnekler yüksek frekanslı dikeylerde: pazaryeri çekirdeğine teslimat, ikinci el ve ödeme katmanlarını ekleyen Trendyol; para transferinin yanında fatura, yatırım ve sigorta işlemlerini toplayan banka uygulamaları; teslimat tarafında birleşen Getir ve Uber ekosistemi. Üçü de sermaye yoğun ve geniş kullanıcı tabanlı yapılar.

KOBİ'nin süper uygulama yapması mantıklı mı?

Genel amaçlı bir süper uygulama kurmak KOBİ ölçeğinde gerçekçi değildir. Mantıklı olan, mevcut müşteri tabanınız için dar kapsamlı bir çoklu hizmet uygulaması kurmaktır: sipariş, teslimat takibi, destek ve sadakat gibi birbirini besleyen üç-dört modül. Ölçüt, uygulamanın günde en az bir kez açılıyor olmasıdır.

Süper uygulama geliştirmek ne kadar sürer?

Tek hizmetli bir çekirdeği yayına almak tipik olarak aylarla ölçülür; modüler mimariye geçiş ve ikinci hizmetin eklenmesi ise ayrı bir faz olarak planlanır. Üçüncü taraflara açık bir mini uygulama platformu kurmak SDK, denetim süreci ve gelir paylaşımı gerektirdiği için çok daha uzun soluklu bir yatırımdır.

Apple ve Google mini uygulamalara izin veriyor mu?

Evet, ancak koşullu. Apple'ın App Review Guidelines 4.7 maddesi HTML5 ve JavaScript mini uygulamalarına izin verirken dizin tutma, içerik denetimi, yaş kısıtı, izin onayı ve uygulama içi satın alma kurallarını şart koşuyor. Google Play ise Play dışından çalıştırılabilir kod indirilmesini yasaklıyor; WebView içinde çalışan JavaScript bu kapsamın dışında.

Süper uygulamanın en büyük riski nedir?

Veri ve güvenlik yoğunlaşması. Ödeme, konum ve iletişim verisi aynı uygulamada toplandığında tek bir güvenlik açığı hepsini birden etkiler. Akademik literatür, modüller arası izolasyonun uygulanış biçimini ve üçüncü taraf denetimini bu modeldeki en kırılgan iki nokta olarak işaret ediyor.

Süper uygulama bir mimari hedef değil, yüksek frekanslı bir çekirdek hizmetin doğal sonucudur. Önce günde birden fazla açılan tek bir hizmet kurun, kod tabanını modüllere ayırın, kimlik ve ödeme gibi ortak katmanları tek yerde toplayın. Ancak bu üç adım sağlamsa dördüncü adımı, yani başka hizmetleri barındırmayı tartışmaya değer.

Mevcut uygulamanızı modüler bir yapıya taşımayı ya da sıfırdan çok hizmetli bir ürün kurmayı değerlendiriyorsanız, kapsamınızı birlikte ölçeklendirebiliriz. Mobil uygulama geliştirme hizmetimiz kapsamında mimari kararlarınızı konuşmak için bize ulaşın.