البناء والإرسال إلى المتاجر عبر EAS

حتى الآن عمل Trailhead عبر Expo Go والـ development builds، مع حاسوبك المحمول يقدّم كود JavaScript. أما المستخدمون الحقيقيون فيحتاجون إلى شيء آخر: تطبيق يُثبَّت من متجر، ويبدأ دون خادم تطوير، وموقَّع بحيث يثق به هاتفهم. يصنع EAS Build هذه الـ builds في السحابة، فلا تحتاج إلى Mac من أجل iOS، ويرفعها EAS Submit إلى المتاجر.

الهوية والإصدارات في app.json

قبل أول build، احسم بضعة حقول:

{
  "expo": {
    "name": "Trailhead",
    "slug": "trailhead",
    "version": "1.0.0",
    "scheme": "trailhead",
    "icon": "./assets/images/icon.png",
    "ios": { "bundleIdentifier": "com.example.trailhead" },
    "android": { "package": "com.example.trailhead" }
  }
}

معرّف الحزمة (bundle identifier في iOS) واسم الحزمة (package name في Android) هما الهوية الدائمة لتطبيقك في المتاجر. غيّرهما بعد النشر فيرى المتجر تطبيقًا مختلفًا: لا تحديثات للمستخدمين الحاليين، ولا انتقال للمراجعات. استخدم نطاقًا معكوسًا تملكه.

هناك نوعان من الإصدارات. version هو ما يراه المستخدمون (“1.0.0”)؛ وترفعه مع كل إصدار عام. وكل رفع يحتاج أيضًا إلى رقم داخلي فريد ومتزايد (رقم البناء في iOS، ورمز الإصدار في Android). دع EAS يدير هذه الأرقام نيابةً عنك، كما سترى أدناه.

الـ build profiles

ثبّت الـ CLI، وسجّل الدخول إلى حساب Expo، وولّد ملف الإعدادات:

npm install -g eas-cli
eas login
eas build:configure

هذا ينشئ eas.json بثلاثة profiles:

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "development": { "developmentClient": true, "distribution": "internal" },
    "preview": { "distribution": "internal" },
    "production": { "autoIncrement": true }
  },
  "submit": { "production": {} }
}

• development يبني عميل التطوير الخاص بك (الـ development build من القسم 1)، مع قائمة التطوير، ويحمّل JavaScript من Metro.
• preview يبني تطبيقًا مستقلًا للمختبِرين، يُثبَّت من رابط أو رمز QR (توزيع داخلي). وعلى iOS يجب أولًا تسجيل أجهزة المختبِرين باستخدام eas device:create، لأن هذه builds من نوع ad hoc.
• production يبني للمتاجر. ومع appVersionSource: "remote" وautoIncrement، يخزّن EAS رقم البناء ويرفعه مع كل production build.

ثم ابنِ:

eas build --platform android --profile preview
eas build --platform all --profile production

يعمل البناء على خوادم EAS؛ ويطبع الـ CLI رابطًا إلى السجلّات، وفي النهاية رابطًا إلى الـ build نفسه.

بيانات الاعتماد

كل build قابل للتثبيت يكون موقَّعًا. يحتاج iOS إلى شهادة توزيع (distribution certificate) وملف تجهيز (provisioning profile)؛ ويحتاج Android إلى upload keystore. يستطيع EAS توليدها وتخزينها وإعادة استخدامها مع كل build؛ ويسألك الـ CLI في المرة الأولى. ولـ iOS تحتاج إلى عضوية مدفوعة في Apple Developer Program؛ ولـ Google Play إلى رسم تسجيل مطوّر يُدفع مرة واحدة. وتعامل مع الـ keystore الخاص بـ Android بحرص: EAS يحتفظ به لك، لكن إن أدرته بنفسك وأضعته، يصبح تحديث التطبيق مؤلمًا.

الإرسال إلى المتاجر

أنشئ أولًا سجلّ التطبيق في App Store Connect وفي Google Play Console. ثم ارفع آخر production build:

eas submit --platform ios
eas submit --platform android

على iOS يذهب الـ build إلى App Store Connect، حيث يصبح متاحًا في TestFlight للمختبِرين بعد المعالجة. وعلى Android يصل إلى مسار اختبار (الداخلي افتراضيًا)؛ ويحتاج EAS إلى مفتاح حساب خدمة (service account) من Google ليرفعه نيابةً عنك. ويمكنك الجمع بين الخطوتين باستخدام eas build --auto-submit.

اجتياز المراجعة

يراجع المتجران التطبيقات، وApple أكثر صرامة. ستملأ صفحة المتجر (الاسم، والوصف، ولقطات الشاشة لأحجام الأجهزة المطلوبة)، ورابط سياسة الخصوصية، وتفاصيل الخصوصية: قسم App Privacy لدى Apple ونموذج Data safety لدى Google Play، ويجب أن يطابقا ما يجمعه Trailhead فعلًا، مثل الموقع والصور.

تستغرق المراجعات عادةً من بضع ساعات إلى يومين. وبعد الموافقة، تختار أنت متى تطلق. ثم تتكرّر الدورة مع كل تغيير أصلي: إصدار جديد، ثم build، ثم إرسال، ثم مراجعة. أما الإصلاحات التي تقتصر على JavaScript فلها طريق أسرع، وهو موضوع الدرس الأخير.