React Native و Expo في 2026: بناء تطبيقات الهاتف ونشرها

توثيق Expo الرسمي ممتاز في شرح ما تفعله كل واجهة برمجية، لكنه أكثر صمتًا بشأن القرارات: هل تستخدم Expo أصلًا، وماذا يحدث أول مرة تحتاج فيها شيفرة أصلية، وما الذي يفصل فعليًا بين بناء ناجح على المحاكي وتطبيق منشور في المتجر.

هذا الدليل يغطي تلك القرارات. الإصدارات وقت الكتابة: Expo SDK 57 وReact Native 0.86 وexpo-router 57.

‏Expo أم React Native مجرّد؟

كان هذا مفترق طرق حقيقيًا في السابق، أما اليوم فأقل بكثير — إذ لم تعد المفاضلة القديمة قائمة، تلك التي كانت تمنعك Expo فيها من الشيفرة الأصلية. فإضافات الإعداد تتيح لمشروع مُدار إضافة اعتماديات أصلية دون الخروج من النمط المُدار.

ابدأ بـ Expo. فالأسباب الحقيقية للذهاب إلى المشروع المجرّد ضيّقة: أن تضيف React Native إلى تطبيق أصلي قائم، أو أن تصون وحدات أصلية بنفسك. وما عدا ذلك يخدمه النمط المُدار بشكل أفضل، ويبقى بإمكانك النزول إلى الأصلي عند الحاجة.

بدء مشروع

npx create-expo-app@latest my-app
cd my-app
npx expo start

يمنحك ذلك TypeScript و expo-router افتراضيًا. وخيار التوجيه أهم مما يبدو، لذا يستحق الفهم لا القبول الصامت.

التوجيه عبر الملفات مع expo-router

app/
  _layout.tsx          # التخطيط الجذري، هنا توضع المزوّدات
  (tabs)/
    _layout.tsx        # متصفّح التبويبات
    index.tsx          # /
    profile.tsx        # /profile
  products/
    [id].tsx           # /products/123
  +not-found.tsx

// app/products/[id].tsx
import { useLocalSearchParams, Stack } from 'expo-router'
import { Text, View } from 'react-native'

export default function ProductScreen() {
  const { id } = useLocalSearchParams<{ id: string }>()

  return (
    <View>
      <Stack.Screen options={{ title: `Product ${id}` }} />
      <Text>Showing product {id}</Text>
    </View>
  )
}

والفائدة تتجاوز الترتيب: هذه المسارات روابط حقيقية، فتعمل الروابط العميقة والروابط الشاملة دون إعداد ربط منفصل، لأن مسار الملف هو المسار.

شيفرة أصلية دون الخروج من النمط المُدار

هذا هو الجزء الذي تتخطاه معظم الأدلة، وهو النقطة التي يستنتج عندها كثيرون خطأً أنهم مضطرون لمغادرة Expo.

أنت لا تعدّل مجلدي ios/ وandroid/ مباشرة، بل تصرّح بما ينبغي أن يحتوياه، فتولّدهما Expo وقت البناء:

// app.json
{
  "expo": {
    "name": "My App",
    "slug": "my-app",
    "plugins": [
      "expo-camera",
      [
        "expo-build-properties",
        {
          "ios": { "deploymentTarget": "15.1" },
          "android": { "compileSdkVersion": 35 }
        }
      ]
    ],
    "ios": { "bundleIdentifier": "com.example.myapp" },
    "android": { "package": "com.example.myapp" }
  }
}

والنتيجة الجوهرية: المجلدان الأصليان مخرجات بناء لا مصدر. فهما يُعاد توليدهما، وأي تعديل يدوي يضيع. وإن وجدت نفسك تعدّلهما، فإما أن التعديل مكانه إضافة إعداد، وإما أنك تجاوزت فعلًا النمط المُدار.

‏EAS Build

eas build --platform ios --profile production
eas build --platform android --profile production

بناء تطبيقات iOS كان يعني تقليديًا امتلاك جهاز Mac ومصارعة الشهادات، وينقل EAS Build ذلك إلى جهاز مُستضاف.

