Guideline 4.2 Minimum Functionality: رفض التطبيق والحل

تَرفض الإرشادة 4.2، «Minimum Functionality»، التطبيقَ الذي لا يقدّم شيئًا أكثر من موقع ويب، أو يقدّم أقل مما يكفي ليحتفظ به المستخدم. العلاج ليس أن تكدّس الميزات الأصلية، بل أن تضع واحدة منها في قلب الاستخدام، ثم تخبر المراجع أين يجدها. والإصلاح يتطلب في أغلب الأحيان build جديدًا.

أنشر تطبيقات iOS خاصة بي: Solys وTradaZen وNolera موجودة على App Store. يعتمد هذا الدليل على نص Apple الرسمي، الذي قرأته في 15 أكتوبر 2026، وعلى حالات رفض بسبب 4.2 نشرها مطوّرون في منتديات Apple. التطبيقات المرفوضة المذكورة أدناه أمثلة. وللنظرة الشاملة على كل أسباب الرفض، اقرأ بدلًا من ذلك لماذا ترفض Apple التطبيق.

ماذا تقول الإرشادة 4.2؟

توجد الإرشادة 4.2 في القسم 4، «Design»، من App Review Guidelines. جملتها الأولى تضع المعيار: «Your app should include features, content, and UI that elevate it beyond a repackaged website.» بعبارة أخرى، يجب أن يقدّم تطبيقك ميزات ومحتوى وواجهة ترفعه فوق موقع ويب أُعيد تغليفه في صندوق.

ويضيف النص فكرتين. التطبيق الذي ليس مفيدًا حقًا أو فريدًا أو «app-like» لا مكان له على App Store. والتطبيق الذي لا يقدّم ترفيهًا دائمًا ولا فائدة كافية قد يُرفض. إذن تحكم الإرشادة 4.2 على أمرين: الاختلاف عن الويب، وكمية القيمة.

القواعد الفرعية التي قد تذكرها الرسالة

القاعدة الفرعية	ما تطلبه Apple	الرفض المعتاد
4.2	تجاوز مستوى موقع الويب	موقع معروض داخل WebView
4.2.1	تجربة واقع معزّز حقيقية	نموذج ثلاثي الأبعاد موضوع في عرض AR
4.2.2	ليس مجرد تسويق أو روابط	تطبيق واجهة عرض، مجمّع، روابط
4.2.3	تطبيق مستقل وتنزيلات واضحة	تطبيق يتطلب تطبيقًا آخر
4.2.6	لا تطبيقات مبنية على قالب تجاري	قالب يقدّمه مزوّد خدمة

ثلاثة توضيحات. تستثني الإرشادة 4.2.2 الكتالوجات: «Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links.» إذن قد يمرّ كتالوج منتجات. أما الكتيّب الإعلاني فلا.

للإرشادة 4.2.3 فقرتان. الفقرة (i) تطلب أن يعمل التطبيق وحده، دون تثبيت تطبيق آخر. والفقرة (ii) تطلب، إن كان التطبيق يحتاج إلى تنزيل موارد عند التشغيل الأول، أن تُعلن حجم التنزيل وتطلب الموافقة قبله.

أما الإرشادة 4.2.6، المتعلقة بالقوالب التجارية وخدمات توليد التطبيقات، فمفصّلة في دليل الإرشادة 4.3، لأنها مرتبطة بقاعدة مكافحة السبام.

أكثر رسالتين شيوعًا في رفض 4.2

تبدأ رسالة Apple بالعنوان «Guideline 4.2 - Design - Minimum Functionality». وما يليه يوضّح أي المشكلتين رآها المراجع. إليك صياغتين نشرهما مطوّرون في منتديات Apple. يعود تاريخهما إلى بضع سنوات: ربما تغيّر النص الحرفي، لكن العائلتين لم تتغيرا.

التطبيق يشبه موقعًا. «Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.» هذه الرسالة، المنشورة في منتديات Apple، تتضمن جملة حاسمة: «Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store.»

