TestFlight beta yönetimi: 200 tester’ı nasıl organize ederim

iOS uygulamalarımda TestFlight aktif olarak kullanıyorum. Her yeni build 10-50 tester’a gidiyor, major release öncesi 100-200 kişiye. Manuel yönetim bu ölçekte imkansız, sistematik bir yaklaşım gerekiyor.

Bu yazıda TestFlight beta program’ını nasıl organize ettiğimi anlatacağım: grouping, feedback collection, versiyonlama, iletişim.

TestFlight’ın temel yapıları

Internal Testers: Apple Developer hesabındaki takım üyeleri. 100 kişi limit. Ücretsiz. Test build’leri anında erişim.

External Testers: Public kullanıcılar. 10,000 kişi limit. Apple review geçmek zorunda (24-48 saat). Ücretsiz.

Groups: Tester’ları grupluyorsun. Her grup’a ayrı build gönderebiliyorsun. Maximum 100 grup.

Bu 3 concept üzerine organization kuruluyor.

Tester gruplarının tasarımı

Benim group yapım:

1. Core Team (5-10 kişi): Kendi ekibim, developer, designer, QA. Her build buraya ilk gider. Internal testing.

2. Extended Team (20-50 kişi): Şirket içi diğer stakeholder’lar, product manager, marketing, customer support. Major feature’lar buraya.

3. Close Beta (50-100 kişi): Power users, ilk kullanıcılar, aktif kullanıcılar. Gerçek kullanım test’i.

4. Public Beta (1000+ kişi): Public TestFlight link ile herkes katılabilir. Wide validation.

5. Release Candidate (500 kişi): App Store’a gitmeden son doğrulama. Gerçek kullanıcı örneği.

Her grup farklı feedback expectation’ı ile geliyor. Core team teknik feedback, Public beta UX feedback.

Build strategy per group

Her group aynı build’i değil, aşamalı build’ler alıyor:

1. Week 1: Build goes to Core Team. Smoke test, major bug catch.
2. Week 2 (bug fix): Same build + fixes → Extended Team.
3. Week 3: Close Beta’ya gidiyor. Real-world usage.
4. Week 4: Public Beta, daha wide audience.
5. Week 5: Release Candidate, no new features.
6. Week 6: App Store submission.

6 haftalık release cycle. Fast-moving teams 2-3 haftaya sıkıştırabiliyor.

Feedback collection: TestFlight’ın built-in tool’u

TestFlight’ın in-app feedback’i iOS 13’ten beri var. Kullanıcı screenshot alıp comment yazabiliyor. Crash otomatik rapor ediliyor.

App Store Connect > TestFlight > Feedback’te görünüyor.

Dezavantaj: basit organization. Binlerce feedback comment’ini categorize etmek zor.

Benim ek tool’larım:

In-app feedback button. App’in içinde “Geri bildirim gönder” butonu. Tıklayınca custom form açılıyor: screenshot + comment + auto-added context (user ID, app version, device model, iOS version).

Feedback backend’e gidiyor. Custom dashboard’da kategorize ediyorum.

Survey after X usage. User 10 kez app açtıktan sonra “Nasıl gidiyor?” mini survey. 1-10 rating + comment.

User interviews. Top 20 most-engaged beta tester’a ayda bir 30 dakika call. Qualitative feedback.

TestFlight’ın native tool’u screenshot + crash reports için. Structured feedback için custom system gerekiyor.

İletişim akışı

200 tester’a nasıl iletişim kuruyorsun?

TestFlight’ın Release Notes: Her build yüklerken notes yazıyorsun. Tester build install etmeden önce görüyor.

v2.3.1 (Build 47)

Bu build'te:
- Yeni dashboard layout (feedback isterim)
- Crash fix: HealthKit sync
- Dark mode renkleri iyileştirildi

Test istediğim:
- Dashboard kartlarının renklerini nasıl buluyorsun?
- HealthKit sync crash ediyor mu? (Evde test ederken)

Bug bulursan: Screenshot + shake gesture → feedback gönder

Spesifik test ister. Tester’a “ne bakman lazım” söyle. Generic “test et” diyen developer feedback alamaz.

Email güncellemeleri: Build gönderdikten sonra aktif tester’lara email: “Yeni build var, özellikle X feature’ını test et.”

Discord / Slack kanalı: Power tester’lar için private kanal. Real-time soru-cevap.