وأعدّ بناء تطوير مبكرًا. فتطبيق Expo Go مريح لنظرة أولى، لكنه لا يحوي إلا الوحدات الأصلية التي تشحنها Expo. وفي اللحظة التي تضيف فيها مكتبة بشيفرة أصلية خاصة بها، لن يستطيع Expo Go تشغيل تطبيقك — ويفشل بطريقة تبدو كأنها تثبيت معطوب لا ميزة غير مدعومة. أما بناء التطوير فيتضمن اعتمادياتك الأصلية الفعلية ويتصرف كالتطبيق الحقيقي.

التحديثات الفورية

eas update --branch production --message "Fix checkout validation"

يشحن هذا شيفرة JavaScript المتغيرة مباشرة إلى التطبيقات المثبّتة متجاوزًا مراجعة المتجر، وهو مفيد فعلًا لإصلاح نص خاطئ أو خطأ تحقق في اليوم نفسه.

والحد الذي يجب معرفته: التحديثات الفورية تحمل JavaScript والأصول فقط. وأي شيء يغيّر الشيفرة الأصلية — مكتبة جديدة باعتماديات أصلية، أو ترقية SDK، أو تغيير أذونات — يتطلب حزمة جديدة ونشرًا في المتجر. والخلط بين الاثنين أشيع سبب لعبارة «أُرسل التحديث لكن لم يتغير شيء».

النشر في المتاجر

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

أمران يكلّفان الناس أسبوعهم الأول عادةً، ولا علاقة لأيهما بالشيفرة:

نصوص الأذونات. ترفض Apple أي تطبيق يطلب إذنًا دون شرح السبب بلغة المستخدم. صرّح بها بوضوح بدل ترك مكتبة تضع نصًا افتراضيًا:

"ios": {
  "infoPlist": {
    "NSCameraUsageDescription": "نستخدم الكاميرا لتتمكن من تصوير الإيصال.",
    "NSPhotoLibraryUsageDescription": "نصل إلى صورك لتتمكن من إرفاق صورة بالطلب."
  }
}

مستوى واجهة Android المستهدف. يفرض Google Play حدًا أدنى ويرفعه سنويًا، والتطبيق دونه لا يمكن تحديثه — وليس تحذيرًا بل منعًا صريحًا. تحقّق منه قبل كل إصدار بدل اكتشافه عند النشر.

المعمارية الجديدة

المعمارية الجديدة في React Native — Fabric و TurboModules — هي الافتراضية في الإصدارات الحالية. ولن تلاحظ فرقًا في معظم شيفرة التطبيق: المكوّنات نفسها والخطافات نفسها.

وحيث تظهر فعلًا هو مكتبات الطرف الثالث. فحزمة غير مصانة كُتبت للمعمارية القديمة قد لا تعمل. لذا قبل تبنّي أي مكتبة تحقّق من تاريخ آخر إصدار لها ومن إعلانها دعم المعمارية الجديدة. وهذا اليوم أشيع عائق أمام الترقية، ويستحق التحقق قبل الاعتماد لا بعده.

الأداء: ثلاثة أمور تهم فعلًا

• استخدم FlatList بشكل صحيح أو FlashList. فعرض قائمة طويلة عبر .map() يركّب كل الصفوف دفعة واحدة، والقوائم هي حيث يُربح أداء الهاتف أو يُخسر.
• أبقِ الحركات خارج خيط JavaScript. يشغّلها Reanimated على خيط الواجهة فتبقى سلسة حتى وJavaScript مشغول، أما الحركات المُدارة من JS فتتقطّع تحت الحمل.
• راقب حجم الحزمة وأبعاد الصور. فشحن صورة بعرض 4000 بكسل لعرضها بعرض 200 يهدر الذاكرة وزمن فك الترميز على الأجهزة الضعيفة تحديدًا، وهي التي لا تستطيع اختبارها.

أخطاء يجدر تجنّبها