التطبيق هزيل جدًا. «We found that the usefulness of your app is limited by the minimal amount of content or features it includes.» هذه الرسالة الثانية تطلب مراجعة الفكرة، وتعترف بأنه لا توجد قاعدة رقمية تحدد ما هو مفيد أو مسلٍّ.

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

أربع حالات نموذجية لرفض 4.2

الحالات الأربع أدناه أمثلة مبنية لتوضيح القاعدة، وليست تطبيقات حقيقية.

موقع الويب المغلّف

مثال: نادٍ رياضي يعرض موقعه للجوال داخل WebView، مع شريط تبويبات أصلي فوقه. الجدول والحجز والحساب كلها صفحات ويب. يجد المراجع فيها ما كان Safari سيعرضه له. وتقول Apple ذلك في صفحة App Review: موقع يُقدَّم داخل تطبيق iOS، أو محتوى ويب غير مكيّف لـ iOS، أو تفاعلات ويب محدودة، لا تصنع تطبيقًا جيدًا.

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

التطبيق البسيط جدًا

مثال: تطبيق يعرض اقتباسًا واحدًا يوميًا، ولا شيء غير ذلك. تكتشفه كله في عشر ثوانٍ. تتحدث الإرشادة 4.2 عن «lasting entertainment value or adequate utility»: قيمة تدوم، أو فائدة كافية. للإصلاح، أضف عمقًا إلى الإجراء الرئيسي، لا شاشات حوله. هنا: سجلّ، ومفضلات، وتذكير في الوقت الذي تختاره، وwidget على الشاشة الرئيسية.

التطبيق المولَّد بالذكاء الاصطناعي دون أي شيء أصلي

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

أشرح ما يُجيده الذكاء الاصطناعي وما يفوته في إنشاء تطبيق بالذكاء الاصطناعي. وتجد مقارنة الصيغة التي ينتجها كل مولّد، تطبيق ويب أو مشروع جوال، في Lovable أو Rork أو FlutterFlow.

القشرة التي تنتظر المحتوى

مثال: سوق إلكتروني بلا إعلانات، أو دليل فارغ، أو موجز يعرض «قريبًا». يفتح المراجع تطبيقًا لا يملك ما يعرضه. هذه الحالة تمسّ أيضًا الإرشادة 2.1، التي ترفض المحتوى المؤقت: راجع دليل الإرشادة 2.1. أرسل التطبيق حين يكون فيه محتوى حقيقي، أو قدّم حساب تجربة مملوءًا مسبقًا.

الاختبار الذي أجريه: «وماذا لو كان في Safari؟»

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

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

توصيات Apple تسير في الاتجاه نفسه. الـ widget يعرض محتوى آنيًا يُقرأ بنظرة واحدة. والـ إشعار يقدّم معلومة مفيدة بكلمات قليلة، ولا يُستعمل لدفع المستخدم نحو مهمة داخل التطبيق.

ما تفعله تطبيقاتي ولا يفعله موقع

أصمّم كل تطبيق حول وظيفة رئيسية لا وجود لها في المتصفح، أو حول قيمة تجعل المستخدم يعود.

• Solys منبّه. يمرّ الرنين عبر AlarmKit، خدمة المنبّه في iOS 26: يتجاوز الوضع الصامت، مثل منبّه Apple. لإيقافه، يجب أن تفوز في لعبة صغيرة، وتبقى التطبيقات المختارة متوقفة بعد الاستيقاظ. لا توجد صفحة ويب تجعل iPhone يرنّ وهو في الوضع الصامت.
• TradaZen محاكي تداول: رسم بياني حقيقي في تاريخ حقيقي، وقرار، وشموع تتكشّف، ومبارزات مصنّفة، ورتبة تتقدّم. هنا ليست ميزة أصلية ما يحمل التطبيق، بل قيمة الترفيه الدائمة التي تتحدث عنها الإرشادة 4.2.
• Nolera خزانة ملابس: تصوّر ملابسك، فيقصّها التطبيق ويرتّبها، ثم يقترح عليك إطلالة كل صباح. الكاميرا جزء من الإجراء الرئيسي، وليست إضافة.

