TestFlight Kullanıcı Limitleri Nasıl Aşılır?

TestFlight Kullanıcı Limitleri Nasıl Aşılır?

iOS uygulamanızın TestFlight kullanıcı limitine takılmadan daha geniş kitlelere ulaşması için uygulayabileceğiniz teknik ve stratejik çözüm yollarını keşfedin.

Mobil uygulama geliştirme sürecinde, kullanıcı geri bildirimleri ürünün başarısını belirleyen en kritik unsurlar arasında yer alır. Apple ekosisteminde yeni bir iOS uygulamasını veya mevcut bir sürümün güncellenmiş halini test etmek istediğimizde ilk başvurduğumuz resmi araç kuşkusuz TestFlight platformudur. Ancak uygulamanız hızla büyümeye başladığında veya geniş çaplı bir kapalı beta testi gerçekleştirmek istediğinizde Apple’ın koyduğu sınırlar ciddi bir engel haline gelebilir. Özellikle Türkiye’deki hızlı büyüyen teknoloji girişimleri ve yüksek kullanıcı trafiğine sahip e-ticaret platformları, bu limitlere oldukça kısa sürede ulaşmaktadır.

Peki, uygulamanızı binlerce farklı kullanıcıya ulaştırmak istediğinizde karşınıza çıkan bu duvarları nasıl aşabilirsiniz? Bu makalede, TestFlight sınırlarının mantığını detaylıca inceleyecek, mimari seviyede uygulayabileceğiniz teknik çözümleri ele alacak ve alternatif dağıtım kanalları ile test süreçlerinizi nasıl kesintisiz sürdürebileceğinizi adım adım öğreneceğiz.

TestFlight Sınırları Nedir ve Neden Karşımıza Çıkar?

Apple, platform güvenliğini ve kullanıcı deneyimini korumak amacıyla TestFlight üzerinden yapılan test dağıtımlarına belirli sınırlamalar getirir. Konuyu tam anlamıyla kavrayabilmek için öncelikle bu sınırların kategorilerini ve çalışma prensiplerini iyi analiz etmemiz gerekir. TestFlight içerisindeki test kullanıcıları temel olarak iki ana gruba ayrılmaktadır: Dahili Test Kullanıcıları (Internal Testers) ve Harici Test Kullanıcıları (External Testers).

Dahili test grubu, App Store Connect hesabınızda “Yönetici”, “Geliştirici” veya “Arayüz Tasarımcısı” gibi rollere sahip olan ekip üyelerinden oluşur. Apple, bu grup için en fazla 100 kullanıcı sınırı belirlemiştir. Bu grubun en büyük avantajı, gönderilen derlemelerin (build) Apple’ın Beta Uygulama İncelemesi (Beta App Review) sürecinden geçme zorunluluğunun olmamasıdır. Yüklediğiniz bir derleme birkaç dakika içinde dahili test kullanıcılarının erişimine açılır.

Harici test grubu ise uygulamanızı gerçek dünya koşullarında test edecek anonim veya davet edilmiş son kullanıcıları temsil eder. Apple, tek bir uygulama için harici test kullanıcısı limitini maksimum 10.000 olarak belirlemiştir. Ayrıca, oluşturacağınız her bir genel bağlantı (public link) için de ayrı bir kota bulunur. Bir derlemenin ömrü ise yüklendiği tarihten itibaren tam 90 gündür. Bu süre dolduğunda derleme otomatik olarak pasif hale gelir ve kullanıcılar uygulamayı açamaz.

Geniş ölçekli bir uygulamada 10.000 kişilik limit ilk bakışta yeterli gibi görünse de kullanıcıların uygulamayı indirip bir kez açtıktan sonra unutması, kullanılmayan hesapların kotayı doldurması ve farklı test senaryolarının eşzamanlı yürütülebilmesi gibi nedenlerle bu sınır hızla dolmaktadır.

