فريق واحد يُصدر تطبيقك في المتجرين
يشمل تطوير React Native تطبيقات iPhone وAndroid مبنية من شيفرة واحدة بلغة TypeScript، تعرض مكونات أصلية حقيقية. وهو الخيار الصحيح حين تحتاج إلى المنصتين منذ الإصدار الأول، أو حين يتكون التطبيق في معظمه من شاشات ونماذج وقوائم ووسائط، أو حين يكون لديك منتج ويب مبني على React ومهندسون يعرفونها.
نبني على Expo وعلى البنية الجديدة (New Architecture) في React Native، مع TypeScript بوضعها الصارم ونظام تصميم مشترك، فتبقى المنصتان متسقتين وتراعي كل منهما أعرافها. وحين تحتاج ميزة إلى شيفرة خاصة بالمنصة، نكتب وحدة أصلية بلغة Swift أو Kotlin. أما إذا غلبت على منتجك الرسوميات الثقيلة، أو المهام المعقدة في الخلفية، أو التكامل العميق مع العتاد، فسنوصيك بالتطوير الأصلي الكامل.
شيفرة TypeScript مشتركة
منطق العمل والوصول إلى واجهات البرمجة (API) والحالة ومعظم الشاشات تُكتب مرة واحدة بلغة TypeScript، ولا نضيف ملفات خاصة بكل منصة إلا حيث ينبغي أن يختلف سلوك iOS عن Android.
العمل عبر Expo
Expo Router للتنقل، وEAS Build لإنتاج النسخ الموقّعة، وإضافات الإعداد لضبط الإعدادات الأصلية، فنادراً ما يحتاج المهندسون إلى فتح Xcode أو Android Studio.
الوحدات الأصلية
وحدات مخصصة بلغتي Swift وKotlin لحزم تطوير البرمجيات (SDK) أو أجهزة الاستشعار أو ميزات النظام التي لا تتوفر لها مكتبة تحظى بالصيانة، ونتيحها لشيفرة TypeScript عبر واجهات محددة الأنواع.
الحركة والإيماءات
تفاعلات مبنية باستخدام Reanimated وGesture Handler تعمل على مسار تنفيذ الواجهة، فتبقى الانتقالات والسحب سلسة بينما تنشغل JavaScript بمهام أخرى.
التحديث عبر الهواء
نوصل إصلاحات JavaScript وتغييرات المحتوى عبر EAS Update دون انتظار مراجعة المتجر، مع قنوات إصدار وإمكانية للتراجع في كل بيئة.
مشاركة الشيفرة مع الويب
مستودع موحد يتشارك فيه تطبيق الويب المبني على React وتطبيق الجوال الأنواعَ والتحقق من المدخلات وخطافات واجهات البرمجة وقواعد العمل، فيقل العمل المكرر.
ما تتسلمه منا
- شيفرة TypeScript واحدة للمنصتين
- نسخ جاهزة لمتجرَي iOS وAndroid
- إعداد البناء والتحديث عبر EAS
- مكتبة مكونات مشتركة
- حزم اختبارات Jest وMaestro
- الشيفرة المصدرية للوحدات الأصلية، إن كُتبت
- صفحات التطبيق في متجرَي المنصتين
- ملاحظات لترقية الإصدارات المستقبلية
طريقة عملنا
- 01
التأكد من الملاءمة
نراجع قائمة الميزات في ضوء ما تتقنه React Native، وننبهك إلى كل ما يحتاج إلى شيفرة أصلية. وإن كان المنتج لا يناسبها، قلنا لك ذلك قبل تحديد أي نطاق عمل.
- 02
وضع الأساسات
نبدأ بإعداد التنقل والحالة وطبقة واجهات البرمجة ومتغيرات التصميم ومسار البناء، فتخرج أولى الشاشات في نسخ قابلة للتثبيت على iPhone وAndroid.
- 03
البناء للمنصتين معاً
نطوّر كل ميزة ونراجعها على المنصتين في طلب الدمج نفسه. وبذلك لا تتأخر منصة عن الأخرى، وتظهر فروق التخطيط أو السلوك ما دام إصلاحها قليل التكلفة.
- 04
الإطلاق والتحديث
نقدّم التطبيق إلى App Store وGoogle Play، ثم نعدّ قنوات التحديث لتصل تغييرات JavaScript اللاحقة إلى المستخدمين بسرعة. أما تغييرات الشيفرة الأصلية فتمر بإصدار عادي عبر المتجر.
التقنيات التي نستخدمها
| المجال | التقنيات |
|---|---|
| الأساس | React Native، Expo، TypeScript، Hermes |
| الواجهة | Expo Router، React Navigation، Reanimated، NativeWind |
| الحالة | Zustand، TanStack Query، Redux Toolkit، MMKV |
| التسليم | EAS Build، EAS Update، Jest، Maestro، Sentry |
تحتاج إلى iOS وAndroid منذ الإصدار الأول
مستخدموك موزعون على المنصتين، والإطلاق على واحدة فقط يترك جزءاً من سوقك منتظراً. ويتكون التطبيق من شاشات ونماذج وصفحات محتوى متجدد ومدفوعات، وتفضّل أن تموّل فريقاً واحداً وشيفرة واحدة بدلاً من مشروعين أصليين متوازيين.
- النسخة الأولى (MVP) لشركة ناشئة على المتجرين
- تطبيق جوال يرافق تطبيق React
- تطبيقات داخلية لأجهزة متنوعة
- تطبيقات الأسواق الإلكترونية والحجز
- ترقية تطبيق React Native قديم
- تطبيقات المحتوى والمجتمعات
أسئلة شائعة
هل React Native سريعة بما يكفي لتطبيق في التشغيل الفعلي؟
في معظم التطبيقات، نعم. تعرض React Native عناصر أصلية، ومع البنية الجديدة ومحرك Hermes تقترب سرعة التشغيل والتفاعل من التطبيقات الأصلية في الشاشات المعتادة. أما الحالات التي تتعثر فيها فمحددة، مثل الرسوميات الثقيلة في الوقت الفعلي، والقوائم الطويلة ذات الخلايا المعقدة التي لم تُضبط، والمعالجة المكثفة على الجهاز. ونقيس الأداء أثناء التطوير على هواتف Android متوسطة الفئة، لأن المشكلات تظهر عليها أولاً.
هل نستخدم Expo أم مشروع React Native مجرداً؟
نوصي باستخدام Expo في كل مشروع جديد تقريباً، وهذا ما يوصي به فريق React Native أيضاً. فهي لم تعد تحصرك في مجموعة ثابتة من الميزات، لأن نسخ التطوير وإضافات الإعداد تتيح لك إضافة أي مكتبة أصلية أو وحداتك الخاصة. وتكسب بذلك بناءً مُداراً، وترقيات أبسط، وتحديثات عبر الهواء. أما المشروع المجرد فمعقول أساساً حين تضيف شاشات React Native إلى تطبيق أصلي قائم.
كم من الشيفرة يمكن أن نتشاركه مع تطبيق الويب المبني على React؟
المنطق يُشارَك بسهولة، والواجهة أقل من ذلك. فالأنواع ومخططات التحقق والوصول إلى واجهات البرمجة وإدارة الحالة وقواعد العمل يمكن أن تجتمع في حزمة واحدة يستخدمها الطرفان. أما الشاشات فتُكتب عادةً كلٌّ على حدة، لأن التخطيط الجيد للجوال ليس صفحة ويب ضيقة، ولأن التنقل يعمل بطريقة مختلفة. ونعدّ مستودعاً موحداً يجعل للشيفرة المشتركة مكاناً واحداً، ونعطيك تقديراً واقعياً بعد مراجعة شيفرة الويب لديك.
ماذا لو احتجنا إلى ميزة لا تدعمها React Native؟
عندها نكتبها بالشيفرة الأصلية. فالوحدة الأصلية بلغتي Swift وKotlin تستطيع أن تغلّف أي واجهة برمجة للمنصة أو حزمة تطوير من مورّد، وتتيحها لجانب TypeScript مع تحديد كامل للأنواع. وهذا عمل معتاد مع أجهزة الدفع وأجهزة Bluetooth ومسارات الكاميرا المخصصة وحزم التحقق من الهوية. ونحدد هذه الاحتياجات أثناء تحديد النطاق، فيظهر الجهد في العرض بدلاً من أن يفاجئك في منتصف البناء.
هل يمكنكم تولي تطبيق React Native الحالي لدينا وترقيته؟
نعم. كثير من تطبيقات React Native تتأخر عدة إصدارات، فيعيقها ذلك عن متطلبات المتاجر وعن المكتبات الجديدة. ندقق الشيفرة والاعتماديات والمشاريع الأصلية، ثم نرقّي على خطوات مضبوطة يبقى التطبيق بعد كل منها قابلاً للإصدار. وحيث يفيد ذلك، ننقل المشروع إلى Expo والبنية الجديدة، ونشدد قواعد TypeScript، ونضيف اختبارات حول أخطر المسارات، ونوثّق ما غيّرناه وسبب تغييره.