Beta termination stratejisi

Bazı tester’lar feedback vermiyor ama TestFlight’da spot tutuyor (100 internal limit’i boşa harcıyorlar). Ayda bir cleanup:

Kriter: Son 3 build’te hiç install etmemiş veya feedback vermemiş.

Aksiyon: Emaille nazik çıkarma. “Son 3 ay’dır TestFlight build’i install etmedin. Beta’dan çıkarıyoruz. Tekrar katılmak istersen haber ver.”

Bu cleanup internal 100 slot’u yeni aktif tester’lar için açıyor.

TestFlight’ın limitlerine ulaşırsak

10,000 external tester limit’i aşmak lazımsa alternatives:

Ad Hoc Distribution: 100 device/yıl limit, ayrı provisioning. Internal corporate apps için.

Enterprise Developer Program: $299/yıl, in-house distribution unlimited device. Ama App Store submission yok (kendi apps).

Firebase App Distribution: TestFlight alternative. Cross-platform (Android + iOS). 3000 tester free tier.

Diawi / AppCenter: Build sharing tools. Individual .ipa distribution için.

Çoğu proje için TestFlight 10K limit’i yeterli. Bu limit’e ulaşmak zaten başarı işareti.

Versioning disciplin

TestFlight build’lerinin version yapısı:

Version (marketing): 2.3.1 gibi semantic versioning. App Store’a çıkan version.

Build (internal): 47, 48, 49 gibi monotonic artan. Her build unique.

Workflow:
– 2.3.0 (Build 44): Önceki release
– 2.3.1 (Build 45): Yeni beta, bug fix
– 2.3.1 (Build 46): Aynı marketing version, new beta iteration
– 2.3.1 (Build 47): Yine aynı, bir daha iteration
– 2.3.1 (Build 47 or 48): App Store’a çıkan

TestFlight aynı marketing version’da birden fazla build yüklemeye izin veriyor. Iterating ederken faydalı.

Crash monitoring ile TestFlight

TestFlight build’lerinde crash’ler App Store Connect’te görünüyor ama sadece 48-72 saat tutulur. Senin ayrıca tutmak gerekiyor.

Firebase Crashlytics, Sentry, Datadog: hepsi TestFlight build’leri track ediyor. Deprecation warning’leri, memory leak’leri kendi tool’unda görüyorsun.

Benim workflow’um:

1. Build upload
2. Crashlytics’te “Beta: 47” filter’ı açıyorum
3. 24 saat sonra crash rate’e bakıyorum
4. %0.1 altında ise Close Beta’ya geçiriyorum
5. %0.5 üstü ise hot fix yapıp yeni build

Bu crash monitoring sayesinde problemli build’leri wider audience’a dağıtmadan önce yakalıyorum.

Common beta problems

Beta programında karşılaştığım tipik sorunlar:

1. Tester sessiz kalıyor. Install ediyor, hiç kullanmıyor. Proactive outreach lazım.

2. Same feedback tekrar geliyor. 10 kişi aynı bug’u rapor ediyor. Duplicate detection + canlı FAQ.

3. Feature request’ler sel oluyor. “Şu feature eklensin” feedback’leri. Ayrı bir kanala yönlendir, beta testing için “mevcut olanı test etmek” odak.

4. Eski iOS version’ları. Bazı tester iOS 16’da, app iOS 17+ hedefliyor. Require iOS 17 warning’i ile filter.

5. Language problem. Turkish app’i sadece Turkish tester. English’e çevirmek için international feedback zor.

TestFlight’ın limit’leri

Farkında olunması gerekenler:

• Beta period 90 gün. Bitince re-submit.
• New build submit’i kurmak 15-20 dakika. Release Notes, screenshots, test info.
• Public link’ler tek seferlik değil, kalıcı. Virality için iyi.
• Build size limit: iOS for normal app 200MB.
• Download sonrası tester’ın TestFlight’a sign in olması gerekiyor.

Sonuç

Beta testing sadece “beta gönder, feedback bekle” değil. Grouping, aşamalı distribution, targeted feedback request’leri, cleanup discipline. 200+ tester’lı bir program 10-15 saat/ay operational iş.

Ama değer: App Store’a çıkan build %90 daha olgun, crash rate %80 düşük, user feedback daha zengin. Ürün kalitesi için investment vermeye değer.