حجبت Apple تحديثات Replit وVibecode في App Store بسبب ميزات vibe coding

أوقفت Apple مؤقتًا نشر التحديثات لعدة تطبيقات مرتبطة بـ vibe coding، بما فيها Replit و Vibecode. استنادًا إلى وصف الحالة، تتعلق مطالبات الشركة بميزات محددة اعتبرتها غير متوافقة مع قواعس App Store.

ما الذي حدث

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

أصبحت Replit و Vibecode أمثلة ملحوظة لأن كلا الخدمتين تبيع فكرة التطوير "من هاتفك وحسب الوصف". يصيغ المستخدم مهمة باللغة الطبيعية، ويتلقى نموذج مشروع، ويمكنه بعد ذلك تعديل الواجهة والمنطق وبنية الملفات. بالنسبة للجمهور الواسع، هذا هو ما يعنيه vibe coding: هندسة يدوية أقل، حوار أكثر مع النموذج، وتكرار أسرع.

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

أين ينشأ النزاع

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

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

بالنسبة لمثل هذه المنتجات، تبدو منطقة الخطر المرتفع عادة كما يلي:

• توليد وتنفيذ كود المستخدم مباشرة من عميل الجوال
• التغييرات البعيدة لسلوك التطبيق بدون استعراض منفصل لكل ميزة جديدة
• الوصول إلى المترجمات أو المترجمات أو الحاويات الخارجية المخفية عن الاعتدال
• السيناريوهات التي ينشئ فيها الذكاء الاصطناعي تطبيقات صغيرة كاملة داخل غلاف منشور بالفعل

ما الذي سيحدث بعد ذلك

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

بالنسبة للمستخدمين، هذا يعني ليس كثيرًا فقدان الخدمة بقدر ما هو إبطاء الوتيرة. قد تُطلق الميزات الجديدة أولاً في المتصفح أو سطح المكتب أو عبر TestFlight، وتصل إلى متجر التطبيقات لاحقًا وفي شكل مخفف. بالنسبة للشركات نفسها، الخطر أكبر: سوق vibe coding ينمو حاليًا بالضبط من خلال وعد "بناء تطبيق في بضع دقائق"، وأي قيد على المنصة يكسر تأثير البساطة هذا الذي يُبنى عليه مسار النمو.

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

ما يعنيه هذا

أظهرت Apple أنها مستعدة لتقييد حتى منتجات الذكاء الاصطناعي الشهيرة إذا اقتربت كثيرًا من السيناريوهات المحظورة لنظام iOS. بالنسبة للسوق، هذا إشارة: يعتمد مستقبل vibe coding ليس فقط على جودة النماذج، بل أيضًا على كيفية حزم الخدمات بحذر لتوليد الكود والتنفيذ والنشر ضمن قواعد منصات الجوال الرئيسية.