Shopify تترك React Native وتعيد بناء تطبيقاتها بـ Swift وKotlin بعد ست سنوات
قرارات معمارية كثيرة اتُّخذت هربًا من تكرار العمل، والـ agents غيّروا تكلفة هذا التكرار نفسه، فصار الرقم الذي بُنيت عليه تلك القرارات بحاجة إلى مراجعة.
نشرت Shopify في 10 سبتمبر 2026 مقالة هندسية بعنوان “Native is now the future of mobile at Shopify”، أعلنت فيها عودة تطبيقاتها من React Native إلى Swift على iOS وKotlin على Android.
أول تطبيق اكتمل هو Shop. فقد أُعيد بناؤه من الصفر، واستغرق من مرحلة الـ proof of concept حتى النشر على المتجر 12 أسبوعًا. ويجري العمل الآن على تطبيق Shopify الأساسي، الذي يضم أكثر من 300 شاشة، إلى جانب widgets وتطبيق Apple Watch وSiri Shortcuts.
اللافت في الإعلان ليس العودة نفسها، بل سببها. ففي عام 2020، حين اختارت الشركة React Native، كانت الحسابات واضحة: تُكتب الميزة مرة واحدة بدل مرتين، ويستطيع أي مطور غير متخصص في الموبايل أن يساهم، ولا يضطر الفريق إلى ملاحقة التطابق بين iOS وAndroid باستمرار.
أي أن تكلفة التطوير native كانت في كتابة كل شيء مرتين، ثم إبقاء النسختين متسقتين.
وهذه التكلفة تحديدًا هي ما خفّضته الـ agents. فبحسب Shopify، يستطيع الـ agent أن ينفّذ الميزة على منصة وهو يرى كود المنصة الأخرى مرجعًا، فيترجم ويكتب الاختبارات ويراجع. وتقول الشركة صراحة إن بناء الميزة نفسها بـ Swift وKotlin لم تعد له التكلفة التي كانت له من قبل.
وأثر القصة أوسع من تطبيقات الموبايل. فكثير من القرارات المعمارية في الفرق التقنية اتُّخذت أصلًا لتجنب العمل المكرر: الـ monorepo، والـ shared library، وطبقات التجريد. وكل قرار منها قام على تقدير لتكلفة التكرار. وحين يتغير هذا التقدير، يصبح القرار القديم عادة أكثر منه حسابًا، ما لم يُراجَع.
ولا يعني ذلك أن كل فريق سيصل إلى الاستنتاج نفسه. فحجم Shopify وعدد مطوريها يختلفان عن فريق صغير. لكن السؤال الذي طرحته الشركة على نفسها ينطبق على أي stack اختير لأنه يوفر الكتابة مرتين.