Kotlin مقابل SwiftUI: الحفاظ على منتج واحد متناسق على iOS وAndroid

لماذا من الصعب مواءمة منتج واحد عبر تقنيتين\n\nحتى عندما تتطابق قائمة الميزات، قد يبدو التجربة مختلفة على iOS وAndroid. لكل منصة افتراضاتها الافتراضية. يميل iOS إلى أشرطة التبويب، إيماءات السحب، والأوراق المنبثقة. يتوقع مستخدمو Android زر رجوع مرئيًا، وسلوك رجوع النظام الموثوق، وأنماط قوائم ومربعات حوار مختلفة. عندما تبني نفس المنتج مرتين، تتراكم هذه الافتراضات الصغيرة.\n\nKotlin مقابل SwiftUI ليس مجرد اختيار لغة أو إطار عمل. إنه مجموعتان من الافتراضات حول كيفية ظهور الشاشات، كيفية تحديث البيانات، وكيف يجب أن يتصرف إدخال المستخدم. إذا كُتبت المتطلبات كـ "اجعلها مثل iOS" أو "انسخ Android"، فستبدو أحد النسخ دائمًا كحل وسط.\n\nعادةً ما يفقد الفرق الاتساق في الفجوات بين الشاشات ذات المسار السهل. يبدو التدفق متوافقًا في مراجعة التصميم، ثم ينحرف بمجرد إضافة حالات التحميل، مطالبات الأذونات، أخطاء الشبكة، وحالات "ماذا لو غادر المستخدم وعاد".\n\nغالبًا ما ينكسر التماثل أولًا في أماكن متوقعة: يتغير ترتيب الشاشات بينما يبسط كل فريق التدفق، يختلف سلوك الرجوع وإلغاء العملية، تحصل حالات الفارغ/التحميل/الخطأ على نصوص مختلفة، تقبل حقول النموذج أحرفًا مختلفة، ويتغير توقيت التحقق (أثناء الكتابة مقابل عند فقد التركيز مقابل عند الإرسال).\n\nالهدف العملي ليس واجهة متطابقة حرفيًا. الهدف هو مجموعة واحدة من المتطلبات تصف السلوك بوضوح كافٍ ليصل كلا المكدسين إلى نفس النتيجة: نفس الخطوات، نفس القرارات، نفس الحالات الطرفية، ونفس النتائج.\n\n## نهج عملي لمتطلبات مشتركة\n\nالجزء الصعب ليس الأدوات. إنه الحفاظ على تعريف منتج واحد حتى يتصرف التطبيقان بنفس الشكل، حتى لو اختلفت الواجهة قليلًا.\n\nابدأ بتقسيم المتطلبات إلى دلوين:\n\n- يجب أن تتطابق: ترتيب التدفق، الحالات الرئيسية (التحميل/الفارغ/الخطأ)، قواعد الحقول، والنص الظاهر للمستخدم.\n- يمكن أن تكون محلية للمنصة: الانتقالات، تصميم عناصر التحكم، والخيارات التخطيطية الصغيرة.\n\nعرّف المفاهيم المشتركة بلغة بسيطة قبل أن يكتب أحد الشيفرة. اتفق على ما يعنيه "الشاشة"، وما يعنيه "المسار" (بما في ذلك معلمات مثل userId)، وما الذي يُعد "حقل نموذج" (النوع، العنصر النائب، الإلزامي، لوحة المفاتيح)، وما الذي يتضمنه "حالة خطأ" (الرسالة، التمييز، ومتى تُزال). تقلل هذه التعاريف النقاشات لاحقًا لأن كلا الفريقين يستهدفان نفس الهدف.\n\nاكتب معايير قبول تصف النتائج، لا الأطر. مثال: "عند نقر المستخدم استمرار، عطل الزر، أظهر مؤشر تحميل، ومنع الإرسال المزدوج حتى ينتهي الطلب." هذا واضح لكلا المكدسين دون أن يفرض طريقة التنفيذ.\n\nاحتفظ بمصدر واحد للحقيقة للتفاصيل التي يلاحظها المستخدمون: النص (العناوين، نص الأزرار، نص المساعدة، رسائل الخطأ)، سلوك الحالة (تحميل/نجاح/فارغ/غير متصل/رفض الأذونات)، قواعد الحقول (إلزامي، الحد الأدنى للطول، الأحرف المسموح بها، التنسيق)، الأحداث الرئيسية (إرسال/إلغاء/رجوع/إعادة المحاولة/انتهاء المدة)، وأسماء التحليلات إن كنت تتعقبها.\n\nمثال بسيط: لنموذج تسجيل، قرر أن "كلمة المرور يجب أن تكون 8 أحرف أو أكثر، أظهر تلميح القاعدة بعد أول فقد تركيز، وامسح الخطأ أثناء كتابة المستخدم." يمكن أن تبدو الواجهة مختلفة؛ لا يجب أن يختلف السلوك.\n\n## التنقل: مطابقة التدفقات دون إجبار واجهة متطابقة\n\nرشِد رحلة المستخدم، لا الشاشات. اكتب التدفق كخطوات يتخذها المستخدم لإتمام مهمة، مثل "تصفح - افتح التفاصيل - عدّل - أكد - تم." بمجرد وضوح المسار، يمكنك اختيار أفضل نمط تنقل لكل منصة دون تغيير ما يفعله المنتج.\n\nغالبًا ما يفضّل iOS الأوراق المنبثقة للمهام القصيرة والإغلاق الواضح. يميل Android إلى سجل الرجوع والزر النظامي. كلاهما يمكن أن يدعم نفس التدفق إذا حددت القواعد مقدمًا.\n\nيمكنك مزج اللبنات المعتادة (التبويبات للمناطق العليا، الستاك للدخول العميق، النوافذ/الأوراق للمهام المركزة، الروابط العميقة، خطوات التأكيد للإجراءات عالية الخطورة) طالما أن التدفق والنتائج لا تتغير.\n\nللحفاظ على المتطلبات متسقة، سمّ المسارات بنفس الطريقة على النظامين وابق مدخلاتها متطابقة. "orderDetails(orderId)" يجب أن تعني الشيء نفسه في كل مكان، بما في ذلك ما يحدث عندما يكون المعرف مفقودًا أو غير صالح.\n\nاشرح سلوك الرجوع وقواعد الإغلاق صراحةً، لأن هنا يحدث الانحراف:\n\n- ماذا يفعل الرجوع من كل شاشة (حفظ، تجاهل، سؤال)\n- ما إذا كانت النافذة المنبثقة قابلة للإغلاق (وماذا يعني الإغلاق)\n- أي الشاشات لا يجب أن تكون قابلة للوصول مرتين (تجنب الازدواج)\n- كيف تتصرف الروابط العميقة إذا لم يكن المستخدم مسجلاً\n\nمثال: في تدفق التسجيل، قد تعرض iOS "الشروط" كـورقة بينما يدفع Android الشاشة إلى الستاك. هذا مقبول إذا أعاد كلاهما النتيجة نفسها (قبول أو رفض) واستأنفا التسجيل في نفس النقطة.\n\n## الحالة: الحفاظ على سلوك متسق\n\nإذا شعرت التطبيقات "مختلفة" حتى عندما تبدو الشاشات متشابهة، فعادةً السبب هو الحالة. قبل مقارنة تفاصيل التنفيذ، اتفق على الحالات التي يمكن أن تكون فيها الشاشة وماذا يُسمح للمستخدم أن يفعل في كل حالة.\n\nاكتب خطة الحالة بكلمات بسيطة أولًا، واجعلها قابلة للتكرار:\n\n- التحميل: أظهر مؤشر تحميل وعطّل الإجراءات الأساسية\n- الفارغ: اشرح ما المفقود واظهر الإجراء التالي الأفضل\n- الخطأ: اظهر رسالة واضحة وخيار إعادة المحاولة\n- النجاح: اظهر البيانات واستمر في تمكين الإجراءات\n- التحديث: احتفظ بالبيانات القديمة مرئية أثناء تشغيل التحديث\n\nثم قرر أين تعيش الحالة. حالة على مستوى الشاشة مناسبة لتفاصيل واجهة محلية (اختيار التبويب، التركيز). الحالة على مستوى التطبيق أفضل للأشياء التي يعتمد عليها التطبيق بأكمله (المستخدم المسجّل، أعلام المزايا، الملف الشخصي المؤقت). المفتاح هو الاتساق: إذا كان "تسجيل الخروج" مستوى تطبيق على Android لكن يُعامل كمستوى شاشة على iOS، ستحصل على فجوات مثل عرض بيانات قديمة على منصة واحدة.\n\nاجعل التأثيرات الجانبية صريحة. التحديث، إعادة المحاولة، الإرسال، الحذف، والتحديثات المتفائلة كلها تغيّر الحالة. عرّف ما يحدث عند النجاح والفشل، وماذا يرى المستخدم أثناء العملية.\n\nمثال: قائمة "الطلبات".\n\nعند السحب للتحديث، هل تبقي القائمة القديمة مرئية (تحديث) أم تستبدلها بحالة تحميل كاملة؟ عند فشل التحديث، هل تحتفظ بآخر قائمة جيدة وتعرض خطأ صغير، أم تتحول إلى حالة خطأ كاملة؟ إذا أجاب الفريقان بطريقة مختلفة، سيشعر المنتج بعدم الاتساق سريعًا.\n\nأخيرًا، اتفق على قواعد التخزين المؤقت وإعادة التهيئة. قرر ما البيانات الآمنة لإعادة الاستخدام (مثل آخر قائمة محمّلة) وما الذي يجب تحديثه دائمًا (مثل حالة الدفع). وعرّف أيضًا متى تعيد الحالة تهيئتها: عند مغادرة الشاشة، تبديل الحسابات، أو بعد إرسال ناجح.\n\n## النماذج: سلوك الحقول الذي لا يجب أن ينحرف\n\nالنماذج هي المكان الذي تتحول فيه الاختلافات الصغيرة إلى تذاكر دعم. شاشة تسجيل تبدو "قريبة بما فيه الكفاية" يمكن أن تتصرف بشكل مختلف، والمستخدمون يلاحظون بسرعة.\n\nابدأ بمواصفة نموذج مرجعية لا تت tied إلى أي إطار UI. اكتبها كعقد: أسماء الحقول، الأنواع، الافتراضيات، ومتى يظهر كل حقل. مثال: "اسم الشركة مخفي ما لم يكن نوع الحساب = Business. نوع الحساب الافتراضي = Personal. البلد يفضّل من إعدادات الجهاز. رمز العرض اختياري."\n\nثم عرّف التفاعلات التي يتوقع الناس أن تكون نفسها على النظامين. لا تترك هذه كـ"سلوك قياسي" لأن معنى "قياسي" يختلف.\n\n- نوع لوحة المفاتيح لكل حقل\n- الملء التلقائي والسلوك مع بيانات الاعتماد المحفوظة\n- ترتيب التركيز والتسميات Next/Return\n- قواعد الإرسال (معطل حتى يكون صالحًا مقابل السماح مع أخطاء)\n- سلوك التحميل (ماذا يغلق، ماذا يبقى قابلاً للتعديل)\n\nقرر كيف تظهر الأخطاء (ضمن السطر، ملخص، أو كلاهما) ومتى تظهر (عند فقد التركيز، عند الإرسال، أو بعد أول تعديل). قاعدة شائعة تعمل جيدًا: لا تظهر الأخطاء حتى يحاول المستخدم الإرسال، ثم حافظ على تحديث الأخطاء المضمنة أثناء الكتابة.\n\nخطط التحقق غير المتزامن مقدمًا. إذا كانت "توافر اسم المستخدم" تتطلب طلب شبكة، عرّف كيفية التعامل مع الطلبات البطيئة أو الفاشلة: أظهر "جارٍ التحقق..."، خرّض الكتابة (debounce)، تجاهل الاستجابات القديمة، وميّز "الاسم محجوز" عن "خطأ شبكة، حاول لاحقًا." بدون هذا، تنجرف التنفيذات بسهولة.\n\n## التحقق: مجموعة قواعد واحدة، تنفيذان\n\nالتحقق هو المكان الذي ينخفض فيه التماثل بهدوء. أحد التطبيقات يمنع مدخلًا، والآخر يسمح به، وتأتي تذاكر الدعم. الحل ليس مكتبة ذكية؛ هو الاتفاق على مجموعة قواعد واحدة بلغة بسيطة، ثم تنفيذها مرتين.\n\nاكتب كل قاعدة كجملة يمكن لغير المطورين اختبارها. مثال: "يجب أن تكون كلمة المرور 12 حرفًا على الأقل وتحتوي على رقم." "يجب أن يتضمن رقم الهاتف رمز البلد." "تاريخ الميلاد يجب أن يكون تاريخًا حقيقيًا وأن يكون المستخدم 18+." تصبح هذه الجمل مصدر الحقيقة.\n\n### افصل ما يعمل على الهاتف عما يعمل على الخادم\n\nتفحصات جانب العميل تركز على إرجاع سريع للأخطاء الواضحة. تفحصات الخادم هي البوابة النهائية ويجب أن تكون أشد لأنها تحمي البيانات والأمن. إذا سمح العميل بشيء يرفضه الخادم، أظهر نفس الرسالة وميّز نفس الحقل حتى لا يحير المستخدم.\n\nعرّف نص الخطأ ونبرة الرسائل مرة واحدة، ثم أعد استخدامهما على المنصتين. قرر تفاصيل مثل ما إذا كنت تقول "أدخل" أم "المرجو إدخال"، ما إذا كنت تستخدم حالة الجملة، ومدى التحديد. تفاوت صغير في الصياغة يمكن أن يجعل المنتج يبدو مختلفًا.\n\nقواعد التنسيق واللوكاليز يجب تدوينها، لا التخمين بها. اتفق على ما تقبله وكيف تعرضه، خاصة أرقام الهواتف، التواريخ (بما في ذلك افتراضات المنطقة الزمنية)، العملة، والأسماء/العناوين.\n\nسيناريو بسيط: نموذج التسجيل يقبل "+44 7700 900123" على Android لكنه يرفض المسافات على iOS. إذا كانت القاعدة "المسافات مسموحة وتخزن كأرقام فقط"، يمكن للتطبيقين توجيه المستخدم بنفس الطريقة وتخزين القيمة النظيفة نفسها.\n\n## خطوة بخطوة: كيف تحافظ على التماثل أثناء البناء\n\nلا تبدأ من الشيفرة. ابدأ بمواصفة محايدة يعاملها الفريقان كمصدر واحد للحقيقة.\n\n### 1) اكتب مواصفة محايدة أولًا\n\nاستخدم صفحة واحدة لكل تدفق، واجعلها ملموسة: قصة مستخدم، جدول حالات صغير، وقواعد الحقول.\n\nلتسجيل، عرّف حالات مثل Idle، Editing، Submitting، Success، Error. ثم اكتب ما يراه المستخدم وماذا يفعل التطبيق في كل حالة. أدرج تفاصيل مثل اقتطاع المسافات، متى تظهر الأخطاء (عند فقد التركيز مقابل عند الإرسال)، وماذا يحدث عندما يرفض الخادم البريد الإلكتروني.\n\n### 2) ابنِ بقائمة تحقق للتماثل\n\nقبل أن يبدأ أحد في تنفيذ الواجهة، أنشئ قائمة تحقق شاشة بشاشة يجب أن يجتازها iOS وAndroid: المسارات وسلوك الرجوع، الأحداث والنتائج الرئيسية، انتقالات الحالة وسلوك التحميل، سلوك الحقول، ومعالجة الأخطاء.\n\n### 3) اختبر نفس السيناريوهات على كلاهما\n\nشغّل نفس المجموعة في كل مرة: مسار النجاح، ثم حالات الحافة (شبكة بطيئة، خطأ خادم، مدخل غير صالح، واستئناف التطبيق بعد الخلفية).\n\n### 4) راجع الفروقات أسبوعيًا\n\nاحتفظ بسجل قصير للتماثل حتى لا تصبح الفروقات دائمة: ما الذي تغيّر، لماذا تغيّر، وهل هو متطلب أم عرف للمنصة أم خطأ، وماذا يجب تحديثه (المواصفة، iOS، Android، أو الثلاثة). التقط الانحراف مبكرًا عندما تظل الإصلاحات صغيرة.\n\n## أخطاء شائعة ترتكبها الفرق\n\nأسهل طريقة لفقدان التماثل بين iOS وAndroid هي التعامل مع العمل كـ"اجعلنها تبدو متشابهة." مطابقة السلوك أهم من مطابقة البيكسل.\n\nفخ شائع هو نسخ تفاصيل واجهة من منصة إلى أخرى بدلًا من كتابة نية مشتركة. يمكن أن تبدو شاشتان مختلفتين وتكونان "متماثلتين" إذا تحملا، فشلا، وتعافيا بنفس الطريقة.\n\nفخ آخر هو تجاهل توقعات المنصة. يتوقع مستخدمو Android أن يعمل زر الرجوع النظامي بثبات. يتوقع مستخدمو iOS غالبًا أن يعمل السحب للوراء في معظم الستاكات، وأن تبدو الأوراق ومربعات الحوار أصلية. إن قاومت هذه التوقعات، سيلوم الناس التطبيق.\n\nأخطاء تظهر مرارًا:\n\n- نسخ الواجهة بدلًا من تعريف السلوك (الحالات، الانتقالات، معالجة الفارغ/الخطأ)\n- كسر عادات التنقل الأصلية للحفاظ على شاشات "متطابقة"\n- ترك معالجة الأخطاء تنحرف (منصة تعرض حظرًا بمنبثق بينما الأخرى تحاول بهدوء إعادة المحاولة)\n- التحقق بشكل مختلف على العميل مقابل الخادم فيحدث تضارب رسائل للمستخدمين\n- استخدام افتراضات مختلفة (الكتابة التلقائية الكبيرة، نوع لوحة المفاتيح، ترتيب التركيز) فيشعر النماذج بعدم الاتساق\n\nمثال سريع: إذا أظهر iOS "كلمة المرور ضعيفة جدًا" أثناء الكتابة، لكن Android ينتظر حتى الإرسال، سيظن المستخدم أن أحد التطبيقات أكثر صرامة. قرر القاعدة والتوقيت مرة واحدة، ثم نفّذها في كلتا الحالتين.\n\n## قائمة تحقق سريعة قبل الإطلاق\n\nقبل الإصدار، قم بتمرير واحد يركز فقط على التماثل: ليس "هل تبدو متطابقة؟"، بل "هل تعني الشيء نفسه؟"\n\n- التدفقات والمدخلات تتطابق في النية: المسارات موجودة على كلا النظامين بنفس المعلمات.\n- كل شاشة تتعامل مع الحالات الأساسية: تحميل، فارغ، خطأ، وزر إعادة المحاولة يعيد نفس الطلب ويعيد المستخدم لنفس المكان.\n- النماذج تتصرف بنفس الطريقة على الأطراف: الحقول الإلزامية مقابل الاختيارية، اقتطاع المسافات، نوع لوحة المفاتيح، التصحيح التلقائي، وماذا يفعل Next/Done.\n- قواعد التحقق تتطابق للمدخل نفسه: تُرفض المدخلات على كلا النظامين لنفس الأسباب وبنفس النبرة.\n- التحليلات (إن وُجدت) تطلق في نفس اللحظة: عرّف اللحظة، لا الإجراء في الواجهة.\n\nلالتقاط الانحراف بسرعة، اختر تدفقًا واحدًا حاسمًا (مثل التسجيل) وجرّبه 10 مرات مع صنع أخطاء عمدية: اترك حقولًا فارغة، أدخل رمزًا غير صالح، افصل الشبكة، دوّر الهاتف، ضع التطبيق في الخلفية أثناء الطلب. إن اختلفت النتيجة، فمتطلباتك ليست مشتركة بما يكفي بعد.\n\n## سيناريو مثالي: تدفق تسجيل مبني على كلا المكدسين\n\nتخيل نفس تدفق التسجيل مبنيًا مرتين: Kotlin على Android وSwiftUI على iOS. المتطلبات بسيطة: بريد إلكتروني وكلمة مرور، ثم شاشة رمز التحقق، ثم نجاح.\n\nيمكن أن يختلف التنقل في المظهر دون تغيير ما يجب على المستخدم إنجازه. على Android قد تدفع الشاشات وتعود إلى الخلف لتعديل البريد. على iOS قد تستخدم NavigationStack وتعرض خطوة الكود كوجهة. القاعدة تبقى: نفس الخطوات، نفس نقاط الخروج (رجوع، إعادة إرسال الكود، تغيير البريد)، ونفس معالجة الأخطاء.\n\nللحفاظ على السلوك متماشيًا، عرّف حالات مشتركة بكلمات بسيطة قبل كتابة أي واجهة برمجية:\n\n- Idle: المستخدم لم يرسل بعد\n- Editing: المستخدم يغيّر الحقول\n- Submitting: طلب جارٍ، المدخلات معطّلة\n- NeedsVerification: الحساب أنشئ، ينتظر الكود\n- Verified: الكود مقبول، التقدم\n- Error: أظهر رسالة، احتفظ بالبيانات المدخلة\n\nثم اقفل قواعد التحقق بحيث تطابق بالضبط، حتى لو اختلفت عناصر التحكم:\n\n- Email: مطلوب، اقتطاع المسافات، يجب أن يطابق نمط الإيميل\n- Password: مطلوب، 8-64 حرفًا، خانة واحدة على الأقل رقم، وخانة واحدة على الأقل حرف\n- Verification code: مطلوب، بالضبط 6 أرقام، رقمي فقط\n- توقيت الأخطاء: اختر قاعدة واحدة (بعد الإرسال، أو بعد فقد التركيز) واحتفظ بها ثابتة\n\nالتعديلات الخاصة بالمنصة مقبولة عندما تغير العرض لا المعنى. على سبيل المثال، قد يستخدم iOS تعبئة الكود لمرة واحدة، بينما قد يعرض Android التقاط رسالة SMS. وثّق: ماذا يتغير (طريقة الإدخال)، ماذا يبقى كما هو (6 أرقام مطلوبة، نفس نص الخطأ)، وماذا ستختبر على كلا المنصتين (إعادة المحاولة، إعادة الإرسال، الرجوع، خطأ عدم الاتصال).\n\n## الخطوات التالية: حافظ على اتساق المتطلبات مع نمو التطبيق\n\nبعد الإصدار الأول، يبدأ الانحراف بهدوء: تعديل صغير على Android، إصلاح سريع على iOS، وسرعان ما تتعامل مع سلوكيات غير متطابقة. أبسط وقاية هي جعل الاتساق جزءًا من سير العمل الأسبوعي، لا مشروع تنظيف لاحق.\n\n### حوّل المتطلبات إلى مواصفة ميزة قابلة لإعادة الاستخدام\n\nأنشئ قالبًا قصيرًا تعيد استخدامه لكل ميزة جديدة. ركّز على السلوك، لا تفاصيل الواجهة، حتى يستطيع كلا المكدسين تنفيذه بنفس الطريقة.\n\nاشمل: هدف المستخدم ومعايير النجاح، الشاشات وأحداث التنقل (بما في ذلك سلوك الرجوع)، قواعد الحالة (تحميل/فارغ/خطأ/إعادة المحاولة/غير متصل)، قواعد النموذج (أنواع الحقول، الأقنعة، نوع لوحة المفاتيح، نص المساعدة)، وقواعد التحقق (متى تعمل، الرسائل، حظر أم تحذير).\n\nمواصفة جيدة تقرأ كملاحظات اختبار. إن تغيّر تفصيل، تتغيّر المواصفة أولًا.\n\n### أضف مراجعة تماثل لتعريف الإنهاء\n\nاجعل التماثل خطوة صغيرة قابلة للتكرار. عندما تُعَلّم ميزة مكتملة، أجرِ فحصًا جنبًا إلى جنب سريعًا قبل الدمج أو الإطلاق. شخص واحد يمرّ بنفس المسار على النظامين ويُدوّن الفروقات. قلّة من البنود في قائمة تحقق تحصّل توقيع موافقة.\n\nإذا أردت مكانًا واحدًا لتعريف نماذج البيانات وقواعد العمل قبل توليد تطبيقات أصلية، فإن AppMaster (appmaster.io) مصمّم لبناء تطبيقات مكتملة، بما في ذلك الخلفية والويب والمحمول. حتى مع منصة مشتركة، احتفظ بقائمة التماثل: السلوك، الحالات، والنصوص لا زالت قرارات منتج وتتطلب مراجعة متعمدة.\n\nالهدف الطويل الأمد بسيط: عندما تتطور المتطلبات، يتطور كلا التطبيقين في نفس الأسبوع، بنفس الطريقة، دون مفاجآت.