تطوير التطبيقات في المغرب: PWA أم متعدد المنصات أم أصلي؟

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

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

PWA ومتعدد المنصات والتطوير الأصلي: ثلاث بنى مختلفة

PWA: تطبيق يُوزع عبر الويب

تستخدم Progressive Web App تقنيات الويب ويمكن أن تتيح التثبيت على الشاشة الرئيسية والعرض المستقل وبعض الوظائف دون اتصال. توضح وثائق MDN أن قابلية التثبيت تعتمد على عناصر مثل ملف manifest والأيقونات وHTTPS، مع اختلاف الدعم بين المتصفحات والمنصات. لذلك يجب اختبار PWA على الأجهزة والمتصفحات التي يستخدمها الجمهور فعلا؛ فهي ليست طريقا مختصرا إلى كل إمكانات التطبيقات الأصلية.

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

متعدد المنصات: شفرة مشتركة مع نقاط تكامل أصلية

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

لا يعني متعدد المنصات إذن «عدم وجود شفرة أصلية». المطلوب هو تحديد الوظائف المشتركة والتبعيات التي تحتاج إلى Swift أو Kotlin أو مكتبة خاصة. ويجب إنجاز هذا الجرد قبل بدء التطوير.

التطوير الأصلي: تطبيق خاص بكل منصة

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

ثمانية معايير لاختيار البنية

1. قناة التوزيع المتوقعة

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

2. وظائف الهاتف الضرورية

اسردوا كل حاجة: الكاميرا والموقع وBluetooth وNFC والقياسات الحيوية والملفات والمهام الخلفية والإشعارات. سجلوا تكرارها وأهميتها والمنصات المعنية. توصي Android بإعلان الصلاحيات التي يحتاجها التطبيق فقط. قد تغطي تقنية الويب أو وحدة جاهزة وظيفة عرضية، بينما قد تبرر وظيفة حرجة وعميقة التطوير الأصلي.

3. السلوك دون اتصال

يجب تحويل عبارة «يعمل دون اتصال» إلى سيناريوهات: قراءة بيانات محفوظة، وإنشاء ملف، والتقاط صور، وتعديل نموذج، والمزامنة لاحقا. تشرح MDN كيف يستطيع service worker اعتراض الطلبات وإرجاع موارد مخزنة في PWA. وتصف Android بنية offline-first تكون فيها البيانات المحلية مرجع القراءة وتُزامن مع الشبكة. ومع ذلك تبقى النزاعات والتكرار والاسترجاع بحاجة إلى تصميم صريح في كل نهج.

للاستخدام الميداني، يشرح دليل تطبيق الهاتف offline-first في المغرب قواعد البيانات والمزامنة.

4. تجربة المستخدم وإمكانية الوصول

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

5. التكاملات والتبعيات الخارجية

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

6. التحديثات وحوكمة المتاجر

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

7. المهارات والصيانة

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

8. الأمن والبيانات واختبار القبول

حددوا البيانات المخزنة على الجهاز وإدارة الجلسة والتشفير المناسب والسجلات والإلغاء. عند معالجة بيانات شخصية في المغرب، ينبغي مراجعة المسؤوليات والنطاق وفق القانون 09-08 كما تعرضه CNDP. ويجب أن يغطي اختبار القبول رفض الصلاحيات والعمل دون اتصال والاسترجاع والتحديث وإصدارات الأنظمة المدعومة.

قاعدة قرار عملية

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

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

نموذج أولي يثبت القرار

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

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

أخطاء يجب تجنبها

• اختيار Flutter أو React Native أو التطوير الأصلي قبل جرد وظائف المنتج.
• الوعد بالعمل دون اتصال دون تعريف البيانات والنزاعات والاسترجاع.
• اعتبار الشفرة المشتركة بديلا عن اختبار iOS وAndroid.
• إنشاء حسابات المتاجر باسم المورد دون إجراء نقل واضح.
• طلب كل الصلاحيات عند فتح التطبيق.
• إهمال صيانة التبعيات والشهادات وإصدارات النظام.
• بناء تطبيق هاتف عندما تلبي بوابة ويب قابلة للوصول الحاجة.

أسئلة شائعة حول تطوير التطبيقات في المغرب

هل تستطيع PWA العمل دون اتصال؟

نعم، للمسارات المصممة عمدا حول service worker والتخزين المؤقت وربما التخزين المحلي. يجب تحديد ما يمكن قراءته أو تعديله وكيف ستتم المزامنة لاحقا.

هل يلغي React Native أو Flutter التطوير الأصلي؟

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

هل يجب إطلاق التطبيق في المتجرين منذ البداية؟

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

كيف نقارن العروض؟

قارنوا النطاق الوظيفي والمنصات والتكاملات والاختبارات وملكية الحسابات والشفرة والتوثيق والصيانة وشروط النقل. اسم الإطار وحده لا يحدد المخرج.

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

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