قبل أن تبني تطبيقاً: ستّ عقبات ليست في الكود

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

1. حسابات المتاجر ليست تفصيلاً إدارياً

لنشر تطبيق تحتاج حسابَي مطوّر: Apple بتسعة وتسعين دولاراً سنوياً، وGoogle بخمسة وعشرين دولاراً مرّة واحدة. هذه أرقام معلنة وثابتة، ولا تُدفع لنا بل للمنصّتين مباشرة.

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

والأثر العملي أهمّ من الشرط نفسه. حين يكون الحساب باسمك:

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

فتح الحسابات يستغرق وقتاً — تحقّقاً من الهويّة، ووثائق للكيان التجاري، وأحياناً أسابيع عند آبل للحسابات المؤسّسية. يُبدأ به في اليوم الأوّل، لا في الأسبوع الأخير.

2. البيع داخل التطبيق يحتاج ח.פ وحساب مقاصّة — والبناء لا ينتظرهما

هذه أكثر عقبة رأيناها تُفاجئ أصحاب المشاريع.

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

ما يحدث عملياً: يُبنى المتجر بالكامل، ويُختبر، ويعمل — ولا يستطيع قبض شيكل واحد. التطبيق جاهز ومعطّل في آن.

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

القاعدة: ملفّ المقاصّة يُفتح بالتوازي مع بدء التطوير، لا بعده. وإن لم يكن لدى النشاط ח.פ بعد، فهذا أوّل بند في الجدول الزمني، لا آخره.

3. آبل تأخذ ثلاثين بالمئة على ما هو رقمي

تفصيل صغير يقلب نموذج الربح كلّه.

• بيع بضاعة ملموسة — ملابس، طعام، قطع، خدمة تُؤدّى في العالم الحقيقي — يمرّ بالدفع العادي، وآبل لا تأخذ منه شيئاً.
• بيع منتج رقمي — اشتراك، كورس، محتوى مدفوع، ميزة داخل التطبيق — يجب أن يمرّ عبر In-App Purchase، وآبل تقتطع عمولتها.

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

4. الكتالوج هو المشروع، لا الشاشات

يسأل معظم الناس عن عدد الشاشات. السؤال الأهمّ: من يملأ التطبيق، وكلّ كم؟

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

الأسئلة التي تُحسم مبكّراً:

• هل المحتوى جاهز فعلاً — صور وأوصاف وأسعار — أم ما زال يُجمَع؟
• من داخل النشاط مسؤول عن التحديث، وفي أيّ وقت من أسبوعه؟
• هل هناك نظام قائم (كاشير، مخزون) يمكن السحب منه، أم سيُدخَل كلّ شيء يدوياً؟

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

5. مراجعة المتاجر ليست جدولك

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

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

لهذا نفصل دائماً بين الرقمين: مدّة البناء التزامنا، ومدّة المراجعة ليست بأيدينا. وكلّ من يَعِدك بتاريخ ظهور في المتجر إمّا لا يعرف، أو يعرف ولا يقول.

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

6. التطبيق الذي لا يُحدَّث يُسحب

التطبيق ليس موقعاً. الموقع المنشور يظلّ يعمل سنوات دون أن يلمسه أحد. التطبيق لا.

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

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

ما الذي يُحسم قبل كتابة سطر واحد

لا شيء في هذا الجدول برمجي. وكلّ بند فيه قادر وحده على تأخير مشروع جاهز تقنياً أشهراً.

خلاصة

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

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