برمجة تطبيق جوال خطوة بخطوة: من الفكرة إلى App Store وGoogle Play

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

الخلاصة

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

حدّد المشكلة والنسخة الأولى (MVP) والنموذج الأولي

الخطوة الأولى في برمجة تطبيق هي تحديد المشكلة التي يحلّها؛ وتنبثق منها النسخة الأولى (MVP) والنموذج الأولي القابل للنقر. وقبل سرد الميزات، اكتب ثلاثة أشياء:

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

ثم حدّد النسخة الأولى القابلة للاستخدام (MVP): أصغر نسخة تحل المشكلة الأساسية بما يكفي ليستخدمها أناس حقيقيون. اكتب رحلة أو رحلتين أساسيتين للمستخدم، مثل «التسجيل ← التصفح ← الطلب ← الدفع ← تلقّي الإشعار»، وانقل كل ما عداها إلى قائمة «لاحقاً». النسخة الأولى ليست تطبيقاً نصف معطل؛ بل تطبيق متقَن ضمن نطاق ضيق.

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

تطبيق أصلي أم متعدد المنصات أم تطبيق ويب؟

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

أصلي (Native): تطبيق منفصل لكل منصة، يُبنى بلغة Swift لنظام iOS وKotlin لنظام Android. أوسع وصول إلى ميزات الجهاز، لكن مع قاعدتَي شيفرة تحتاجان إلى صيانة.
متعدد المنصات (Cross-platform): أُطر عمل مثل Flutter أو React Native تتشارك معظم الشيفرة بين iOS وAndroid؛ وتصف وثائق Flutter هدفها بأنه بناء «تطبيقات متعددة المنصات من قاعدة شيفرة واحدة». ولتطبيقات الأعمال المعتادة (الطلبات، والحجوزات، والعضويات، والكتالوجات، والأدوات الداخلية) هذا خيار افتراضي معقول. أما الرسوميات الثقيلة، أو أعمال الكاميرا والصوت المتقدمة، أو الاعتماد على أحدث ميزات المنصات، فقد ترجّح الكفة نحو التطبيق الأصلي.
تطبيق ويب أو PWA: تطبيق الويب التقدمي يعمل في المتصفح، ويمكن إضافته إلى الشاشة الرئيسية، ولا يحتاج إلى مراجعة المتاجر. وهو يكفي غالباً حين يحتاج إليك العملاء من حين لآخر فقط، أو حين لا تزال تختبر الفكرة. أما الثمن: لا وجود في المتاجر، وتكامل أصعب مع الجهاز، ودعم أكثر محدودية لتطبيقات PWA على iOS.

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

الخلفية ولوحة الإدارة وواجهات API

معظم تطبيقات الأعمال قمة نظام أكبر: خلف الشاشات تقف خلفية (Backend) ولوحة إدارة وتكاملات مع الدفع والشحن والأنظمة التي تستخدمها أصلاً.

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

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

الخصوصية وحماية البيانات

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