Dahili ve Harici Test Grubu Stratejileri Nasıl Yapılandırılır?

TestFlight limitlerini verimli yönetmenin ilk adımı, test gruplarını doğru bir mimariyle segmentlere ayırmaktır. Rastgele davet göndermek yerine kullanıcıları kullanım alışkanlıklarına ve test hedeflerinize göre gruplandırmalısınız. Böylelikle hem 10.000 kişilik harici test sınırını gereksiz yere doldurmazsınız hem de daha nitelikli geri bildirimler toplarsınız.

İlk olarak, harici test grubunuzu tek bir havuz olarak düşünmek yerine alt gruplara (sub-groups) bölün. Örneğin, uygulamanızda aşağıdaki gibi bir yapılandırma kurabilirsiniz:

• Çekirdek Beta Ekibi (VIP Testers): Sürekli geri bildirim veren, uygulamanızı günlük hayatında aktif kullanan 500-1000 kişilik sadık kitle.
• Saha Test Ekibi (Regional Testers): Sadece belirli bölge veya lokasyon bazlı özellikleri test eden geçici kullanıcı grubu.
• Stres ve Performans Ekibi: Yeni bir altyapı değişikliğinde yüksek anlık trafik oluşturmak için kullanılan geniş kitle.

Bu gruplandırmayı yaptıktan sonra, her derlemeyi (build) tüm gruplara aynı anda açmak zorunda kalmazsınız. Sadece ilgili özelliği kapsayan grubu hedefleyerek testleri yürütebilirsiniz. Ayrıca, genel davet bağlantılarını (public links) sınırsız süreliğine açık bırakmak en büyük hatalardan biridir. Genel bağlantılara mutlaka kullanıcı sayısı kotası koymalısınız. Örneğin, 1.000 kişilik bir kota belirleyip dolduğunda bağlantıyı kapatmak, kontrolün sizde kalmasını sağlar.

Pasif Kullanıcıları Otomatik Temizleme ve Rotasyon Yöntemi

TestFlight limitini aşmanın en pratik ve etkili yolu, mevcut 10.000 kişilik kotayı bir “döner sermaye” veya “rotasyon” mantığıyla çalıştırmaktır. Çoğu zaman harici test listesindeki kullanıcıların %40 ila %60’ı uygulamayı yüklemez bile veya sadece bir kez yükleyip bir daha açmaz. Pasif kalan bu kullanıcılar değerli kotalarınızı işgal eder.

Kullanıcı rotasyonu stratejisinde hedefimiz, belirli bir süredir aktif olmayan kullanıcıları tespit edip onları test grubundan çıkarmak ve yerlerine yeni istekte bulunan kullanıcıları dahil etmektir. Apple, App Store Connect üzerinde kullanıcıların en son hangi tarihte test yaptığını ve kaç oturum açtığını gösteren veriler sunar.

Bu süreci manuel olarak yapmak yüzlerce kullanıcı için oldukça zahmetlidir. Bunun yerine App Store Connect API kullanarak bu süreci tamamen otomatize edebilirsiniz. Otomasyon senaryonuz şu adımları izlemelidir:

1. Haftalık olarak App Store Connect API üzerinden test kullanıcılarının listesini ve son etkinlik tarihlerini çekin.
2. Son 14 veya 30 gün boyunca hiçbir derlemeyi yüklememiş veya açmamış kullanıcıları filtreleyin.
3. Bu kullanıcılara otomatik bir uyarı e-postası göndererek test sürecine devam etmek isteyip istemediklerini sorun.
4. Yanıt vermeyen veya pasif kalmaya devam eden hesapları API aracılığıyla harici test grubundan silin.

Bu dinamik temizlik yöntemi sayesinde 10.000 kişilik kapasiteniz hiçbir zaman tam anlamıyla atıl kalmaz ve sürekli olarak aktif test yapan taze bir kullanıcı kitlesine sahip olursunuz.

