قائمة تحقق تطبيق الجوال للشركات الناشئة: 34 بندًا من MVP حتى موافقة App Store (2026)

قائمة تحقق تطبيق الجوال للشركات الناشئة: 34 بندًا من MVP حتى موافقة App Store (2026)

البند 5.1.1(v) من إرشادات مراجعة App Store من Apple قضى على مواعيد إطلاق لشركات ناشئة أكثر من أي خطأ برمجي واجهناه. زر حذف حساب واحد ناقص، يُرسَل ليلة يوم العرض التجريبي، فينزلق الجدول الزمني أسبوعًا كاملًا. قائمة تحقق تطبيق الجوال للشركات الناشئة هذه وُجدت لأن هذا الخطأ يمكن تجنبه بالكامل، ومع ذلك لا يكاد أحد يدوّن رقم الإرشاد الذي يسببه.

أهم النقاط:

• Apple ترفض التطبيقات التي تفتقر إلى تدفقات حذف الحساب وروابط سياسة الخصوصية: البندان 5.1.1 و1.5 ينصّان على ذلك صراحة.
• Google Play يشترط مسار حذف حساب داخل التطبيق ومسارًا عامًا عبر الويب، مع تطبيق إلزامي بعد مهلة 31 مايو 2024.
• قوائم تقديم iOS وAndroid تختلفان؛ والتعامل معهما كقائمة واحدة مجمّعة هو السبب الأول لتأخيرات الإطلاق في اللحظة الأخيرة.

قبل أن تكتب سطرًا واحدًا من الكود

قبل تصميم أي شاشة، هناك ثلاثة أمور يجب حسمها: ما هو MVP فعليًا، وهل تحتاج سياسة خصوصية (نعم تحتاج)، وهل ينطبق GDPR أو قانون KVKK التركي على مستخدميك. تخطّي هذه المرحلة هو ما يجعل المؤسسين يتسابقون لكتابة الصفحات القانونية في الأسبوع الذي أرادوا فيه التقديم.

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

إرشادات Apple نفسها صريحة بشأن شرط سياسة الخصوصية: البند 5.1.1(i) ينص على أن التطبيقات "يجب أن تتضمن رابطًا لسياسة الخصوصية الخاصة بها" في بيانات App Store Connect الوصفية، وفي كثير من الحالات داخل التطبيق نفسه. هذا ليس اقتراحًا. إنه عائق تقديم إذا كان مفقودًا.

• حدّد نطاق MVP في جملة واحدة
• تأكّد أنك تحتاج سياسة خصوصية (تحتاجها دائمًا تقريبًا)
• أعدّ رابط دعم (إرشاد Apple 1.5 يشترطه)
• تحقّق من انطباق GDPR/KVKK إذا كان لديك مستخدمون في الاتحاد الأوروبي أو تركيا
• قرّر بين الأصلي (native) أو متعدد المنصات (cross-platform)

أسبوع بناء MVP

أسبوع بناء MVP هو المرحلة التي تقرر فيها ما الذي سيُشحَن فعليًا وما الذي سيُحذَف، والإجابة الصادقة هي: أكثر مما يتوقعه المؤسسون. التحليلات وتقارير الأعطال تُدمَج أثناء البناء، وليس بعده. إضافتها بعد الإطلاق تعني أنك تفقد البيانات ذاتها التي كنت بحاجة إليها للتحقق من افتراضك الأول.

ما نحذفه فعليًا من نطاق v1، في معظم الأحيان، هو كل شيء ليس الشيء الواحد الذي يُختبَر. الإشعارات الفورية، تسجيل الدخول الاجتماعي، شاشة إعدادات بستة مفاتيح تبديل، كل ذلك يمكن أن ينتظر. المؤسسون يقاومون هذا، وهذا مفهوم؛ يبدو وكأنك تُطلق شيئًا غير مكتمل. وهو غير مكتمل. هذه هي الفكرة.

كما عبّر أحد المؤسسين الذين أطلقوا عدة تطبيقات في منشور قائمة تحقق على dev.to، فإن تخطّي آلية جمع الملاحظات مبكرًا خطأ "ندم عليه في كل مرة". ادمجها الآن، وليس بعد وصول أول مراجعة. إذا أردت تسريع محادثة تحديد النطاق نفسها، فإن استخدام الذكاء الاصطناعي لتسريع تحديد النطاق يستحق الاطلاع قبل بدء البناء.

