بناء تطبيق موبايل: القرارات التي تفرضها قواعد المتاجر قبل أن تبدأ البرمجة

ما يعطّل التطبيقات عند الإطلاق في أغلب الحالات بند منشور منذ سنوات في إرشادات المتجر، لم ينتبه إليه أحد إلا بعد أن صار تعديله مكلفاً: صفحة ويب لحذف الحساب لم تُبنَ، إذن يحتاج نموذج إقرار وموافقة من جوجل قبل النشر، نموذج ربح كامل يصطدم بنظام دفع المتجر.

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

ما لن تجده هنا: نطاقات التكلفة والمدة الزمنية واختيار التقنية. لكلٍّ منها صفحته المستقلة، وستجد روابطها في مواضعها. أما خطوات الرفع نفسها (فتح الحسابات وتجهيز الأصول والتوقيع الرقمي) ففي دليل نشر تطبيقك على App Store وGoogle Play.

1. باسم من يُفتح حساب المطوّر

هذا أول القرارات وأكثرها إهمالاً، لأنه يبدو إجراءً إدارياً. عند آبل هو شرط مراجعة صريح: إرشادات مراجعة التطبيقات تنصّ في البند 5.1.1(ix) على أن التطبيقات التي تقدّم خدمات في مجالات شديدة التنظيم، ومنها الخدمات المصرفية والمالية والرعاية الصحية وتذاكر الطيران ومنصات تداول العملات الرقمية، ينبغي أن يقدّمها الكيان القانوني الذي يقدّم الخدمة، لا مطوّر فرد. عيادة أو شركة تأمين أو تطبيق محفظة يسجّل باسم المبرمج الذي بناه يدخل المراجعة من الباب الخطأ.

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

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

2. هل يحتاج تطبيقك حسابات من الأصل

سؤال «هل تحتاج النسخة الأولى حسابات أصلاً» تناولناه في تحديد ما يدخل النسخة الأولى وما يُؤجَّل. ما يعنينا هنا ما يترتّب على الإجابة بنعم: يربط البند 5.1.1(v) عند آبل بين الأمرين مباشرة، فمن يفتح باب إنشاء الحسابات يلتزم بإتاحة حذفها من داخل التطبيق.

شرط جوجل أوسع. تقول سياسة بيانات المستخدم في Google Play إن على المستخدم أن يجد خياراً واضحاً لبدء الحذف من داخل التطبيق ومن خارجه، عبر مورد ويب يُدخل رابطه في حقل مخصص داخل Play Console، وإن حذف الحساب يستلزم حذف البيانات المرتبطة به، وإن التعطيل المؤقت أو «تجميد» الحساب لا يُعد حذفاً.

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

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

3. كيف يسجّل الناس الدخول

إن قرّرت أن التطبيق يحتاج حسابات، فالقرار التالي هو وسيلة الدخول، وله شرط منشور عند آبل كثيراً ما يُكتشف متأخراً. البند 4.8 يقول إن التطبيق الذي يستخدم خدمة تسجيل دخول من طرف ثالث أو خدمة اجتماعية مثل Google Sign-In أو Facebook Login لإنشاء الحساب الأساسي للمستخدم أو التحقق منه، يجب أن يقدّم إلى جانبها خياراً مكافئاً يقصر جمع البيانات على الاسم والبريد، ويتيح للمستخدم إبقاء بريده خاصاً، ولا يجمع تفاعلاته مع التطبيق لأغراض إعلانية دون موافقة.

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

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

4. أي الأذونات تفتح باباً لمراجعة إضافية

في Play Console أذونات لا تُطلب وتُنسى، بل يفتح طلبها نموذج إقرار ومراجعة قبل النشر. من الصفحة نفسها:

• الصور والفيديو: من يستهدف Android 13 أو أحدث لا يطلب READ_MEDIA_IMAGES وREAD_MEDIA_VIDEO إلا إذا كانت أدوات الاختيار النظامية، ومنها Android Photo Picker، غير كافية للوظيفة الأساسية، ومن يطلبها عليه تقديم إقرار في Play Console يوضح لماذا لم تكفِ.
• الموقع في الخلفية: تقول جوجل صراحة إنها قد ترفض التطبيقات التي تطلب الموقع في الخلفية دون مبرر مقنع، وإن هذا الطلب يحتاج إقراراً مخصصاً في الكونسول.
• الوصول إلى كل الملفات: MANAGE_EXTERNAL_STORAGE يحتاج اجتياز مراجعة وصول قبل النشر، لا مجرد إعلانه في ملف البيان.