Çoklu Uygulama Kimliği (Bundle ID) ile Limitleri Çarpanlara Ayırma

Eğer uygulamanız tek bir TestFlight hesabındaki 10.000 aktif kullanıcı sınırını tamamen dolduruyorsa ve hiçbir kullanıcıyı gruptan çıkarmak istemiyorsanız, mimari bir çözüme geçmeniz gerekir. Bu çözüm, uygulamanızın farklı ortamlarını (environment) veya sürümlerini bağımsız birer App Store Connect projesi olarak tanımlamaktır.

Normal şartlarda uygulamanızın bir paket kimliği (Bundle Identifier) bulunur; örneğin com.sirket.uygulama. Xcode üzerinde derleme ayarlarını ve şemalarını (schemes) yapılandırarak farklı Bundle ID’lere sahip türev uygulamalar oluşturabilirsiniz:

• com.sirket.uygulama.alpha (Alpha Sürümü)
• com.sirket.uygulama.beta (Beta Sürümü)
• com.sirket.uygulama.staging (Hazırlık Sürümü)

Apple, her farklı Bundle ID’yi tamamen bağımsız bir uygulama olarak değerlendirir. Bu durum, her bir uygulama projesi için ayrı bir 10.000 harici kullanıcı kotasına sahip olacağınız anlamına gelir. Yukarıdaki gibi 3 farklı ortam oluşturduğunuzda, toplam harici test kapasitenizi anında 30.000 kullanıcıya çıkarmış olursunuz.

Bu yöntemi uygularken dikkat edilmesi gereken en önemli nokta, derleme yapılandırmasını (Build Configuration) doğru ayarlamaktır. Aşağıda Xcode projenizde kullanabileceğiniz örnek bir Configuration/Build Settings yaklaşımı yer almaktadır:

// Xcode Build Settings - User-Defined Settings Örneği
PRODUCT_BUNDLE_IDENTIFIER_APP = com.sirket.uygulama
PRODUCT_BUNDLE_IDENTIFIER_BETA = com.sirket.uygulama.beta
PRODUCT_BUNDLE_IDENTIFIER_ALPHA = com.sirket.uygulama.alpha

// Info.plist içerisindeki Bundle Identifier tanımı
// $(PRODUCT_BUNDLE_IDENTIFIER)

Geliştirme ekibiniz CI/CD (Sürekli Entegrasyon / Sürekli Teslimat) süreçlerinde Fastlane veya GitHub Actions kullanıyorsa, hedef ortama göre ilgili şemayı derleyip doğru App Store Connect projesine otomatik olarak yükleyebilir.

TestFlight Alternatifi Dağıtım Kanalları Nelerdir?

TestFlight, Apple’ın sunduğu en entegre çözüm olsa da tek seçenek değildir. Özellikle kapalı beta aşamasından açık alfa süreçlerine geçerken veya şirket içi çok geniş çalışan kitlelerine test yaptırırken alternatif araçları sürece dahil etmek esneklik kazandırır.

Aşağıdaki tabloda, TestFlight ve en popüler alternatif dağıtım kanallarının temel özelliklerini, limitlerini ve kullanım senaryolarını karşılaştırmalı olarak inceleyebilirsiniz:

Firebase App Distribution gibi platformlar, iOS cihazlarının UDID (Benzersiz Cihaz Kimliği) numaralarını toplayarak Ad-Hoc profilleri üzerinden dağıtım yapılmasına imkan tanır. Apple Bireysel veya Kurumsal Geliştirici hesabında yıllık 100 iPhone, 100 iPad ve 100 Apple Watch tanımlama sınırınız vardır. Eğer test kitleniz kurum içi çalışanlardan oluşuyorsa, Apple Developer Enterprise Program (Kurumsal Geliştirici Programı) kullanarak sınırsız sayıda cihaza uygulama yükleyebilirsiniz. Ancak bu lisansın sadece şirket personeline özel olduğunu unutmamalısınız.