• ادمج التحليلات قبل أول نسخة TestFlight/داخلية
• اربط تقارير الأعطال (Sentry أو Firebase Crashlytics)
• ابنِ آلية ملاحظات داخل التطبيق
• احذف أي ميزة ليست جوهرية للشيء الواحد الذي تختبره
• اكتب أول سلسلة إصدار (انظر الإصدارات أدناه)

الأسبوع الذي يسبق التقديم

هذه المرحلة التي تتخطاها كل قوائم المنافسين بالكامل، وهي حيث تحدث أكثر التأخيرات القابلة للمنع. الإصدار الدلالي (Semantic Versioning) للتطبيقات يتبع نمط MAJOR.MINOR.BUILD (‏1.0.0، ثم 1.0.1 لإصلاح، و1.1.0 لإضافة ميزة). اختر نظامًا الآن، لأن أرقام الإصدارات غير المتسقة تربك كلا متجري التطبيقات وفريقك.

الإطلاق المتدرّج يُصدر تحديثك لنسبة صغيرة من المستخدمين أولًا (غالبًا 1%، ثم 10%، ثم 50%) قبل الوصول إلى الجميع. واحدة فقط من قوائم المنافسين الثلاث التي راجعناها تذكره، وحتى ذلك بشكل عابر. إذا تسرّب عطل، فإن الإطلاق المتدرّج يحدّ من نطاق التأثير بدلًا من إصابة 100% من المستخدمين دفعة واحدة.

الأسئلة التي نطرحها قبل الموافقة على تقديم عميل بسيطة: هل المسار الحرج يعمل من البداية إلى النهاية، الآن، على جهاز حقيقي؟ ليس المحاكي. هل معدل الجلسات الخالية من الأعطال مقبول؟ هل أصول قائمة المتجر نهائية فعلًا، وليست عناصر نائبة؟

• تأكّد أن رقم الإصدار يتبع نظامًا متسقًا
• اختبر مسارك الحرج من البداية إلى النهاية مرة أخيرة
• أعدّ نسبة الإطلاق المتدرّج إذا كان المتجر يدعمها
• تأكّد أن معدل الجلسات الخالية من الأعطال مقبول قبل التقديم
• التقط لقطات شاشة وأعدّ جميع أصول قائمة المتجر

يوم التقديم: iOS مقابل Android

تقديمات iOS وAndroid تفشل لأسباب مختلفة، والتعامل معها كقائمة تحقق واحدة مجمّعة هو أكبر سبب منفرد لتأخيرات الإطلاق في اللحظة الأخيرة التي نراها. إرشادات مراجعة App Store من Apple وسياسات مطوّري Google Play كل منهما يسمّي متطلبات محددة وقابلة للتحقق، ومعظم المؤسسين لا يكتشفونها إلا بعد رسالة رفض.

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

إرشادات مراجعة App Store من Apple محددة: البند 5.1.1(v) يشترط على التطبيقات التي تدعم إنشاء حساب أن توفر أيضًا حذف حساب داخل التطبيق، البند 1.6 يغطي إفصاحات أمان البيانات، والبند 1.5 يشترط رابط دعم فعّال. على Android، سياسة مطوّري Google Play تشترط مسار حذف داخل التطبيق ورابط ويب عام لطلبات حذف الحساب. أعلنت Google عن الشرط في أبريل 2023، وحددت مهلة 7 ديسمبر 2023 لأسئلة حذف البيانات في نموذج أمان البيانات، وسمحت بتمديدات حتى 31 مايو 2024، وبعدها تواجه التطبيقات غير الممتثلة إجراءات تنفيذية. هذه ليست قاعدة قديمة أُعفيت منها التطبيقات الصغيرة؛ لا تزال سارية.

مسارا التقديم يختلفان أيضًا ميكانيكيًا، وليس على الورق فقط. على iOS، ترفع نسخة عبر Xcode أو Transporter، ويعالجها App Store Connect (يستغرق هذا من بضع دقائق إلى أكثر من ساعة)، ومن هناك إما توجّهها إلى TestFlight للمختبرين الداخليين والخارجيين أو تقدّمها مباشرة لمراجعة App Review.‏ TestFlight ليس عملًا روتينيًا اختياريًا: إنه الطريقة التي تتوقعها Apple لاكتشاف الأخطاء التي كان سيرفضك المراجع بسببها. على Android، يعمل Google Play Console بمسارات (tracks) بدلًا من تقديم واحد، متنقلًا بين الاختبار الداخلي، ثم الاختبار المغلق أو المفتوح، ثم الإنتاج، وكل منها له جمهوره وخطوة ترقية خاصة به. الإطلاق المتدرّج لا يظهر إلا عند تحديث إصدار إنتاجي قائم. كما تقول وثائق إصدار Google نفسها، "إذا كنت تُطلق إصدارك الأول، فلن ترى خيار تحديد نسبة الإطلاق"، لذا لا تبنِ أول إطلاق لك على تدرّج نسبي، ذلك يأتي لاحقًا.

