كيفية نشر تطبيق Lovable على App Store: PWA أم Capacitor أم إعادة البناء، وتجنّب رفض الإرشاد 4.2 (2026)

إن كنت تبحث عن طريقة نشر تطبيق Lovable على App Store، فأول ما يجب معرفته أن Lovable لا يستطيع فعل ذلك نيابةً عنك. تقول وثائق النشر في Lovable إن «Lovable يبني تطبيقات ويب والنشر يكون دائمًا على رابط ويب»، وإنه «لا يوجد مسار مدمج يحزّم مشروعك ويرسله إلى App Store أو Google Play». فيما يلي الخيارات الثلاثة الحقيقية، وتكلفة كل منها، والخطوات التي تُبعد تطبيق Lovable المغلَّف عن الرفض بموجب الإرشاد 4.2.

هل يمكن نشر تطبيق Lovable على App Store مباشرةً؟

لا. حتى أكتوبر 2026، ينشر Lovable على نطاق فرعي من lovable.app أو على نطاق مخصص، والوصول إلى المتجر يعني تحزيم التطبيق خارج Lovable وإرساله من حساب المطوّر الخاص بك.

تقترح وثائق Lovable حلّين بديلين: تحويل الموقع المنشور إلى PWA قابل للتثبيت، أو «تغليف رابطك المنشور في غلاف أصلي باستخدام Capacitor خارج Lovable» ثم إرسال هذا الغلاف بنفسك. وتوضح الوثائق أمرين آخرين: Lovable لا يُنشئ مشاريع React Native، وتطبيق Lovable على الجوال مخصص فقط لبناء المشاريع من هاتفك، فهو «لا يحوّل مشروعك إلى تطبيق أصلي للمستخدمين النهائيين».

PWA أم غلاف Capacitor أم إعادة البناء: أي مسار تختار؟

اختر PWA إن لم تكن بحاجة إلى صفحة في المتجر، وCapacitor إن كنت تحتاج إلى صفحة في المتجر وتستطيع إضافة ميزات أصلية حقيقية، وإعادة البناء الأصلية إن كان على تطبيقك أن يبدو ويتصرف كمنتج مصمَّم للهاتف أولًا.

الرسوم مأخوذة من صفحة التسجيل في Apple Developer Program («99 USD لكل سنة عضوية. قد تختلف الأسعار حسب المنطقة») ومن مركز مساعدة Google Play Console («رسوم تسجيل لمرة واحدة بقيمة US$25»). وعلى Google Play، يجب على الحسابات الشخصية الجديدة أيضًا إجراء اختبار مغلق مع 12 مختبِرًا لمدة 14 يومًا قبل الحصول على صلاحية النشر في بيئة الإنتاج. ويشرح دليل الاختبار المغلق هذه الخطوة.

كيف تغلّف تطبيق Lovable باستخدام Capacitor؟

صدِّر شيفرة Lovable إلى GitHub، وابنِها محليًا، وأضف Capacitor ووجّه webDir إلى مخرجات البناء. ثم افتح المشاريع الأصلية في Xcode وAndroid Studio وأنشئ الأرشيف.

1. في Lovable، اربط حساب GitHub. المزامنة ثنائية الاتجاه وتُنشئ دائمًا مستودعًا خاصًا جديدًا، لذا يمكنك مواصلة التعديل في Lovable بينما تعمل على الغلاف الأصلي محليًا.
2. انسخ المستودع، وشغّل npm install ثم npm run build. تحقق من المكان الذي يكتب فيه Vite المخرجات، وهو عادةً dist. يحتاج Capacitor إلى ملف index.html يحتوي على وسم <head> في جذر هذا المجلد.
3. ثبّت Capacitor والمنصات باستخدام الأوامر الواردة في كتلة الشيفرة أدناه، والمأخوذة من وثائق البدء في Capacitor.
4. في capacitor.config، اضبط webDir على dist. لا تضبط server.url على نطاق Lovable المباشر: إذ يقول مرجع إعدادات Capacitor إنه «غير مخصص للاستخدام في بيئة الإنتاج».
5. أضف إضافات أصلية (الإشعارات الفورية، والاهتزاز اللمسي، والمشاركة، والمصادقة البيومترية، والإشعارات المحلية) إلى جانب أيقونات التطبيق وشاشات البداية الأصلية.
6. شغّل npx cap sync بعد كل عملية بناء للويب، ثم أنشئ الأرشيف في Xcode وارفعه إلى App Store Connect. وتغطي قائمة التحقق لإرسال التطبيق إلى App Store بقية الخطوات.

npm i @capacitor/core
npm i -D @capacitor/cli
npx cap init
npm i @capacitor/android @capacitor/ios
npx cap add android
npx cap add ios
npm run build && npx cap sync
npx cap open ios

أرسل التطبيق من حسابك الخاص في Apple. يرفض الإرشاد 4.2.6 التطبيقات المبنية بخدمة لتوليد التطبيقات ما لم «يرسلها مزوّد محتوى التطبيق مباشرةً». ويشرح دليلنا حول الإرشادين 4.3 و4.2.6 كيف ينطبق ذلك على التطبيقات المبنية بالذكاء الاصطناعي.

