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

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

السؤال الذي يسبق «أي تطبيق أبني؟»

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

الخلط بين السؤالين مكلف. صاحب متجر يبدأ بسؤال «Flutter أم React Native؟» يكون قد أنفق على إجابة قبل أن يتأكد أن السؤال يخصه.

ما الذي يفصل الموقع عن التطبيق فعلاً

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

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

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

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

خمس حالات يصبح فيها التطبيق قراراً صحيحاً

1. الاستخدام يتكرر من الأشخاص أنفسهم

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

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

2. الإشعار جزء من الخدمة نفسها

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

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

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

3. العمل يستمر في مكان بلا شبكة مستقرة

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

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

4. تحتاج عتاداً خارج المألوف

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

القاعدة العملية: اكتب الأجهزة التي سيلمسها البرنامج، ثم اسأل مطورك عن حالة دعم كل واحد منها على الويب قبل أن تقرر.

5. التطبيق نفسه هو المنتج

إذا كان ما تبيعه هو التجربة على الهاتف نفسها (لعبة، أو منتج اشتراك رقمي، أو أداة تقوم على الاستخدام اليومي)، فأنت لا تختار قناة توصيل، أنت تبني المنتج. هنا لا يوجد سؤال.

ما تحتاجههل ينجزه الموقع اليوم؟مصدر الحكم
إشعارات فوريةنعم، مع شرط الإضافة إلى الشاشة الرئيسية على iPhoneتوثيق WebKit
فتح المحتوى من دون اتصالنعم، عبر Service Workerتوثيق MDN
مزامنة ما جُمع بعد إغلاق الجلسةمحدود، وغير مدعوم في كل المتصفحاتتوثيق MDN
الكاميرا وتحديد الموقعنعمتوثيق MDN
أجهزة بلوتوث وطابعات إيصالاتتجريبي ومحدودتوثيق MDN
الظهور لمن لا يعرف اسمكنعم، عبر الفهرسة في البحثتوثيق Google

لمن هذا التطبيق فعلاً: عملاؤك أم فريقك؟

في نصف الحالات التي يبدأ فيها النقاش بسؤال «تطبيق للعملاء؟» تكون الحاجة الحقيقية عند من يعمل عندك، لا عند من يشتري منك.

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

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

أربعة أسباب تجعل الموقع القرار الأذكى

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

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

هل تخطط لبناء أو تطوير مشروع رقمي؟

فريق سنابل يوفر لك دراسة فنية مخصصة لتحديد التقنيات المناسبة وتكلفة التنفيذ الدقيقة.

تواصل عبر واتساباستكشف خدماتنا

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

الفكرة ما زالت تحت الاختبار. ما دامت الخدمة نفسها تتغير كل أسبوعين، فالويب يمنحك حرية تغيير المسار بلا دورة مراجعة في كل مرة.

فاتورة الاستمرار التي لا تظهر في عرض السعر

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

تفصيل ما تدفعه سنوياً بعد الإطلاق في دليل تكلفة صيانة التطبيق، وخطوات النشر نفسها في دليل النشر على المتاجر.

عمولة المتاجر: القاعدة التي يخطئ فيها أغلب من ينصحك

«المتاجر تقتطع نسبة من كل عملية بيع» جملة تتكرر في كل نقاش عن التطبيقات، وهي في حالة أغلب من يقرأ هذه الصفحة غير صحيحة.

القواعد المنشورة تقول العكس تماماً لمن يبيع سلعاً أو خدمات تُستهلك خارج التطبيق. في إرشادات مراجعة App Store، البند 3.1.3(e) ينص على أن التطبيق الذي يتيح شراء سلع مادية أو خدمات تُستهلك خارجه «يجب» أن يستخدم وسيلة دفع غير الشراء داخل التطبيق. وسياسة المدفوعات في Google Play تقابلها: نظام فوترة Play يُمنع استخدامه عندما يكون الدفع مقابل سلع مادية مثل البقالة والملابس، أو خدمات مادية مثل النقل وتوصيل الطعام وتذاكر الفعاليات.

يعني ذلك أن مطعماً أو متجر ملابس أو عيادة يبيع كل منهم عبر بوابة الدفع التي يتعاقد معها مباشرة، مثل Paymob أو Fawry أو غيرهما، ولا يدفع للمتجر نسبة من الطلب.

العمولة تخص من يبيع محتوى رقمياً أو اشتراكاً يُستهلك داخل التطبيق. وحتى هنا النسبة الشائعة ليست 30%: برنامج Apple للشركات الصغيرة يخفض العمولة إلى 15% لمن لم تتجاوز أرباحه مليون دولار في السنة السابقة، ورسوم خدمة Google Play هي 15% على أول مليون دولار من الأرباح السنوية و30% على ما يزيد، مع 15% على تجديد الاشتراكات.

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

الشرط الذي يسقط «غلّفوا لي الموقع في تطبيق»

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

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

ستة أسئلة قبل أن تدفع

جاوب بنعم أو لا، من واقع ما تعرفه عن عملائك لا عما تتمناه:

  1. هل يحتاج العميل الواحد فتح ما تبنيه مرتين في الشهر على الأقل؟
  2. هل تفقد الخدمة معناها إذا تأخر إشعار أو لم يصل؟
  3. هل يعمل مستخدموك في أماكن تنقطع فيها الشبكة، ويجب أن يستمر التسجيل والإرسال بعدها؟
  4. هل يتعامل البرنامج مع جهاز غير الكاميرا وتحديد الموقع؟
  5. هل جمهورك موجود لديك بالفعل (قائمة عملاء، موظفون، مشتركون) فلا تحتاج أن يكتشفك أحد عبر البحث؟
  6. هل التطبيق هو المنتج الذي يدفع الناس مقابله؟

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

مثال افتراضي على تطبيق الأسئلة

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

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

الحالتان متقاربتان في الحجم والميزانية. ما فرّق بينهما هو عدد المرات التي يُفتح فيها البرنامج، والظروف التي يُفتح فيها.

إشارات تقول إن الوقت جاء

لا تحتاج إلى حدس هنا. الإشارات تظهر في بياناتك ومكالماتك:

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

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

بعد أن يستقر القرار

إذا كانت الإجابة الموقع، فاختيار نوعه هو الخطوة التالية، وشرحناه في أنواع المواقع الإلكترونية.

وإذا كانت الإجابة التطبيق، فالترتيب المنطقي: حدد الطريقة في تطبيق أصلي أم متعدد المنصات، وقارن التكلفة مع البديل الأخف في PWA أم تطبيق أصلي، ثم راجع خطوات بناء التطبيق وتفصيل بنود التكلفة قبل التعاقد.

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

أسئلة شائعة

هل يمكن أن أبدأ بموقع ثم أضيف التطبيق لاحقاً من غير إعادة البناء؟

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

هل وجود التطبيق يساعد ظهوري في Google؟

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

عميلي في الخليج ويطلب تطبيقاً لأن منافسه لديه تطبيق. ماذا أقول له؟

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

هل التطبيق يرفع ثقة العملاء حتى لو لم يستخدموه كثيراً؟

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

المصادر