الهدف
بعد هالدرس تقدر ترفع build على TestFlight وتضيف testers داخليين وخارجيين، وتستخدم Play internal track لتوزيع بيتا على Android، وتفهم الفرق بين المسارات المتاحة على كل منصة.
ليش هذا الحين؟
ترى ماكو شي يكسر ثقة المستخدم مثل تطبيق فيه bug يظهر في أول استخدام. البيتا خطوة تحميك من هالشي — تكتشف المشاكل قبل ما يشوفها الناس في الستور. Apple تطلب مراجعة حتى للـ beta الخارجي. Google عندها 4 مسارات مرتبة بالأمان.
الفكرة
iOS — TestFlight:
- Internal testing: حتى 100 مختبر، بدون مراجعة، الـ build يظهر خلال دقائق
- External testing: حتى 10,000 مختبر، يحتاج Beta App Review من Apple (ياخذ 1-3 أيام في الغالب)
- المختبرين لازم ينزّلون تطبيق TestFlight أول
Android — Play tracks:
- Internal testing: حتى 100 مختبر، بدون مراجعة، فوري تقريبا
- Closed testing (alpha/beta): آلاف من المختبرين، بدون مراجعة
- Open testing: عام، أي شخص يسجل، يحتاج مراجعة من Google
- Production: الإطلاق الكامل
القاعدة: ابدأ دايما من internal → بعدين closed → بعدين production. لا تقفز. الـ build المفروض يكون production-ready (مو debug، والمفاتيح حقيقية مو test keys).