• البقاء على Expo Go طويلًا. فهو لا يشغّل الوحدات الأصلية المخصصة. انتقل إلى بناء تطوير فور إضافة واحدة.
• تعديل ios/ و android/ يدويًا. فهما يُعاد توليدهما. ضع التغيير في إضافة إعداد.
• توقّع أن تشحن التحديثات الفورية تغييرات أصلية. لا تستطيع. فالشيفرة الأصلية الجديدة تحتاج حزمة جديدة.
• الاختبار على المحاكي فقط. فالأداء والأذونات والكاميرا والإشعارات تتصرف جميعها بشكل مختلف على جهاز حقيقي.
• تخطي ترقيات SDK. فترقية واحدة أمر روتيني، وأربع دفعة واحدة مشروع قائم بذاته.

مسار معقول

ابدأ بـ create-expo-app و expo-router. وانتقل إلى بناء تطوير فور احتياجك وحدة أصلية. وجهّز EAS Build مبكرًا — قبل الإطلاق بكثير — كي يعمل البناء قبل أن يصبح مضطرًا للعمل. وأضف التحديثات الفورية لإصلاحات JavaScript، وواصل الترقية إصدار SDK واحدًا في كل مرة.

لا شيء من هذا غريب. فمعظم مشاريع React Native التي تتعثّر لا تتعثّر لأن إطار العمل فشل، بل لأن مسار البناء والإصدار تُرك إلى النهاية.

أسئلة شائعة

هل أستخدم Expo أم React Native مجرّدًا في 2026؟

استخدم Expo ما لم تكن تضيف React Native إلى تطبيق أصلي قائم أو تصون وحدات أصلية بنفسك. فإضافات الإعداد تعني أن النمط المُدار لم يعد يمنع الشيفرة الأصلية، وبذلك زال السبب القديم للذهاب إلى المجرّد.

هل يمكنني استخدام وحدات أصلية مع Expo؟

نعم. أضف المكتبة، وصرّح بها في app.json عبر إضافة إعداد، وابنِ بناء تطوير. ولن تعدّل ios/ أو android/ بنفسك، فـ Expo تولّدهما من إعدادك.

ما الفرق بين Expo Go وبناء التطوير؟

‏Expo Go تطبيق جاهز يحوي وحدات Expo الأصلية فقط، ومفيد لنظرة أولى. أما بناء التطوير فهو تطبيقك أنت باعتمادياتك الأصلية مُدمجة. وفور إضافة أي شيفرة أصلية مخصصة، لن يستطيع Expo Go تشغيل مشروعك.

هل أحتاج جهاز Mac لبناء تطبيق iOS عبر Expo؟

لا. يبني EAS Build على أجهزة macOS مُستضافة، فتستطيع البناء والنشر من Windows أو Linux. ويبقى الـ Mac مريحًا لمحاكي iOS لكنه لم يعد شرطًا للنشر.

ما الذي تستطيع التحديثات الفورية تغييره فعلًا؟

‏JavaScript والأصول فقط. فإصلاحات الأخطاء والنصوص وتغييرات الواجهة تُشحن فورًا، أما أي شيء يمس الشيفرة الأصلية — اعتمادية أصلية جديدة أو ترقية SDK أو تغيير أذونات — فيحتاج حزمة جديدة ومراجعة متجر.

لماذا يعمل تطبيقي في Expo Go ويفشل بعد البناء؟

غالبًا بسبب وحدة أصلية يتضمنها Expo Go ولا يصرّح بها إعدادك، أو إذن ناقص في app.json. ابنِ بناء تطوير واقرأ السجلات الأصلية، فالفشل يظهر فيها عادةً لا في سجل JavaScript.

كم مرة ينبغي ترقية Expo SDK؟

مع كل إصدار، أو كل إصدارين على أبعد تقدير. فترقية إصدار واحد مهمة قصيرة عادةً مع أداة تحويل تلقائي، أما تخطي عدة إصدارات فيحوّلها إلى ترحيل يستغرق أيامًا، والمكتبات غير المصانة تزيد الأمر سوءًا كلما انتظرت.

هل المعمارية الجديدة آمنة للاستخدام؟

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