اجمع ما تحتاجه فقط. كل حقل في النماذج وكل إذن (الموقع، وجهات الاتصال، والكاميرا) يجب أن يقابله ميزة تستطيع شرحها.
اعرف القوانين المطبَّقة. إذا كان لديك مستخدمون في الاتحاد الأوروبي، فاللائحة العامة لحماية البيانات (GDPR) تنطبق عليك. ويؤكد دليل حماية البيانات للشركات الصغيرة الصادر عن المجلس الأوروبي لحماية البيانات (EDPB) أن ذلك يشمل المؤسسات الواقعة خارج المنطقة الاقتصادية الأوروبية التي تُعرض منتجاتها أو خدماتها على أشخاص داخلها. وتشترط اللائحة أساساً قانونياً لكل استخدام للبيانات، ومعلومات واضحة، وحقوقاً للمستخدمين، وعقوداً مع المزوّدين الذين يعالجون البيانات نيابةً عنك. ولكثير من الدول الأخرى، ولعدد من الولايات الأمريكية، قوانين خصوصية خاصة بها.
اطلب الإذن قبل التتبّع. في الاتحاد الأوروبي، تحتاج حزم SDK للتحليلات والإعلانات غير الضرورية تماماً عموماً إلى موافقة مسبقة، وأنت مسؤول عمّا تجمعه حزم الأطراف الثالثة. وعلى iOS، يتطلب تتبّع الأشخاص عبر تطبيقات ومواقع شركات أخرى إذن «شفافية تتبّع التطبيقات» (App Tracking Transparency) من Apple.
أفصح عن ذلك في المتاجر. تطلب Apple تفاصيل «خصوصية التطبيق» (App Privacy)، ويطلب Google Play قسم «أمان البيانات» (Data safety). وكلاهما يشترط سياسة خصوصية، ويجب أن تطابق إفصاحاتك ما يفعله التطبيق فعلاً.
مكّن الناس من حذف حساباتهم. بموجب الإرشاد 5.1.1 من إرشادات مراجعة App Store، «إذا كان تطبيقك يتيح إنشاء الحسابات، فيجب أن يتيح أيضاً حذف الحساب من داخل التطبيق». وتضيف متطلبات Google Play لحذف الحسابات رابط ويب يستطيع الناس من خلاله طلب حذف حساباتهم وبياناتهم من خارج التطبيق.

الاختبار ومراجعة المتاجر وحسابات المطوّرين الخاصة بك

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

الاختبار. استخدم أجهزة حقيقية: هواتف قديمة وحديثة، وشاشات صغيرة وكبيرة، وكل إصدارات الأنظمة التي تدعمها. ثم أطلق نسخة تجريبية عبر TestFlight من Apple ومسارات الاختبار في Google Play. ووفقاً لـمتطلبات الاختبار في Google Play، يجب على حسابات المطوّرين الشخصية التي أُنشئت بعد 13 نوفمبر 2023 إجراء اختبار مغلق يشارك فيه 12 مختبِراً على الأقل بشكل متواصل لمدة 14 يوماً على الأقل قبل طلب الوصول إلى الإصدار العلني؛ وتنطبق القاعدة على الحسابات الشخصية فقط.

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

حساباتك الخاصة. انشر التطبيق عبر حسابات المطوّرين الخاصة بشركتك، لا حسابات الوكالة التي تتعامل معها. لبرنامج مطوّري Apple رسوم سنوية، ولـGoogle Play Console رسوم تسجيل لمرة واحدة؛ وحسابات المؤسسات في المتجرين تتطلب رقم D-U-N-S والتحقق من الهوية، فابدأ مبكراً. واحرص أيضاً على أن يكون النطاق والاستضافة ومستودع الشيفرة وبيانات اعتماد التوقيع باسمك.

ما الذي يحدد التكلفة والمدة قبل الإطلاق وبعده

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

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

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

كيف تكتب موجزاً لفريق التطوير

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

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

ثم اسأل فريق التطوير: كيف ستقسّم العمل إلى مراحل؟ من يملك الشيفرة والتصاميم والحسابات؟ كيف تُدار التغييرات في النطاق؟ كيف تبدو الصيانة؟

أسئلة شائعة

هل أبني تطبيقاً أصلياً أم متعدد المنصات؟

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

كم تكلفة برمجة تطبيق؟

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

هل أحتاج إلى حسابات مطوّرين خاصة بي لدى Apple وGoogle؟

نعم، يُنصح بذلك بشدة. فبحساباتك الخاصة تتحكم في صفحة التطبيق ومراجعاته وتحديثاته، ويمكنك تغيير فريق التطوير من دون نقل التطبيق. تفرض Apple رسوماً سنوية، ويفرض Google Play رسوم تسجيل لمرة واحدة، وحسابات المؤسسات تحتاج إلى رقم D-U-N-S.

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

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