لا تشترط الإرشادة 4.2 قائمة من الميزات الأصلية: بل تشترط سببًا لتثبيت التطبيق بدلًا من فتح موقع.

إصلاح رفض 4.2 خطوة بخطوة

1. حدّد العائلة. تصفح ويب: إنه الموقع المغلّف. محتوى أو ميزات قليلة: إنه التطبيق الهزيل. الإرشادة 4.2.3: اعتماد على تطبيق آخر أو تنزيل غير مُعلن.
2. غيّر المنتج، لا الصياغة. الرد الذي يجادل دون أن يغيّر شيئًا لا سبب لأن يقنع أحدًا. أعد بناء شاشات الإجراء الرئيسي بشكل أصلي، أو أضف العمق الناقص.
3. خطّط لـ build جديد. السبب داخل التطبيق: التحديث عن بُعد لا يكفي. كل إرسال يعود إلى قائمة الانتظار، راجع مدة مراجعة App Store.
4. اكتب ملاحظات مراجعة ترشد المراجع. تطلب Apple، في صفحتها عن المعلومات اللازمة لمراجعة كاملة، أن تصف الفكرة والميزات والجمهور. وفي حالة التحديث: ما الذي تغيّر، وأين تجده.
5. لا تستأنف إلا إذا فات المراجعَ شيء. إن كانت ميزتك الأصلية موجودة أصلًا ولم يرها، فردّ في App Store Connect بفيديو قصير. الاستئناف أمام App Review Board مبرَّر حين يُساء فهم تطبيقك، لا حين يكون هزيلًا.

نموذج الملاحظات الذي كنت سأستخدمه، بالإنجليزية، لتكييفه:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

لا تكتب إلا ما هو موجود في الـ build المُرسل. الميزة المُعلنة التي لا يمكن العثور عليها ستكلّفك رفضًا جديدًا، بموجب الإرشادة 2.1 هذه المرة.

قائمة تحقق 4.2 قبل الإرسال

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

اجتياز 4.2 من إرسالك القادم

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

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

لا أحد يستطيع أن يضمن أن Apple ستقبل تطبيقك. لكن يمكنني مساعدتك على منحه سببًا للوجود على App Store.

الأسئلة الشائعة

ماذا يعني «Guideline 4.2 - Design - Minimum Functionality»؟

إنه عنوان الرفض بسبب الحد الأدنى من الوظائف. ترى Apple أن تطبيقك يشبه موقع ويب أكثر من اللازم، أو يقدّم محتوى أو ميزات قليلة جدًا. وقد يستهدف العنوان نفسه قاعدة فرعية: «Guideline 4.2.2» لتطبيق واجهة عرض أو قائمة روابط، و4.2.3 لتطبيق يعتمد على تطبيق آخر.

هل يُرفض التطبيق المبني على WebView دائمًا؟

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

هل تكفي إضافة الإشعارات الفورية لاجتياز 4.2؟

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

ما الفرق بين الإرشادة 4.2 والإرشادة 4.3؟

الإرشادة 4.2 تحكم على تطبيقك وحده: هل يقدّم ما يكفي مقارنة بموقع ويب؟ والإرشادة 4.3 تقارنه بغيره: هل هو نسخة، أو تنويع، أو تطبيق إضافي في فئة مشبعة؟ قد يتلقى التطبيق نفسه الرفضين، لكنهما لا يُصلحان بالطريقة نفسها.

هل يلزم build جديد بعد رفض 4.2؟

في أغلب الأحيان نعم، لأن السبب داخل التطبيق نفسه. الاستثناء الوحيد: أن المراجع لم يجد ميزة كانت موجودة أصلًا. في هذه الحالة، ردّ في App Store Connect بملاحظات دقيقة وفيديو قصير، دون تغيير الـ build.