كيف تتجنب الرفض بموجب الإرشاد 4.2 مع تطبيق Lovable مغلَّف؟

اجعل التطبيق يقدّم ما لا يستطيع الموقع تقديمه. يطلب الإرشاد 4.2 «ميزات ومحتوى وواجهة ترتقي بالتطبيق إلى ما يتجاوز موقعًا معاد تغليفه»، ويستبعد الإرشاد 4.2.2 التطبيقات التي هي في الأساس «مقتطفات من الويب أو مجمّعات محتوى أو مجموعة من الروابط».

استخدم قائمة التحقق هذه قبل الإرسال:

• نسخة الويب المبنية مضمَّنة في الملف الثنائي وتفتح دون اتصال بالشبكة، مع عرض بيانات مخزنة مؤقتًا أو شاشة مناسبة لحالة عدم الاتصال.
• يعتمد التنقل على شريط تبويبات سفلي بدلًا من قائمة الهامبرغر، ولا توجد تذييلات خاصة بالويب أو لافتات ملفات تعريف الارتباط.
• تتم عمليات تسجيل الدخول وإنشاء الحساب وإعادة تعيين كلمة المرور كلها داخل التطبيق. لا شيء يُخرج المستخدم إلى Safari.
• يعتمد سير عمل أساسي واحد على الأقل على الجهاز، مثل التقاط الصور بالكاميرا، أو إشعارات محلية مرتبطة ببيانات المستخدم نفسه، أو الأدوات المصغّرة (Widgets)، أو المصادقة البيومترية.
• إزالة الروابط الخارجية إلى صفحات التبرع أو المتاجر أو وسائل التواصل الاجتماعي أو تقليلها إلى الحد الأدنى.
• توضح ملاحظات App Review سبب فائدة التطبيق على الهاتف وتتضمن بيانات دخول تجريبية.

ماذا حدث عندما رُفضت تطبيقات أخرى قائمة على الويب بموجب 4.2؟

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

في ديسمبر 2020، رُفض تطبيق عضوية نادٍ لمطوّر على منتدى Ionic بعبارة «يقدّم تطبيقك تجربة مستخدم محدودة لأنه لا يختلف بما يكفي عن تجربة التصفح على الجوال»، تلتها عبارة «معظم محتوى التطبيق يحيل إلى Safari». لم تكن إزالة InAppBrowser وتحسين دعم العمل دون اتصال كافيتين، فرُفض الإرسال الثاني أيضًا. ثم قُبلت المحاولة الثالثة بعد أن أعاد المطوّر بناء الشاشة الرئيسية بقوائم وبطاقات صور بأسلوب أصلي، وأضاف مزيدًا من محتوى الأخبار داخل التطبيق، وأزال معظم الروابط الخارجية.

في يناير 2026، أفاد مطوّر على منتديات Apple Developer بأن تطبيقًا للجدولة رُفض لأنه «لا يختلف بما يكفي عن تجربة التصفح على الويب»، رغم أنه كان يستخدم بالفعل الإشعارات الفورية وCore Location والوصول إلى جهات الاتصال. وخطط لإضافة الاهتزاز اللمسي والإجراءات السريعة وتكامل أعمق مع التقويم، وسأل عمّا يُعدّ «أكثر أصالة». وحتى وقت كتابة هذا المقال، لا توجد ردود على النقاش ولا نتيجة مؤكدة.

المقارنة: نجح المطوّر الأول لأنه غيّر جوهر التطبيق (محتوى داخل التطبيق، وتخطيطات أصلية، ولا روابط خارجية). أما الثاني فاكتفى بإضافة واجهات برمجة للجهاز وظل غير متأكد. ركّز جهدك على التجربة الأساسية، لا على قائمة أطول من الأذونات.

متى يجب إعادة البناء بدلًا من التغليف؟

أعد البناء بشكل أصلي عندما تكون القيمة الأساسية لتطبيقك هي محتوى الويب، أو عندما تكون قد تلقيت بالفعل رفضين بموجب 4.2 للواجهة نفسها.

مثال عملي: أداة حجز مبنية بـLovable لاستوديو يوغا تعرض قائمة الحصص ونموذج حجز ورابط دفع عبر Stripe. إذا غُلِّفت كما هي، فإنها تقع في العلامات الحمراء الثلاث للإرشاد 4.2: واجهة ويب، ورابط خارجي، وعدم إمكانية الاستخدام دون اتصال. وكتطبيق PWA يمكن إطلاقها اليوم دون تكلفة إضافية. وللحصول على صفحة في المتجر، أبقِ على الخادم الخلفي في Lovable، وأعد بناء قائمة الحصص ومسار الحجز بشاشات أصلية، وأضف تذكيرات محلية قبل كل حصة، وتعامل مع الدفع وفق قواعد الإرشاد 3.1 من إرشادات App Review. ينتقل الخادم الخلفي ونموذج البيانات كما هما، وما تعيد كتابته هو الواجهة.

إن أردت رأيًا ثانيًا حول المسار المناسب لمشروع Lovable الخاص بك، فإن خدمات The App Guy تشمل التغليف وإعادة البناء والإرسال إلى المتاجر، أو راسل yagyeshsrbobde@gmail.com.