كيف استفادت آريب من Compose Multiplatform: رؤى تقنية ودروس مستفادة

حتى مع أننا كنا نستخدم Jetpack Compose بالفعل داخل مشاريعنا، كان الانتقال إلى Compose Multiplatform (CMP) خطوة مختلفة تمامًا. هذه الخطوة أضافت تحديات جديدة ودفعتنا لإعادة التفكير في الطريقة التي ندير بها التطوير من الأساس، بما في ذلك:

إزالة الـ Activities والاعتماد على نموذج شاشة واحدة (Single Activity).

الانتقال من Retrofit إلى Ktor للعمل على الشبكات.

استبدال Hilt بـ Koin لإدارة التبعيات.

إعادة تنظيم التبعيات والانتقال من buildSrc إلى Version Catalogs.

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

التحدي الأول: التحول إلى تفكير "Kotlin أولًا"

أول عقبة واجهناها كانت التخلي عن التفكير التقليدي الخاص بأندرويد والتحول إلى أسلوب يعتمد على Kotlin أولًا.

Compose Multiplatform لا يستهدف أندرويد فقط، بل يعمل على iOS ومنصات أخرى. لذلك كان علينا:

استبدال الأدوات المبنية على Java بمكتبات مكتوبة بالكامل بـ Kotlin.

تعديل بنية التطبيق لتجنب أي شيء مرتبط بشكل مباشر بأندرويد.

التفكير في حلول مشتركة بدلًا من حلول منفصلة لكل منصة.

وهذا جعلنا نعيد تقييم كل مكتبة وكل أداة لضمان أنها متوافقة مع Kotlin Multiplatform.

أهم خطوات الانتقال والتحديات المصاحبة

1. إزالة Activities واستخدام نموذج Single Activity

CMP لا يعتمد على Activities وFragments، لذلك اعتمدنا واجهات Compose مع نظام تنقّل خاص بها، مما أعطانا تنظيمًا أفضل واستقرارًا أكبر.

2. الانتقال من Retrofit إلى Ktor

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

3. استبدال Hilt بـ Koin

Hilt مرتبط ببنية أندرويد، بينما Koin يعمل على كل المنصات بسهولة، وخفيف، ومرن.

4. الانتقال من buildSrc إلى Version Catalogs

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

5. معالجة الكود الخاص بكل منصة

رغم أننا نشارك أغلب الكود، إلا أن بعض الأمور كانت تحتاج تنفيذًا منفصلًا، مثل:

الكاميرا

التخزين

الإشعارات

تحسينات واجهة iOS بسبب طريقة الرسم باستخدام Skia

6. التحديات الخاصة بأداء واستقرار iOS

بما أن CMP على iOS لا يزال في نسخة تجريبية، قررنا اتباع نهج متوازن:

أندرويد: التطبيق بالكامل يعتمد على CMP.

iOS: يبقى تطبيقًا أصليًا حتى إصدار نسخة مستقرة في 2025.

خطتنا للمرحلة القادمة

🔹 المرحلة 1: إطلاق تطبيق أندرويد بالكامل باستخدام CMP 🔹 المرحلة 2: إعداد نظام CI/CD يدعم CMP 🔹 المرحلة 3: مراقبة أداء وإصدار CMP على iOS 🔹 المرحلة 4: التوسع لاحقًا لدعم الويب باستخدام نفس الكود 🔹 المرحلة 5: الانتقال الكامل لـ iOS عند جاهزية CMP

نصائح لبناء تطبيق أصلي جديد من البداية

استخدم Jetpack Compose للواجهة.

استخدم Ktor للشبكات.

استخدم Koin لإدارة التبعيات.

استخدم Version Catalogs لتنظيم الإصدارات.

استخدم Coil للصور.

استخدم Kotlin Serialization لمشاركة نماذج البيانات.

استخدم Room لقواعد البيانات المحلية.

استخدم DataStore للتخزين الخفيف.

قلل قدر الإمكان من أي شيفرة خاصة بأندرويد فقط.

الأداء: مقارنة بين Native وCMP وKMP

التطبيقات الأصلية: الأعلى في الأداء والاستقرار.

CMP: ممتاز للواجهات المشتركة، لكنه يضيف بعض الحمل بسبب نظام الرسم.

KMP بدون CMP: يشارك المنطق مع إبقاء الواجهة أصلية—مزيج من الأداء والمرونة.

JetBrains تعمل على تحسينات كبيرة لـ CMP على iOS، ومع حلول 2025 سيقترب الأداء كثيرًا من التطبيقات الأصلية.

الخلاصة

عملية نقل تطبيق العميل إلى Compose Multiplatform لم تكن مجرد تحديث تقني، بل كانت تجربة غيرت طريقة تفكير الفريق في Areeb Technology. تعلمنا الكثير، طوّرنا بيئة العمل، ونجحنا في بناء أساس قوي لمشاريع مستقبلية متعددة المنصات.

إذا كنت مهتمًا بنقل تطبيقك إلى Kotlin Multiplatform أو تبحث عن شريك موثوق يمتلك خبرة عملية حقيقية في CMP — نحن مستعدون لدعمك بكل خطوة.

تواصل مع آريب تكنولوجي اليوم… ودعنا نبني معًا الجيل القادم من التطبيقات متعددة المنصات.