الأوراق، وليس الكود، هي ما يعرقل فعليًا معظم التقديمات الأولى. Apple تشترط بيان خصوصية (privacy manifest) لقائمة محددة من حزم SDK الشائعة الاستخدام من أطراف ثالثة (شبكات إعلانية، تحليلات، أدوات تقارير أعطال)، وإرشاداتها صريحة بشأن من يتحمل المسؤولية: "عندما تستخدم حزمة SDK من طرف ثالث مع تطبيقك، أنت مسؤول عن جميع الأكواد التي تتضمنها الحزمة في تطبيقك، ويجب أن تكون على دراية بممارسات جمع البيانات واستخدامها"، وفقًا لـصفحة متطلبات حزم SDK من Apple. تخطَّ بيان خصوصية لحزمة مدرجة ولن تجتاز نسختك App Store Connect. ما يعادله على Google Play هو نموذج أمان البيانات (Data safety form)، وهو إلزامي لكل تطبيق على كل مسار باستثناء نسخ الاختبار الداخلي فقط: "جميع المطورين الذين لديهم تطبيق منشور على Google Play يجب أن يكملوا نموذج أمان البيانات، بما في ذلك التطبيقات على مسارات الاختبار المغلقة أو المفتوحة أو الإنتاجية"، وفقًا لـوثائق أمان بيانات Google Play. أخطئ فيه وتقول Google صراحة إنها "قد تتخذ الإجراءات المناسبة، بما في ذلك إجراءات تنفيذية" بمجرد ظهور عدم تطابق بين سلوك تطبيقك المُعلَن والفعلي.

هناك وضع فشل ثالث لا علاقة له بنص السياسة: المراجع حرفيًا لا يستطيع اختبار تطبيقك. البند 2.1 من Apple يوضح هذا مباشرة: "أدرج معلومات حساب تجريبي (وشغّل خدمتك الخلفية!) إذا كان تطبيقك يتضمن تسجيل دخول." لا بيانات اعتماد تجريبية فعّالة، لا خادم خلفي حي أثناء نافذة المراجعة، لا رابط دعم قابل للوصول، وستُرفَض بغض النظر عن مدى امتثال تدفق حذف الحساب. إذا كان أي جزء من تطبيقك خلف جدار دفع أو بوابة تسجيل دخول، اكتب ملاحظات للمراجع تشرح بالضبط كيفية الوصول إليه. إنها خطوة تستغرق دقيقتين يتخطاها المؤسسون لأول مرة باستمرار.

بوابة أخرى خاصة بـAndroid تنتمي إلى المحادثة نفسها: مستوى API المستهدف. وثائق مطوّري Android تنص على أن "التطبيقات الجديدة وتحديثات التطبيقات يجب أن تستهدف" مستوى Android API المطلوب حاليًا "لتقديمها إلى Google Play"، وأن "التطبيقات غير المحدّثة تصبح غير متاحة للمستخدمين الجدد على الأجهزة التي تعمل بإصدارات أحدث من Android." لا علاقة له بحذف الحساب أو أمان البيانات، لكنه يمنع التقديم بنفس الحسم، وهو من نوع المتطلبات التي تتغير كل عام، لذا تحقّق من الرقم الحالي قبل بناء إصدارك.

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

قائمة تقديم iOS:

• رابط سياسة الخصوصية حي وقابل للوصول
• مسار حذف حساب داخل التطبيق مُشحَن (البند 5.1.1(v))
• رابط الدعم حي (البند 1.5)
• إفصاحات أمان البيانات مكتملة (البند 1.6)
• نسخة TestFlight معتمدة قبل التقديم العام

قائمة تقديم Android:

• نموذج أمان البيانات مكتمل في Play Console
• مسار حذف حساب داخل التطبيق مُشحَن
• رابط ويب عام لطلبات حذف الحساب حي (شرط Google Play)
• نسبة الإطلاق المتدرّج محددة
• مستوى API المستهدف يلبي شرط Play الحالي

يوم الإطلاق

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

راقب لوحة App Store Connect أو Play Console كل ساعة، وليس يوميًا، خلال أول 24 ساعة. إذا انخفض معدل الجلسات الخالية من الأعطال، تريد أن تعرف خلال الساعة، وليس في الصباح التالي عندما يكون مئة مستخدم إضافي قد واجهوا الخطأ نفسه. أبقِ نسخة تراجع جاهزة. انضباط التثبيت ثم الاستقرار ثم النشر الذي نستخدمه لميزات الذكاء الاصطناعي ينطبق هنا بنفس الدرجة.

