تطوير تطبيقات الهاتف المحمول

ما تطوير تطبيقات الهاتف، ومتى تحتاجون فعلًا إلى تطبيق؟

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

تقدم UNIT İstanbul خدمات تطوير تطبيقات الهاتف عبر علامتها البرمجية Unit Software. ولأن الفريق يعمل داخل وكالة تمارس التسويق منذ عام 2009، يكون القياس واكتساب المستخدمين والظهور في المتاجر حاضرة منذ اليوم الأول للمشروع.

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

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

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

تطوير أصلي أم React Native أم Flutter؟

قرار التقنية يحدد ميزانية التطبيق وسرعته وعبء صيانته لسنوات. فالتطوير الأصلي (Native) يعني كتابة كل منصة بلغتها الخاصة: Swift لنظام iOS وKotlin لنظام Android. أما في النهج متعدد المنصات، فينتج React Native أو Flutter تطبيقات للمنصتين من قاعدة شيفرة واحدة.

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

متى يكفي تطبيق الويب التقدمي (PWA)؟

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

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

لماذا تهم تجربة المستخدم وإمكانية الوصول على الهاتف؟

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

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

النصف الخفي من التطبيق: الخادم وواجهة API ولوحة الإدارة

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

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

كيف يُخطَّط للإشعارات الفورية؟

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

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

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

كيف تجري عملية النشر في App Store وGoogle Play؟

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

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

ما القواعد التي تنطبق على المشتريات داخل التطبيق؟

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

كيف تُدار الإصدارات ومراقبة الأعطال والأداء؟

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

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

ما الذي ينبغي قياسه في تطبيق الهاتف؟

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

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

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

كيف يُعالَج الأمان وحماية البيانات (KVKK) في تطبيق الهاتف؟

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

• تُحفظ رموز الجلسات والبيانات الحساسة في المناطق الآمنة لنظام التشغيل، مثل iOS Keychain وAndroid Keystore، ولا تُكتب المفاتيح السرية في شيفرة التطبيق أبدًا.
• تمر كل حركة البيانات عبر اتصالات مشفّرة، ويُضاف تثبيت الشهادات (certificate pinning) في المشاريع التي تحتاج إليه.
• لا يطلب التطبيق إلا البيانات والأذونات التي تتطلبها وظيفته، ولا يُطلب الوصول إلى الموقع أو جهات الاتصال دون سبب.
• لأغراض قانون حماية البيانات التركي (KVKK)، يُوثَّق إشعار الخصوصية، والمعالجة التي تتطلب موافقة صريحة، وموقع خوادم البيانات، وتدفقات البيانات في المكتبات الخارجية. أما القرارات المتعلقة بنقل البيانات عبر الحدود فتُحسم بالتعاون مع مستشاركم القانوني.

ما الذي يحدد تكلفة بناء تطبيق للهاتف؟

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

• منصة واحدة أم منصتان، وتطوير أصلي أم متعدد المنصات.
• أدوار المستخدمين، وعدد المسارات ومدى تعقيدها.
• هل يُبنى الخادم من الصفر أم يُربط بنظام قائم.
• التكاملات مثل المدفوعات والخرائط والمراسلة وERP أو CRM.
• الاستخدام دون اتصال، والبيانات الفورية، ومتطلبات الأمان.
• نطاق الصيانة والتطوير بعد الإطلاق.

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

لماذا يحتاج التطبيق إلى صيانة بعد الإطلاق؟

لا ينتهي تطبيق الهاتف عند إطلاقه. فـApple وGoogle تحدّثان أنظمة التشغيل كل عام؛ ويشترط Google Play أن تستهدف تحديثات التطبيقات إصدارًا حديثًا من Android، ويتوقع App Store نسخًا مبنية بأدوات تطوير حديثة.

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