تطوير تطبيقات الجوال

ماذا يشمل تطوير تطبيقات الجوال؟

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

نتناول مشروع تطبيق iOS و Android عادةً تحت العناوين الآتية:

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

تطبيق أم تطبيق ويب؟

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

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

لأي الأنشطة يكون ذا معنى؟

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

اختيار النهج التقني لتطبيق iOS و Android

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

التطوير الأصلي (Native)

في النهج الأصلي يُكتب تطبيقان منفصلان: بلغة Swift لنظام iOS وبلغة Kotlin لنظام Android. ويُتاح الوصول المباشر إلى كل إمكانات المنصة؛ وهو خيار قوي للتطبيقات التي تتطلب حركات كثيفة، أو معالجة متقدمة للكاميرا، أو اتصالات بعتاد مثل Bluetooth، أو أداءً عاليًا. وفي المقابل تلزم صيانة قاعدتي شيفرة منفصلتين كل على حدة.

التطوير متعدد المنصات (Cross-platform)

بأطر عمل مثل Flutter أو React Native تُنتَج النسختان لنظامي iOS و Android من قاعدة شيفرة واحدة. ويمكن بهذا النهج تطوير معظم التطبيقات براحة، مثل الكتالوج والطلبات والحجوزات والعضويات ومتابعة الأعمال. وتسهّل قاعدة الشيفرة الواحدة وصول الميزة الجديدة إلى المنصتين في وقت واحد، وتقلل عبء الصيانة.

ما الذي يحدد القرار؟

عند اختيار النهج في مشروع تطبيق iOS و Android ننظر في الأسئلة الآتية:

• ما ميزات الجهاز التي سيستخدمها التطبيق: الكاميرا أم الموقع أم Bluetooth أم البيانات الصحية أم العمل في الخلفية؟
• كم الحركة في الواجهة، وما توقعات الأداء؟
• ما وتيرة التحديث بعد النشر، وما ميزانية الصيانة؟
• هل هناك احتمال أن تتولى التطبيق جهة أخرى أو فريق آخر مستقبلًا؟
• بأي طريق سيتبادل التطبيق البيانات مع أنظمتكم القائمة؟

الأداء وإمكانية الوصول

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

مراحل عملنا في تطوير تطبيقات الجوال

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

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

ماذا تتضمن وثيقة النطاق؟

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

لماذا يهم النموذج الأولي؟

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

تصميم يناسب فروق المنصات

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

إبقاء الإصدار الأول صغيرًا

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

الفتح الأول وطلبات الأذونات

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

مشاركة نسخ الاختبار معكم

نشارك نسخ الاختبار أثناء التطوير عبر TestFlight في iOS وعبر قنوات الاختبار في Google Play في Android. فتثبّتون أنتم وفريقكم التطبيق على هواتفكم، وتجرّبونه في ظروف الاستخدام الحقيقية، وترسلون ملاحظاتكم. وتدخل هذه الملاحظات في قائمة أولويات دورة التطوير التالية.

الواجهة الخلفية ولوحة التحكم والتكاملات

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

• إدارة المستخدمين: مسارات التسجيل وتسجيل الدخول وتجديد كلمة المرور وحذف الحساب.
• لوحة التحكم: لوحة عبر الويب يستطيع فريقكم من خلالها تحديث المحتوى أو المنتجات أو الطلبات أو المواعيد دون المساس بالتطبيق.
• الإشعارات: إشعارات فورية تُرسل عبر Apple Push Notification service في iOS وعبر Firebase Cloud Messaging في Android.
• التحليلات: قياس يبيّن أي الشاشات تُستخدم وفي أي خطوة يغادر المستخدمون.
• تتبع الأخطاء: تقارير تخبر حين يتعطل التطبيق على أي جهاز وعند أي خطوة.

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

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

عملية النشر في المتجر وما بعدها

جاهزية التطبيق لا تعني أنه منشور في المتجر. فكل من Apple و Google يراجع كل تطبيق وكل تحديث وفق قواعده. وفي مشروع تطبيق iOS و Android ندرج الاستعدادات للمتاجر في الخطة من البداية بدل تركها لنهاية التطوير.

حسابات المطورين

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

قواعد المراجعة

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

الخصوصية وقانون حماية البيانات الشخصية التركي رقم 6698 (KVKK) وأذونات المستخدم

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

المدفوعات داخل التطبيق

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

صفحة المتجر والظهور

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

الصيانة بعد النشر

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

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

العوامل التي تحدد النطاق في تطوير تطبيقات الجوال

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

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

ما ينبغي أن تجهزوه

إذا جئتم إلى لقاء تطوير تطبيقات الجوال ومعكم ما يلي، استطعنا توضيح النطاق أسرع بكثير:

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

ماذا ننظر فيه عند مقارنة العروض؟

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

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

أخطاء شائعة

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

كيف نقيس النجاح؟

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

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

كم يستغرق تطوير تطبيقات الجوال؟

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

هل يمكن النشر في المتجرين بتطبيق iOS و Android واحد؟

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

لمن تعود ملكية الشيفرة المصدرية وحسابات المتاجر؟

ننصح بأن تُفتح حسابات المتاجر باسم شركتكم. ونكتب شروط ملكية الشيفرة المصدرية والحسابات بوضوح في العقد عند بداية المشروع.

هل يمكن أن يستخدم التطبيق وموقعي الإلكتروني الحالي البيانات نفسها؟

يمكن ذلك. إذا كانت بنية موقعكم توفّر واجهة API استخدم التطبيق بيانات المنتجات والأعضاء والطلبات نفسها؛ وإن لم توفّرها بنينا طبقة الربط هذه أولًا.

ماذا يحدث إذا رُفض التطبيق من المتجر؟

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

من يجري التحديثات بعد تطوير تطبيقات الجوال؟

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

لنوضح فكرة تطبيقكم معًا

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