Gerçek Dünya Senaryosu: Yerel Bir FinTech Girişiminin Test Otomasyonu

Konuyu somutlaştırmak adına Türkiye pazarında hizmet veren hayali bir FinTech girişiminin (“Parabox”) karşılaştığı krizi ve çözüm yolunu inceleyelim. Parabox, yeni nesil dijital cüzdan özelliğini canlıya almadan önce 25.000 kullanıcılı devasa bir topluluk ile test etmek istedi. Ancak TestFlight’ın 10.000 kişilik harici test engeline takıldılar.

Şirket, kriz anında üç aşamalı bir strateji geliştirdi ve uyguladı:

İlk adım olarak, kullanıcılara uygulama içi ve e-posta üzerinden bir bilgilendirme gönderildi. Test kullanıcıları “Aktif Testçiler” ve “Gözlemciler” olarak ikiye ayrıldı. Son 10 gündür uygulamaya girmeyen 4.200 kullanıcı TestFlight listesinden temizlendi. Böylelikle anında 4.200 kişilik yeni alan açıldı.

İkinci adımda, uygulamanın teknik altyapısı ikiye bölündü. Sadık ve sürekli geri bildirim veren 10.000 kullanıcı com.parabox.app.beta paketi altında toplanırken, sosyal medya üzerinden gelen geçici test kullanıcıları için com.parabox.app.community adında ikinci bir Bundle ID oluşturuldu. Bu sayede kapasite tek gecede 20.000’e çıkarıldı.

Üçüncü ve son adımda ise şirket içi 300 personelin testi için Apple Enterprise lisansı kullanılarak Firebase App Distribution altyapısına geçildi. Böylece kurum içi trafik, dış kullanıcı limitlerinden tamamen izole edildi. Sonuç olarak Parabox, tek bir kullanıcısını dahi dışarıda bırakmadan test sürecini başarıyla tamamladı.

App Store Connect API ve Fastlane ile Otomatik Test Yönetimi

TestFlight süreçlerini manuel olarak yönetmek bir süre sonra sürdürülemez hale gelir. Sürekli gelişen mobil ekipler için Fastlane otomasyon aracı ve App Store Connect API biçilmiş kaftandır. Bu bölümde, pasif kullanıcıları veya derleme süreçlerini otomatize etmek için kullanabileceğiniz teknik yapıları ele alacağız.

Fastlane kullanarak bir test grubuna otomatik olarak yeni bir derleme yüklemek ve kullanıcıları bilgilendirmek son derece basittir. Projenizdeki Fastfile dosyasına aşağıdaki gibi bir lane (görev) ekleyebilirsiniz:

# Fastfile İçeriği
default_platform(:ios)

platform :ios do
  desc "TestFlight Harici Beta Grubuna Otomatik Derleme Gönderir"
  lane :deploy_to_beta do
    build_app(scheme: "AppBeta") # Beta şemasını derler
    
    upload_to_testflight(
      skip_waiting_for_build_processing: true,
      groups: ["Genel Beta Ekibi", "VIP Testers"],
      changelog: "Bu sürümde performans iyileştirmeleri ve hata düzeltmeleri yapıldı."
    )
  end
end

Pasif kullanıcıların tespiti için ise Python ve App Store Connect API entegrasyonu tercih edilebilir. JWT (JSON Web Token) ile kimlik doğrulaması yaptıktan sonra API’nin /v1/betaTesters uç noktasına (endpoint) istek atarak kullanıcı durumlarını sorgulayabilirsiniz. Aşağıdaki Python kod parçacığı, API’ye bağlanıp kullanıcı verilerini nasıl çekebileceğinizi göstermektedir:

import requests
import time
import jwt

# App Store Connect API Anahtar Bilgileri
KEY_ID = 'YOUR_KEY_ID'
ISSUER_ID = 'YOUR_ISSUER_ID'
PRIVATE_KEY_PATH = 'AuthKey_YOUR_KEY_ID.p8'