وآبل تدفع في الاتجاه نفسه من زاوية التصميم: البند 5.1.1(iii) يطلب الاكتفاء بالبيانات المتصلة بالوظيفة الأساسية، واستخدام أداة الاختيار التي تعمل خارج التطبيق أو ورقة المشاركة بدل طلب وصول كامل إلى الصور وجهات الاتصال.

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

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

5. الإشعارات قناة غير مضمونة

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

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

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

6. العربية واتجاه الواجهة قرار بناء لا لمسة نهائية

من يخدم مصر والخليج يفترض أن «تعريب التطبيق» بند ترجمة في آخر المشروع. الاتجاه ليس ترجمة.

على أندرويد، السمة android:supportsRtl قيمتها الافتراضية false، ولا تعمل واجهات البرمجة الخاصة بالاتجاه من اليمين إلى اليسار إلا إذا ضُبطت على true وكان targetSdkVersion 17 أو أعلى. وما دامت false، تبقى التخطيطات كما هي مهما اختار المستخدم من لغة.

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

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

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

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

7. قناة الدفع تحدد نموذج الربح كله

القاعدة نفسها بسيطة، وأثرها على دراسة الجدوى كبير. البند 3.1.1 عند آبل يقول إن فتح خاصية أو محتوى داخل التطبيق يمر عبر الشراء داخل التطبيق، وإن استخدام آليات خاصة لفتحه، مثل مفاتيح الترخيص أو رموز QR، غير مسموح. والبند 3.1.3(e) يقول العكس لمن يبيع سلعاً أو خدمات مادية تُستهلك خارج التطبيق: هذه يجب أن تُحصَّل بوسيلة دفع أخرى غير الشراء داخل التطبيق.

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

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

8. التصنيف العمري والجمهور المستهدَف

هذا أحدث ما تغيّر، ويخصّ كل من سيرفع تحديثاً هذا الشهر. غيّرت آبل نظام التصنيف العمري فأضافت 13+ و16+ و18+ إلى 4+ و9+ القائمة، مع أسئلة جديدة في الاستبيان عن أدوات التحكم داخل التطبيق والقدرات والمواضيع الطبية ومشاهد العنف. وفي تحديث يوليو 2026 أضافت أسئلة عن خصائص التواصل الاجتماعي في التطبيق، وأكدت أن الإجابات صارت مطلوبة منذ سبتمبر 2026 عند تقديم أي تطبيق جديد أو تحديث.

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

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

ترتيب القرارات وثمن تأجيل كل واحد

ويبقى ما يُجهَّز يوم الرفع نفسه: رابط سياسة خصوصية حيّ ومطابق، وحساب تجريبي للمراجع مع تشغيل الخدمة الخلفية (أو وضع عرض مدمج بموافقة مسبقة من آبل، كما ينصّ البند 2.1(a))، وإقرارات الخصوصية في المتجرين، ورابط حذف الحساب في Play Console. جوجل تشترط أن تكون سياسة الخصوصية على رابط فعّال وعام غير مقيّد جغرافياً، لا ملف PDF ولا صفحة قابلة للتعديل، وأن يظهر فيها اسم الكيان المذكور في صفحة المتجر. تفاصيل هذه المرحلة في دليل النشر، وما يأتي بعدها من التزامات سنوية في تكلفة صيانة تطبيق موبايل.

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

المصادر

• App Review Guidelines، بنود آبل 2.1 و3.1.1 و3.1.3(e) و4.5.4 و4.8 و5.1.1 و5.1.2.
• Sign and update agreements في مركز مساعدة App Store Connect.
• Right to left ضمن Human Interface Guidelines من Apple.
• Updated age ratings in App Store Connect وAge rating questionnaire now includes social media questions في Apple Developer News.
• User Data وPermissions and APIs that Access Sensitive Information وPayments ومتطلبات التقييم حسب الفئة العمرية ضمن سياسات Google Play.
• إذن تشغيل الإشعارات وعنصر <application> ودعم لغات وثقافات مختلفة في توثيق Android Developers.