• راقب معدل الجلسات الخالية من الأعطال كل ساعة خلال أول 24 ساعة
• اجعل قناة الدعم مزوّدة بفريق وجاهزة
• تأكّد أن إطلاقك المتدرّج يتوسع كما هو مخطط
• أبقِ نسخة تراجع جاهزة في حالة وجود خلل حرج

أسبوعك الأول بعد الإطلاق

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

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

• راجع تقارير الأعطال يوميًا خلال الأسبوع الأول
• ردّ على أول 10 مراجعات في المتجر شخصيًا
• صنّف وأصلح أي خلل حرج خلال 48 ساعة
• تأكّد أن عملية طلب حذف البيانات تعمل فعليًا من البداية إلى النهاية
• ضع وتيرة منتظمة لمقارنة بيانات التحليلات بفرضية MVP الأصلية

كيف تتعامل Techsy مع هذا

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

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

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

ما هو MVP ولماذا يهم في قائمة تحقق الإطلاق؟

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

لماذا تُرفض التطبيقات من App Store؟

أكثر الأسباب شيوعًا والقابلة للمنع هي غياب روابط سياسة الخصوصية (البند 5.1.1(i))، وعدم وجود حذف حساب داخل التطبيق (البند 5.1.1(v))، ورابط دعم غير قابل للوصول (البند 1.5). لا شيء من هذه يتطلب جهدًا هندسيًا لإصلاحه، إنها بنود قائمة تحقق، وليست أخطاء برمجية.

ماذا يحدث إذا لم أضف خيار حذف حساب إلى تطبيقي؟

على iOS، البند 5.1.1(v) يجعل هذا سبب رفض تلقائي إذا كان تطبيقك يدعم إنشاء حساب. على Android، يشترط Google Play مسار حذف داخل التطبيق ومسار ويب عام، والتطبيقات غير الممتثلة تواجه إجراءات تنفيذية بعد مهلة 31 مايو 2024، وإغفاله يمنع التقديم على كلتا المنصتين.

هل تحتاج الشركات الناشئة سياسة خصوصية لتطبيق جوال؟

نعم، دائمًا تقريبًا. Apple تشترط سياسة خصوصية مرتبطة بموجب البند 5.1.1(i)، وGoogle Play يشترط واحدة داخل نموذج أمان البيانات. إذا كنت تجمع أي بيانات مستخدم، حتى مجرد بريد إلكتروني للتسجيل، تحتاجها قبل التقديم.

ما الفرق بين التقديم لـApp Store مقابل Google Play؟

مراجعة Apple قائمة على إرشادات ببنود مسماة (5.1.1، 1.5، 1.6) ومراجع بشري؛ Google Play يعتمد على نموذج أمان البيانات وفحوصات آلية. شرط حذف الحساب متشابه في الروح لكنه مختلف في الآلية؛ انظر جدول المقارنة أعلاه.

كم تستغرق مراجعة متجر التطبيقات فعليًا؟

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

ما هو الإطلاق المتدرّج وهل يجب أن أستخدمه؟

الإطلاق المتدرّج يُصدر تحديثًا لنسبة صغيرة من المستخدمين أولًا، ثم يتوسع تدريجيًا، بدلًا من الوصول إلى 100% دفعة واحدة. استخدمه كلما دعمه المتجر؛ فهو يحدّ من عدد المستخدمين الذين يواجهون خللًا قبل أن تتمكن من الإيقاف والإصلاح.

هل أحتاج رابط دعم لتقديم تطبيقي؟

نعم. البند 1.5 من Apple يشترط رابط دعم فعّال كجزء من التقديم، وGoogle Play يتوقع جهة اتصال دعم أيضًا. رابط معطّل أو صندوق وارد غير مراقب هنا سبب رفض سهل وقابل للتجنب.

ماذا يجب أن أراقب في أسبوع تطبيقي الأول بعد الإطلاق؟

تقارير الأعطال يوميًا، أول عشر مراجعات في المتجر، وهل عملية طلب حذف البيانات تعمل فعليًا من البداية إلى النهاية. هذا أيضًا عندما تبدأ بمقارنة بيانات الاستخدام الفعلية بالافتراض الذي بُني MVP لاختباره.

هل GDPR أو KVKK ذو صلة بتطبيق شركة ناشئة صغيرة؟

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

الخلاصة

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

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