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

ترى Mesterséges Intelligencia Központ Kft.، شركة تطوير البرمجيات في بودابست بالمجر، أن التطبيق الأصلي يلزم إذا كان التطبيق يستخدم الجهاز استخدامًا عميقًا؛ وإذا كانت الوظائف نفسها مطلوبة على المنصتين، فقاعدة شيفرة مشتركة أسهل في الصيانة.

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

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

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

التطبيق الأصلي

في التطبيق الأصلي تُبنى نسختا iOS وAndroid كلٌّ على حدة، بلغة كل منصة وأدوات واجهتها الخاصة. وعلى iOS يعني ذلك اليوم عادةً لغة Swift وSwiftUI: فبحسب Apple، يتيح SwiftUI بناء واجهة المستخدم على جميع منصات Apple بصياغة تصريحية (declarative)، اعتمادًا على لغة Swift (Apple: SwiftUI). وعلى Android يعني ذلك Kotlin وJetpack Compose: إذ تصف Google أداة Jetpack Compose بأنها مجموعة الأدوات الحديثة الموصى بها في Android لبناء واجهة أصلية (Android Developers: Jetpack Compose)، وتوصي بالبدء بلغة Kotlin عند إنشاء تطبيق Android جديد (Android Developers: Kotlin-first). وميزة الطريق الأصلي أن كل إمكانية جديدة للمنصة تكون متاحة مباشرة منذ اليوم الأول؛ وعيبه أنه يجب تطوير قاعدتَي شيفرة وصيانتهما.

أطر العمل متعددة المنصات

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

Flutter: إطار عمل بلغة Dart. وبحسب وثائقه، ينفّذ Flutter كل عنصر من عناصر الواجهة بنفسه بدلًا من استخدام عناصر النظام، ويستخدم في الرسم محركًا يُسمّى Impeller؛ ويمكن استدعاء الشيفرة الخاصة بالمنصة عبر ما يُسمّى قناة المنصة (platform channel) (Flutter: Architectural overview).
React Native: يعتمد على React وJavaScript؛ وبتعبير المشروع نفسه، يُكتب بلغة JavaScript لكنه يُعرض بشيفرة أصلية، لأن مكوّناته الأساسية تقابل لبنات الواجهة الأصلية للمنصة (React Native). واعتبارًا من الإصدار 0.76 أصبحت ما تُسمّى البنية الجديدة (New Architecture) هي الافتراضية، وفيها تحلّ واجهة JavaScript Interface (JSI) محلّ الجسر غير المتزامن (React Native: New Architecture).
Kotlin Multiplatform: تقنية مفتوحة المصدر من JetBrains، تتيح مشاركة الشيفرة بين أهداف Android وiOS وسطح المكتب والويب والخادم. ويمكن مشاركة منطق الأعمال وحده مع واجهة أصلية، أو مشاركة الواجهة أيضًا باستخدام Compose Multiplatform (Kotlin: Kotlin Multiplatform). وبحسب وثائق Kotlin، بلغ Compose Multiplatform مستوى الاستقرار (Stable) على iOS أيضًا (Kotlin: stability of supported platforms، تم التحقق في 17 أكتوبر 2026).
.NET MAUI: إطار عمل من Microsoft بلغتَي C# وXAML، يتيح تطوير تطبيقات لأنظمة Android وiOS وmacOS وWindows من قاعدة شيفرة مشتركة واحدة؛ وهو امتداد مطوَّر لـXamarin.Forms. ويلزم جهاز Mac لبناء تطبيقات iOS وmacOS (Microsoft Learn: What is .NET MAUI?).

تطبيق الويب التقدّمي (PWA)

تطبيق PWA هو تطبيق ويب يعمل في المتصفح، ويمكن تثبيته على الشاشة الرئيسية، ويقدّم تجربة أكثر موثوقية بفضل وظائف تتوسع تدريجيًا (progressive enhancement). وبحسب ملخص web.dev، تتفوق تطبيقات المنصات في القدرات، وتطبيقات الويب في الانتشار: فقاعدة شيفرة واحدة تصل إلى أي شخص، على أي جهاز (web.dev: Progressive Web Apps). وعلى iOS وiPadOS، منذ الإصدار 16.4، يمكن لتطبيق الويب المضاف إلى الشاشة الرئيسية أن يطلب أيضًا الإذن بإرسال الإشعارات الفورية (push) (WebKit: Web Push for Web Apps). وثمة قيد مهم: فبموجب البند 4.2 من إرشادات App Store، يجب أن يقدّم التطبيق أكثر من موقع ويب أُعيد تغليفه، ولذلك لا يجدر نقل موقع ويب إلى المتجر بمجرد تغليفه في تطبيق (Apple: App Store Review Guidelines).

