بناء أول تطبيق لـ visionOS: ما الذي يختلف

تفتح Xcode وتنشئ مشروع visionOS فتجد شيئًا مألوفًا: SwiftUI، وبنية مشروع تعرفها، وكود يعمل من أول تشغيل. ثم تجرّبه على الجهاز فتكتشف أن نصف قراراتك التصميمية بُنيت على افتراضات لم تعد صحيحة — إصبع تلمس، وشاشة بمقاس معلوم، ومستخدم يجلس أمامها.

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

ما الذي ينتقل كما هو؟

الخبر الجيد أولًا، لأنه أكبر مما يتوقع كثيرون.

• SwiftUI بالكامل تقريبًا. الشاشات والتخطيط وإدارة الحالة تنتقل بلا تعديل جوهري.
• منطق التطبيق والشبكة والتخزين. لا علاقة لها بالمنصة.
• الحزم والمكتبات المكتوبة بـ Swift الخالص، ما لم تعتمد على UIKit مباشرة.
• أنماط المعمارية التي تتبعها في تطبيقاتك الأخرى.

المهاجر من iOS يجد نفسه منتجًا في اليوم الأول. المفاجأة تأتي في اليوم الثالث حين يبدأ الاختبار على الجهاز.

الإدخال: العين تشير واليد تنقر

هذا أكبر تغيير مفهومي، وأثره على كل شاشة.

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

ثلاث نتائج عملية:

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

لا تبنِ شيئًا على معرفة اتجاه النظر. لا يمكنك تتبّع ما ينظر إليه المستخدم لتشغيل سلوك، ومحاولة الالتفاف على ذلك تفشل في المراجعة.

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

على iOS تصمّم لإصبع تعرف موضعه. على visionOS تصمّم لنظرة لا تعرف عنها شيئًا، والنظام وحده يوصلها.

النوافذ والفضاء: ثلاثة أنماط

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

الحجم للمحتوى ثلاثي الأبعاد فقط، لا لجعل واجهة مسطّحة تبدو مميزة.

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

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

ما الذي يجب اختباره على الجهاز؟

المحاكي مفيد للتخطيط ومضلّل في كل شيء آخر.

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

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

المشاركة والوصول: ما يختلف عن الشاشة

جانب يُغفَل في أدلة البداية ويظهر أثره سريعًا مع أول مستخدم حقيقي.

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

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

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

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

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

الأداء: ميزانية لا تُساوَم

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

وثلاثة أخطاء شائعة عند القادمين من iOS:

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

صور بأحجام ضخمة. الذاكرة أضيق مما تفترض، والصورة غير المصغّرة سبب متكرر لسلوك سيئ.

رسوم متحركة معقّدة بلا داعٍ. الحركة في الفضاء أكثر إلحاحًا على العين منها على الشاشة، والأقل هنا أفضل فعلًا لا تجميلًا للكلام.

وتطبيقات المحتوى الثلاثي الأبعاد التي تُنتَج على الجهاز نفسه — مثل Pitchora Vision الذي يبني المشاهد ويصدّرها محليًا — تعيش داخل هذه الميزانية بالضرورة، لأن الإنتاج والعرض يتنافسان على الموارد نفسها.

هل تبني تطبيقًا جديدًا أم تنقل الموجود؟

ثلاثة مسارات، وأولها أرخص مما يظن كثيرون.

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

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

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

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

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

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

مزيد في الموبايل وSwift والمنتجات. ووثائق visionOS تغطي الأنماط الثلاثة وواجهات الإدخال بالتفصيل.

الخلاصة

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

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