with open(PRIVATE_KEY_PATH, 'r') as f:
    private_key = f.read()

payload = {
    'iss': ISSUER_ID,
    'exp': int(time.time()) + (20 * 60),
    'aud': 'appstoreconnect-v1'
}

headers = {
    'alg': 'ES256',
    'kid': KEY_ID,
    'typ': 'JWT'
}

# Token Üretimi
token = jwt.encode(payload, private_key, algorithm='ES256', headers=headers)

# Beta Test Kullanıcılarını Getir
api_url = "https://api.appstoreconnect.apple.com/v1/betaTesters"
api_headers = {'Authorization': f'Bearer {token}'}

response = requests.get(api_url, headers=api_headers)

if response.status_code == 200:
    testers = response.json()
    print(f"Toplam Test Kullanıcısı Sayısı: {len(testers.get('data', []))}")
else:
    print(f"Hata Oluştu: {response.status_code} - {response.text}")

Bu tür scriptleri bir Cron Job veya GitHub Actions Workflow içerisine bağlayarak her pazar gecesi pasif kullanıcıların taranmasını ve kotanızın otomatik olarak temizlenmesini sağlayabilirsiniz. Böylece geliştirme ekibiniz zamanını operasyonel işlerle değil, doğrudan kod kalitesiyle harcar.

Sonuç ve Sıkça Sorulan Sorular

TestFlight limitleri, hızlı büyyen mobil projeler için caydırıcı bir engel gibi görünse de doğru strateji ve teknik otomasyonlar ile tamamen kontrol altına alınabilir. Tek bir yönteme bağımlı kalmak yerine; aktif rotasyon mekanizmaları kurmak, çoklu Bundle ID mimarisini benimsemek ve alternatif dağıtım kanallarını hibrit bir şekilde kullanmak en sağlıklı yaklaşımdır.

Test süreçlerinizi optimize ederken kullanıcı gizliliğini (KVKK/GDPR) göz önünde bulundurmayı, kullanıcılarınıza düzenli geri bildirim kanalları sunmayı ve otomasyon araçlarından maksimum düzeyde faydalanmayı unutmayın.

Sıkça Sorulan Sorular (SSS)

1. TestFlight harici test kullanıcısı limiti tam olarak kaçtır?

Apple, bir iOS uygulaması için harici test kullanıcısı (External Tester) sınırını maksimum 10.000 olarak belirlemiştir. Dahili test kullanıcıları (Internal Testers) için bu sınır 100 kişidir.

2. Bir TestFlight derlemesinin (build) kullanım süresi ne kadardır?

Yüklenen her bir test derlemesi, yüklendiği tarihten itibaren 90 gün boyunca geçerlidir. 90 gün sonunda derleme otomatik olarak kapanır ve kullanıcıların yeni bir derleme yüklemesi gerekir.

3. TestFlight için her güncellenen derleme Apple incelemesinden geçer mi?

Harici test grubuna gönderilen ilk derleme mutlaka Beta Uygulama İncelemesi (Beta App Review) sürecinden geçer. Ancak aynı sürüm numarası altında yapılan küçük hata düzeltmeleri ve alt derlemeler (build number güncellemeleri) genellikle çok daha hızlı onaylanır veya doğrudan yayınlanır. Dahili test grubunda ise inceleme süreci hiç yoktur.

4. Çoklu Bundle ID kullanmak Apple kurallarına aykırı mıdır?

Hayır, kesinlikle aykırı değildir. Büyük ölçekli yazılım şirketleri mimari olarak Alpha, Beta, Staging ve Production ortamlarını ayırmak için farklı Bundle ID’ler kullanırlar. Bu, yazılım mühendisliğinde kabul görmüş standart bir uygulamadır.

#Teknoloji #WebGeliştirme #iOSGeliştirme #TestFlight #MobileTesting