مقارنة في جدول واحد

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

وتقول وثائق Flutter ذلك صراحةً: فحزمة تطبيق Flutter مستقلة بذاتها، وتحتوي على كل الشيفرة والموارد اللازمة للتشغيل، ولذلك قد يكون حجمها اعتبارًا مهمًا (Flutter: Measuring your app's size). وفي الواقع العملي نادرًا ما يكون هذا الفرق حاسمًا، لكن من المفيد معرفته إذا كان الجمهور المستهدف يستخدم التطبيق على أجهزة أقدم أو باتصال ضعيف.

متى يلائم كلٌّ منها؟

الأصلي، إذا

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

متعدد المنصات، إذا

كانت الوظائف نفسها مطلوبة على المنصتين، وكان من المهم أن تظهر التغييرات عليهما في آن واحد؛
كان التطبيق يتكون في الغالب من نماذج وقوائم وعرض للبيانات وإشعارات، كما هي حال معظم تطبيقات الأعمال؛
كان فريق واحد سيتولى صيانة التطبيق على المدى الطويل؛
كانت الشركة تستخدم بالفعل لغة إطار العمل، فمثلًا تشير خبرة React في الويب إلى React Native، والخلفية في .NET إلى .NET MAUI.

PWA أو تطبيق ويب، إذا

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

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

النظام الخلفي وواجهة الإدارة

نادرًا ما يقف تطبيق الجوال وحده. فبمجرد أن تكون فيه حسابات مستخدمين، أو بيانات مشتركة، أو إشعارات، يلزم خلفه خادم: فهناك توجد الحسابات والبيانات والصلاحيات، ومن هناك تنطلق الإشعارات. ويرسل النظام الخلفي الإشعارات الفورية عادةً عبر خدمة مخصّصة لذلك؛ فـFirebase Cloud Messaging مثلًا حل مراسلة مستقل عن المنصات، تُعِدّ فيه بيئة خادم موثوقة الرسائل وترسلها إلى تطبيقات Apple وAndroid والويب (Firebase: Cloud Messaging).

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

النشر في المتاجر: إلامَ ننتبه في أكتوبر 2026؟

تتغير قواعد المتاجر كثيرًا، ولذلك نورد النقاط التالية مؤرَّخة (تم التحقق في 17 أكتوبر 2026).

App Store (Apple)

إرشادات المراجعة: حُدّثت App Store Review Guidelines آخر مرة في 16 أكتوبر 2026. وبموجب البند 2.1، يجب إرسال نسخة كاملة جاهزة للمراجعة؛ وإذا كان في التطبيق تسجيل دخول، فيجب تقديم حساب تجريبي، ويجب أن يعمل النظام الخلفي أثناء المراجعة أيضًا. وبموجب البند 5.1.1، يجب أن يحيل كل تطبيق إلى إشعار الخصوصية الخاص به، وإذا كان التطبيق يتيح إنشاء حساب، فيجب أن يتيح حذف الحساب أيضًا من داخل التطبيق (Apple: App Store Review Guidelines).
بيانات الخصوصية: يجب أن تُبيَّن في App Store Connect ممارسات التطبيق في معالجة البيانات، بما في ذلك ممارسات المكوّنات الخارجية المدمجة فيه (مثل حزم SDK للتحليلات)؛ وهذا مطلوب لإرسال تطبيق جديد ولإرسال تحديث على حدّ سواء (Apple: App privacy details).
متطلبات أدوات التطوير: منذ 28 أبريل 2026 يجب بناء التطبيقات المرفوعة إلى App Store Connect باستخدام Xcode 26 أو أحدث، وبـiOS 26 SDK، ومنذ 9 سبتمبر 2026 يجب أن تستهدف تطبيقات iOS وiPadOS نظام iOS 13 على الأقل (Apple: Upcoming requirements).
حساب الشركة: للتسجيل بصفة مؤسسة، يجب أن تكون الشركة شخصًا اعتباريًا لديه رقم D-U-N-S، ويجب أن يكون للشخص الذي يسجّل صلاحية إلزام الشركة قانونيًا (Apple: Enrollment).
صفة التاجر في الاتحاد الأوروبي: تطلب Apple من المطوّر أن يصرّح بما إذا كان يُعدّ تاجرًا بموجب قانون الاتحاد الأوروبي؛ وتظهر بيانات التواصل الخاصة بالتجار في الاتحاد الأوروبي على صفحة التطبيق في المتجر (Apple: Digital Services Act trader requirements).

Google Play

مستوى API المستهدف: منذ 31 أغسطس 2026 يجب أن تستهدف التطبيقات الجديدة والتحديثات على الهواتف Android 16 (مستوى API 36) على الأقل؛ ويجب أن تستهدف التطبيقات القائمة Android 15 (مستوى API 35) على الأقل لكي تبقى متاحة للمستخدمين الجدد على الأجهزة التي تعمل بإصدارات Android أحدث. وفي حال طلب تمديد عبر Play Console يكون الموعد النهائي 1 نوفمبر 2026 (Android Developers: Target API level).
الاختبار في الحسابات الشخصية: في حسابات المطوّرين الشخصية المنشأة بعد 13 نوفمبر 2023، يجب قبل الإصدار الفعلي إجراء اختبار مغلق مع 12 مختبِرًا على الأقل، يشاركون فيه بصورة متواصلة منذ 14 يومًا على الأقل (Play Console Help: testing requirements).
حساب المؤسسة: لا يمكن إنشاء حساب مطوّر لمؤسسة دون رقم D-U-N-S (Play Console Help: creating an account).
نموذج أمان البيانات: يجب تعبئته لكل تطبيق منشور على Google Play، حتى لو لم يجمع التطبيق أي بيانات للمستخدمين (Play Console Help: Data safety).
حذف الحساب: إذا كان يمكن إنشاء حساب في التطبيق، فيجب إتاحة طلب حذف الحساب والبيانات المرتبطة به من داخل التطبيق وعبر رابط ويب أيضًا (Play Console Help: account deletion requirements).

وتسري هذه القواعد بصرف النظر عن التقنية: فالتطبيق المبني بـFlutter أو React Native يجب أن يستوفي متطلبات API المستهدف وSDK نفسها التي يستوفيها التطبيق الأصلي، ويجب أن تواكبها تحديثات إطار العمل. ونوصي بأن يكون حساب المطوّر ملكًا لشركة العميل: فبذلك يظهر التطبيق باسم شركتكم، وتبقى صفحة التطبيق في المتجر ملكًا للشركة أيضًا.

إمكانية الوصول

تعمل المنصتان كلتاهما بقارئ شاشة مدمج (VoiceOver على iOS، وTalkBack على Android)، وتوفّران واجهات تتيح للتطبيقات التكامل مع هذه التقنيات المساعدة (React Native: Accessibility). وتوصي وثائق Flutter مثلًا بأن يصف قارئ الشاشة كل عنصر تحكم وصفًا مفهومًا، وبألّا تقل نسبة التباين بين النص والخلفية عن 4.5:1، وبألّا يقل حجم كل عنصر قابل للّمس عن 48×48 بكسل (Flutter: Accessibility). وتوصي وثائق Android باتباع إرشادات Material Design، واستخدام أداة Accessibility Scanner، وإجراء فحوص تلقائية لاكتشاف المشكلات (Android Developers: Accessibility).

وليس هذا مجرد ممارسة جيدة: فبموجب التوجيه (EU) 2019/882، يتعيّن على الدول الأعضاء أن تطبّق اعتبارًا من 28 يونيو 2025 متطلبات إمكانية الوصول الخاصة بخدمات التجارة الإلكترونية المقدَّمة للمستهلكين، بما فيها الخدمات المقدَّمة عبر تطبيقات الجوال (وتستند القواعد المجرية إلى نقل هذا التوجيه إلى القانون الوطني)؛ ويجب إعفاء المؤسسات متناهية الصغر التي تقدّم الخدمات (EUR-Lex: التوجيه (EU) 2019/882). ويتناول مقال المتجر الإلكتروني: منصة مستأجَرة أم تطوير مخصّص؟ التفاصيل الخاصة بالمتاجر الإلكترونية.

الذكاء الاصطناعي: على الجهاز أم في السحابة؟

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

على الجهاز (Apple): يتيح إطار Foundation Models من Apple، اعتبارًا من iOS 26، الوصول إلى النماذج المصمَّمة لـApple Intelligence، العاملة على الجهاز وعلى Private Cloud Compute؛ ويمكن استخدامه لتوليد النصوص، وللمخرجات المنظَّمة، ولاستدعاء الأدوات الخاصة أيضًا، لكن فقط على الأجهزة التي تدعم Apple Intelligence (Apple: Foundation Models).
على الجهاز (Android): يعمل Gemini Nano في خدمة النظام AICore في Android، ويُتاح عبر واجهات ML Kit GenAI، مثلًا للتلخيص، وتدقيق النصوص، وإعادة الصياغة، ووصف الصور. وبحسب Google، يعمل دون اتصال بالشبكة أيضًا، وتبقى البيانات الحساسة على الجهاز، لكن حدّ الـtokens وعتاد الجهاز يقيّدان النموذج (Android Developers: Gemini Nano).
في السحابة: النماذج اللغوية الكبيرة من OpenAI (ChatGPT) وAnthropic (Claude) وGoogle (Gemini)، للمهام الأكثر تعقيدًا، مثل مساعد يجيب من مواد الشركة نفسها، ومعالجة المستندات والصور، والتلخيص. ويبقى مفتاح الوصول إلى خدمة الذكاء الاصطناعي في النظام الخلفي، لا على الهاتف: فلا يمكن استخراجه من التطبيق، ويمكن ضبط الاستخدام على الخادم.

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

علامَ تتوقف الصيانة؟

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

متطلبات أنظمة التشغيل والمتاجر: تفرض Apple إصدارات أحدث من Xcode وSDK لرفع التطبيقات، وتفرض Google Play مستوى API مستهدفًا أحدث. وتُظهر التواريخ أعلاه أن هذه المتطلبات ترتفع بانتظام.
تغيّرات إرشادات المتاجر: إقرارات خصوصية جديدة، وقواعد جديدة لحذف الحساب أو للاختبار.
تحديثات إطار العمل: في التطبيق متعدد المنصات، قد يعني تغيير إصدار رئيسي في Flutter أو React Native أو .NET MAUI عملًا في الشيفرة الخاصة وفي الإضافات المستخدمة أيضًا.
المكوّنات الخارجية: حزم SDK للدفع والخرائط والتحليلات، ولها أيضًا متطلبات تحديث خاصة بها.
النظام الخلفي والتكاملات: تغيّرات واجهات أنظمة الشركة وخدمات الذكاء الاصطناعي المرتبطة.
عدد قواعد الشيفرة: يتطلب تطبيقان أصليان التعديل في موضعين.

الأخطاء الشائعة

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

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

أصلي أم Flutter/React Native؟

إذا كان التطبيق يستخدم الجهاز استخدامًا عميقًا (الكاميرا، والمستشعرات، والعمليات العاملة في الخلفية)، أو كانت متطلبات أدائه عالية، فالتطوير الأصلي هو الطريق الأضمن. وإذا كانت الوظائف نفسها مطلوبة على المنصتين، فإن تطبيقًا بقاعدة شيفرة مشتركة مبنيًا بـFlutter أو React Native أسهل في الصيانة. ومع Kotlin Multiplatform يمكن سلوك طريق وسط أيضًا: منطق أعمال مشترك، وواجهة أصلية. وفي الاستشارة الأولى نقدّم توصيتنا بناءً على الوظائف المحددة.

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

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

هل يحتاج التطبيق إلى نظام خلفي؟

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

مَن ينشر التطبيق في المتاجر؟

نتولى نحن النشر: نُعدّ مواد صفحة التطبيق في المتجر وإقرارات الخصوصية، ونرسل التطبيق، ونرافق المراجعة حتى النهاية. ونوصي بأن يكون حساب المطوّر ملكًا لشركتكم؛ ويطلب المتجران كلاهما رقم D-U-N-S لحساب المؤسسة، ولذلك يجدر الحصول عليه في الوقت المناسب.

علامَ تتوقف تكلفة الصيانة؟

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

كيف نساعدكم؟

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

نقيس الحجم الوظيفي للتطوير بنقاط COSMIC الوظيفية (ISO/IEC 19761)، ومنه يُعَدّ العرض والجدول الزمني. الاستشارة الأولى مجانية، ونوقّع عند الطلب اتفاقية عدم إفصاح (NDA)، وبعد التسليم نتولى التشغيل والصيانة أيضًا. وتخضع الشيفرة المصدرية وحقوق الاستخدام لأحكام العقد. اكتبوا لنا فكرتكم في بضع جمل، وتواصلوا معنا.