---
read_when:
    - إقران عقدة iOS أو إعادة توصيلها
    - تمكين عقدة Apple Watch المباشرة أو استكشاف أخطائها وإصلاحها
    - تشغيل تطبيق iOS من الشيفرة المصدرية
    - تصحيح أخطاء اكتشاف Gateway أو أوامر اللوحة القماشية
summary: 'تطبيق Node لنظام iOS: الاتصال بـ Gateway، والإقران، واللوحة، واستكشاف الأخطاء وإصلاحها'
title: تطبيق iOS
x-i18n:
    generated_at: "2026-07-16T14:19:32Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 7db2f099602435837cc18fcd3e7670067d4b58b6cdb6f6502704a1565d1d1c61
    source_path: platforms/ios.md
    workflow: 16
---

التوافر: تُوزَّع إصدارات تطبيق iPhone عبر قنوات Apple عند تفعيلها لإصدار ما. ويمكن أيضًا تشغيل إصدارات التطوير المحلية من المصدر.

## ما الذي يفعله

- يتصل بـ Gateway عبر WebSocket (الشبكة المحلية LAN أو tailnet).
- يوفّر إمكانات Node: Canvas، ولقطة الشاشة، والتقاط الصور بالكاميرا، والموقع، ووضع التحدث، والتنشيط الصوتي، وملخصات Health الاختيارية.
- يتلقى أوامر `node.invoke` ويبلّغ عن أحداث حالة Node.
- يتيح تصفح مساحة عمل الوكيل المحدد للقراءة فقط من واجهة الوكلاء (الملفات): التنقل التفصيلي في المجلدات، ومعاينات النصوص المميزة صياغيًا، ومعاينات الصور، والتصدير عبر ورقة المشاركة. لا توجد عمليات كتابة؛ ويحدّ Gateway حجم المعاينات.
- يحتفظ بذاكرة تخزين مؤقت صغيرة غير متصلة بالإنترنت وللقراءة فقط لجلسات الدردشة والنصوص المنسوخة الحديثة لكل Gateway مقترن: تعرض عمليات الفتح البارد آخر نص منسوخ معروف فورًا وتحدّثه بمجرد استجابة Gateway، وتظل الدردشات الحديثة قابلة للتصفح أثناء انقطاع الاتصال، وتؤدي إعادة الضبط/النسيان إلى حذف ذاكرة التخزين المؤقت المحلية المحمية.
- يضع الرسائل النصية المرسلة أثناء انقطاع الاتصال في قائمة انتظار صادرة دائمة لكل Gateway (حتى 50): تظهر فقاعات الرسائل الموضوعة في قائمة الانتظار ضمن النص المنسوخ، وتُرسل بالترتيب عند إعادة الاتصال مع محاولات إعادة متكررة آمنة التكرار، وتظل محفوظة حتى يؤكد السجل المرجعي الإرسال، وتُعاد محاولتها بتراجع تدريجي قبل إظهار إجراء لإعادة المحاولة/الحذف، وتنتهي صلاحيتها بدلًا من إرسالها بعد 48 ساعة من عدم الاتصال؛ وتؤدي إعادة الضبط/النسيان إلى مسح قائمة الانتظار مع ذاكرة التخزين المؤقت.
- ينطق رسائل المساعد عند الطلب: اضغط مطولًا على رسالة في الدردشة واختر **Listen**. يشغّل التطبيق مقاطع `tts.speak` المدعومة من Gateway باستخدام موفّر تحويل النص إلى كلام المضبوط، ويعود إلى النطق على الجهاز عندما لا يتوفر صوت Gateway أو يتعذر تشغيله. يتوقف التشغيل عند تبديل الجلسة أو انتقال التطبيق إلى الخلفية.

## المتطلبات

- تشغيل Gateway على جهاز آخر (macOS أو Linux أو Windows عبر WSL2).
- مسار الشبكة:
  - الشبكة المحلية LAN نفسها عبر Bonjour، **أو**
  - شبكة tailnet عبر DNS-SD أحادي الإرسال (مثال للنطاق: `openclaw.internal.`)، **أو**
  - المضيف/المنفذ اليدوي (احتياطي).

## البدء السريع (الاقتران + الاتصال)

عند التشغيل الأول، يرشد التطبيق خلال شرح موجز للاقتران وصفحة
للأذونات (الإشعارات، والكاميرا، والميكروفون، والصور، وجهات الاتصال،
والتقويم، والتذكيرات، والموقع). كل إذن اختياري ويمكن تغييره
لاحقًا في **Settings** -> **Permissions**، أو في تطبيق إعدادات iOS.

1. شغّل Gateway موثّقًا بمسار يمكن لهاتفك الوصول إليه. يُعد Tailscale
   Serve المسار البعيد الموصى به:

```bash
openclaw gateway --port 18789 --tailscale serve
```

لإعداد موثوق على الشبكة المحلية LAN نفسها، استخدم `gateway.bind: "lan"` موثّقًا
بدلًا من ذلك. لا يمكن الوصول من الهاتف إلى ربط الاسترجاع الحلقي الافتراضي. إذا لم
يُضبط Gateway بعد، فشغّل `openclaw onboard` أولًا لكي يتوفر لإنشاء رمز الإعداد
مسار مصادقة برمز مميز أو كلمة مرور.

2. افتح [واجهة التحكم](/ar/web/control-ui)، وحدد **Nodes**، وانقر
   على **Pair mobile device** في صفحة **Devices**. يُوصى بالوصول الكامل
   وهو محدد افتراضيًا؛ اختر Limited access فقط عندما تريد استثناء
   عناصر التحكم الإدارية في Gateway، ثم انقر على **Create setup code**.

3. في تطبيق iOS، افتح **Settings** -> **Gateway**، وامسح رمز QR ضوئيًا (أو الصق
   رمز الإعداد)، ثم اتصل.

   إذا كان رمز الإعداد يحتوي على مساري LAN وTailscale Serve معًا، فإن التطبيق
   يختبرهما بالترتيب ويحفظ أول نقطة نهاية يمكن الوصول إليها.

4. يتصل التطبيق الرسمي تلقائيًا. إذا عرضت **Pending approval**
   طلبًا، فراجع دوره ونطاقاته قبل الموافقة عليه.

   تعرض **Settings → Gateway** ما إذا كان اتصال المشغّل المحفوظ يتمتع بوصول
   **Full** أو **Limited**. يُقيَّد إعداد `ws://` النصي الصريح عبر LAN تلقائيًا
   حفاظًا على أمان الرمز المميز لحامله. إذا كان مقيّدًا، فاضبط `wss://` أو
   Tailscale Serve، وامسح رمز وصول كامل جديدًا من واجهة التحكم أو `openclaw qr`،
   ثم أعد الاتصال لتمكين الإعدادات والترقيات.

يتطلب زر واجهة التحكم جلسة مقترنة مسبقًا مع `operator.admin`.
وكحل احتياطي عبر الطرفية، اختر Gateway مكتشفًا في تطبيق iOS (أو فعّل
Manual Host وأدخل المضيف/المنفذ)، ثم وافق على الطلب في مضيف Gateway:

```bash
openclaw devices list
openclaw devices approve <requestId>
```

إذا أعاد التطبيق محاولة الاقتران بتفاصيل مصادقة متغيرة (الدور/النطاقات/المفتاح العام)، يُستبدل الطلب المعلّق السابق ويُنشأ `requestId` جديد. شغّل `openclaw devices list` مرة أخرى قبل الموافقة.

اختياري: إذا كانت Node الخاصة بـ iOS تتصل دائمًا من شبكة فرعية خاضعة لرقابة صارمة، فيمكن تفعيل الموافقة التلقائية على Node لأول مرة باستخدام نطاقات CIDR صريحة أو عناوين IP دقيقة:

```json5
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
```

يكون هذا معطلًا افتراضيًا. ولا ينطبق إلا على اقتران `role: node` جديد بلا نطاقات مطلوبة. يظل اقتران المشغّل/المتصفح وأي تغيير في الدور أو النطاق أو البيانات الوصفية أو المفتاح العام بحاجة إلى موافقة يدوية.

5. تحقق من الاتصال:

```bash
openclaw nodes status
openclaw gateway call node.list --params "{}"
```

## ملخصات Health

يمكن لـ Node الخاصة بـ iOS إرجاع تجميع HealthKit اختياري وللقراءة فقط لليوم
التقويمي الحالي. تُعد موافقة iPhone والتخويل الصريح لأمر Gateway
بوابتين مستقلتين. راجع [ملخصات HealthKit](/platforms/ios-healthkit) لمعرفة
الإعداد والاستدعاء وحقول الحمولة وسلوك الخصوصية واستكشاف الأخطاء وإصلاحها.

افتراضيًا، يستمر تطبيق Apple Watch المصاحب في استخدام وسيط iPhone الحالي ولا
يحتاج إلى اقتران منفصل مع Gateway. أقرن الساعة بـ iPhone في تطبيق Watch من
Apple، وثبّت OpenClaw من **Watch app -> My Watch -> Available
Apps**، ثم افتح OpenClaw مرة واحدة على كلا الجهازين.

## مراجعة الموافقات على الأوامر

يمكن لاتصال مشغّل يتضمن `operator.admin`، أو اتصال
`operator.approvals` مقترن يستهدفه Gateway صراحةً، مراجعة
طلبات التنفيذ المعلقة على iPhone. تعرض بطاقة الموافقة معاينة الأمر
المنقحة من Gateway، والتحذير، وسياق المضيف، ووقت انتهاء الصلاحية، والقرارات
التي يتيحها ذلك الطلب فقط. تتلقى Apple Watch المقترنة المطالبة الآمنة
للمراجع نفسها عبر وسيط iPhone الحالي، وتتيح المجموعة المختصرة من قراري
السماح لمرة واحدة/الرفض. لا ينقل وضع Gateway المباشر للساعة مطالبات
الموافقة.

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

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

## Node مباشرة اختيارية لـ Apple Watch

يمنح الوضع المباشر الساعة هوية Node موقّعة خاصة بها واتصالًا بـ Gateway.
تستمر أوامر Node المدعومة في العمل عبر شبكة Wi-Fi أو الاتصال الخلوي للساعة أثناء
نشاط OpenClaw، حتى عندما لا يتوفر iPhone المقترن.

المتطلبات:

- أن يكون iPhone متصلًا بـ Gateway بنطاق `operator.admin`.
- أن يعلن رمز الإعداد عن نقطة نهاية Gateway من نوع `wss://` بشهادة يثق بها
  watchOS؛ وتستطلع الساعة أصل `https://` المقابل. لا يُدعم HTTP النصي الصريح ولا
  الثقة القائمة فقط على شهادة موقعة ذاتيًا أو بصمة. راجع [الاقتران المملوك لـ
  Gateway](/ar/gateway/pairing) لضبط نقطة النهاية. لا يمكن للساعة الوصول بصورة مستقلة
  إلى مسارات الاسترجاع الحلقي أو المسارات الخاصة بـ iPhone فقط أو الخاصة بـ tailnet فقط.
- يتطلب الاستخدام الخلوي Apple Watch تدعم الاتصال الخلوي مع خدمة نشطة.
- أن يكون OpenClaw نشطًا على الساعة. لا تسمح Apple لتطبيقات watchOS العادية
  بالحفاظ على اتصالات WebSocket/TCP عامة، لذلك تستخدم Node المباشرة استطلاعات HTTPS
  قصيرة وتعيد الاتصال عندما يعود التطبيق إلى الواجهة الأمامية. راجع
  [إرشادات Apple للشبكات منخفضة المستوى في watchOS](https://developer.apple.com/documentation/technotes/tn3135-low-level-networking-on-watchOS).

الإعداد:

1. على iPhone، افتح **Settings -> Apple Watch**.
2. اضغط على **Enable Direct Gateway Connection**.
3. افتح OpenClaw على الساعة قبل انتهاء صلاحية رمز الإعداد قصير العمر.
4. تحقق من صف Apple Watch المنفصل باستخدام `openclaw nodes status`.

يحتوي رمز الإعداد على بيانات اعتماد تمهيدية قصيرة العمر ومخصصة لـ Node فقط؛ تعامل معها
ككلمة مرور حتى تنتهي صلاحيتها. ولا يحتوي مطلقًا على كلمة مرور Gateway
أو رمزه المميز المحفوظين على iPhone. بعد الاقتران، تخزن الساعة رمز الجهاز المميز الخاص بها
وتحذف بيانات الاعتماد التمهيدية. لا يغطي الوضع المباشر سوى الأوامر أدناه.
وتظل الدردشة والتحدث والموافقات وتدفق إشعارات `watch.*` الحالي
ميزات تعتمد على وسيط iPhone، ولا تزال تتطلب iPhone المقترن.

أوامر Node المباشرة في watchOS:

| الواجهة       | الأوامر                         | الملاحظات                                                   |
| ------------- | ------------------------------ | ------------------------------------------------------- |
| الجهاز        | `device.info`، `device.status` | هوية الساعة والبطارية والحرارة والتخزين والشبكة. |
| الإشعارات | `system.notify`                | أثناء نشاط التطبيق؛ تتطلب إذن الساعة.     |

لا يتيح watchOS واجهة WebKit لتطبيقات الجهات الخارجية، لذلك لا تعلن Node
المباشرة للساعة عن أوامر Canvas.

## الإشعارات الفورية المدعومة بالوسيط للإصدارات الرسمية

تستخدم إصدارات iOS الرسمية الموزعة وسيط إشعارات فورية خارجيًا بدلًا من نشر رمز APNs المميز الخام إلى Gateway. تستخدم إصدارات App Store الرسمية من مسار الإصدار العام الوسيط المستضاف على `https://ios-push-relay.openclaw.ai`؛ وعنوان URL الأساسي هذا مضمّن برمجيًا لتوزيع App Store ولا يقرأ أي تجاوز.

تتطلب عمليات نشر الوسيط المخصصة مسار إصدار/نشر iOS منفصلًا عن قصد، بحيث يطابق عنوان URL الخاص بالوسيط عنوان URL الخاص بوسيط Gateway. لا يقبل مسار إصدار App Store مطلقًا عنوان URL مخصصًا للوسيط. إذا كنت تستخدم إصدارًا مخصصًا للوسيط، فعيّن عنوان URL المطابق لوسيط Gateway:

```json5
{
  gateway: {
    push: {
      apns: {
        relay: {
          baseUrl: "https://relay.example.com",
        },
      },
    },
  },
}
```

كيفية عمل التدفق:

- يسجّل تطبيق iOS لدى الوسيط باستخدام App Attest ومعاملة تطبيق StoreKit بتنسيق JWS.
- يعيد الوسيط معرّف وسيط مبهمًا مع منحة إرسال خاصة بنطاق التسجيل.
- يجلب تطبيق iOS هوية Gateway المقترن (`gateway.identity.get`) ويضمّنها في تسجيل الوسيط، بحيث يُفوّض التسجيل المدعوم بالوسيط إلى Gateway المحدد ذاك.
- يمرر التطبيق ذلك التسجيل المدعوم بالوسيط إلى Gateway المقترن باستخدام `push.apns.register`.
- يستخدم Gateway معرّف الوسيط المخزن ذاك من أجل `push.test`، والتنشيط في الخلفية، وتنبيهات التنشيط.
- إذا اتصل التطبيق لاحقًا بـ Gateway مختلف أو بإصدار ذي عنوان URL أساسي مختلف للوسيط، فإنه يحدّث تسجيل الوسيط بدلًا من إعادة استخدام الارتباط القديم.

ما **لا** يحتاج إليه Gateway لهذا المسار: لا رمز وسيط مميز على مستوى النشر، ولا مفتاح APNs مباشر لعمليات الإرسال الرسمية عبر App Store والمدعومة بالوسيط.

تدفق المشغّل المتوقع:

1. ثبّت تطبيق iOS الرسمي.
2. اختياري: عيّن `gateway.push.apns.relay.baseUrl` على Gateway فقط عند استخدام إصدار وسيط مخصص ومنفصل عن قصد.
3. أقرن التطبيق بـ Gateway واتركه يكمل الاتصال.
4. ينشر التطبيق `push.apns.register` بمجرد حصوله على رمز APNs مميز، واتصال جلسة المشغّل، ونجاح تسجيل الوسيط.
5. بعد ذلك، يمكن لكل من `push.test`، وعمليات التنشيط عند إعادة الاتصال، وتنبيهات التنشيط استخدام التسجيل المخزن والمدعوم بالوسيط.

## إشارات البقاء نشطة في الخلفية

عندما يوقظ iOS التطبيق بسبب إشعار صامت، أو تحديث في الخلفية، أو حدث تغيّر كبير في الموقع، يحاول التطبيق إعادة اتصال قصيرة بالـ Node ثم يستدعي `node.event` باستخدام `event: "node.presence.alive"`. لا يسجّل Gateway ذلك بوصفه `lastSeenAtMs`/`lastSeenReason` ضمن البيانات الوصفية للـ Node/الجهاز المقترن إلا بعد معرفة هوية جهاز الـ Node المصادَق عليها.

لا يعدّ التطبيق إيقاظ الخلفية مسجّلًا بنجاح إلا عندما تتضمن استجابة Gateway القيمة `handled: true`. قد تؤكد بوابات Gateway الأقدم استلام `node.event` باستخدام `{ "ok": true }`؛ وهذه الاستجابة متوافقة، لكنها لا تُحتسب تحديثًا دائمًا لآخر وقت ظهور.

ملاحظة حول التوافق:

- `OPENCLAW_APNS_RELAY_BASE_URL` لا يزال يعمل كتجاوز مؤقت عبر متغير بيئة لـ Gateway (يمثّل `gateway.push.apns.relay.baseUrl` المسار الذي يعطي الأولوية للإعدادات).
- يفرض وضع الإشعارات في بنية إصدار App Store مضيف الترحيل المستضاف ضمن الشيفرة، ولا يقرأ أبدًا أي تجاوز لعنوان URL الخاص بالترحيل — ولا يؤثر متغير بيئة وقت البناء `OPENCLAW_PUSH_RELAY_BASE_URL` إلا في أوضاع بناء iOS المحلية/المعزولة.

## مسار المصادقة والثقة

يوجد الترحيل لفرض قيدين لا يمكن لاستخدام APNs مباشرةً على Gateway توفيرهما لبنيات iOS الرسمية:

- لا يمكن استخدام الترحيل المستضاف إلا من خلال بنيات OpenClaw الأصلية لنظام iOS والموزعة عبر Apple.
- لا يمكن لـ Gateway إرسال إشعارات مدعومة بالترحيل إلا إلى أجهزة iOS المقترنة بذلك الـ Gateway تحديدًا.

خطوة بخطوة:

1. `iOS app -> gateway`: يقترن التطبيق بـ Gateway عبر مسار مصادقة Gateway المعتاد، ما يمنحه جلسة Node مصادَقًا عليها بالإضافة إلى جلسة مشغّل مصادَق عليها. تستدعي جلسة المشغّل `gateway.identity.get`.
2. `iOS app -> relay`: يستدعي التطبيق نقاط نهاية تسجيل الترحيل عبر HTTPS باستخدام إثبات App Attest بالإضافة إلى JWS لمعاملة تطبيق StoreKit. يتحقق الترحيل من معرّف الحزمة وإثبات App Attest وإثبات التوزيع من Apple، ويشترط مسار التوزيع الرسمي/الإنتاجي — وهذا ما يمنع بنيات Xcode/التطوير المحلية من استخدام الترحيل المستضاف، إذ لا يمكن لبنية محلية استيفاء إثبات التوزيع الرسمي من Apple.
3. `gateway identity delegation`: قبل التسجيل في الترحيل، يجلب التطبيق هوية Gateway المقترن من `gateway.identity.get` ويضمّنها في حمولة تسجيل الترحيل. يعيد الترحيل معرّف ترحيل ومنحة إرسال مقيّدة بالتسجيل ومفوّضة إلى هوية Gateway تلك.
4. `gateway -> relay`: يخزّن Gateway معرّف الترحيل ومنحة الإرسال الواردين من `push.apns.register`. عند `push.test`، وعمليات الإيقاظ لإعادة الاتصال، وتنبيهات الإيقاظ، يوقّع Gateway طلب الإرسال باستخدام هوية جهازه؛ ويتحقق الترحيل من منحة الإرسال المخزّنة ومن توقيع Gateway بمقارنتهما بهوية Gateway المفوّضة أثناء التسجيل. لا يمكن لـ Gateway آخر إعادة استخدام ذلك التسجيل المخزّن، حتى إذا حصل على المعرّف بطريقة ما.
5. `relay -> APNs`: يمتلك الترحيل بيانات اعتماد APNs الإنتاجية ورمز APNs الخام للبنية الرسمية. لا يخزّن Gateway رمز APNs الخام أبدًا للبنيات الرسمية المدعومة بالترحيل؛ ويرسل الترحيل الإشعار النهائي إلى APNs نيابةً عن Gateway المقترن.

سبب إنشاء هذا التصميم: إبقاء بيانات اعتماد APNs الإنتاجية خارج بوابات Gateway الخاصة بالمستخدمين، وتجنّب تخزين رموز APNs الخام للبنيات الرسمية على Gateway، وقصر استخدام الترحيل المستضاف على بنيات OpenClaw الرسمية لنظام iOS، ومنع أي Gateway من إرسال إشعارات إيقاظ إلى أجهزة iOS التي يملكها Gateway مختلف.

تظل البنيات المحلية/اليدوية معتمدة على APNs المباشر. إذا كنت تختبر تلك البنيات من دون الترحيل، فسيظل Gateway بحاجة إلى بيانات اعتماد APNs المباشرة:

```bash
export OPENCLAW_APNS_TEAM_ID="TEAMID"
export OPENCLAW_APNS_KEY_ID="KEYID"
export OPENCLAW_APNS_PRIVATE_KEY_P8="$(cat /path/to/AuthKey_KEYID.p8)"
```

هذه متغيرات بيئة لوقت تشغيل مضيف Gateway، وليست إعدادات Fastlane. لا يخزّن `apps/ios/fastlane/.env` سوى بيانات مصادقة App Store Connect مثل `APP_STORE_CONNECT_KEY_ID` و`APP_STORE_CONNECT_ISSUER_ID`؛ ولا يضبط تسليم APNs المباشر لبنيات iOS المحلية.

التخزين الموصى به على مضيف Gateway، بما يتوافق مع بيانات اعتماد الموفّرين الأخرى ضمن `~/.openclaw/credentials/`:

```bash
mkdir -p ~/.openclaw/credentials/apns
chmod 700 ~/.openclaw/credentials/apns
mv /path/to/AuthKey_KEYID.p8 ~/.openclaw/credentials/apns/AuthKey_KEYID.p8
chmod 600 ~/.openclaw/credentials/apns/AuthKey_KEYID.p8
export OPENCLAW_APNS_PRIVATE_KEY_PATH="$HOME/.openclaw/credentials/apns/AuthKey_KEYID.p8"
```

لا تُدرج ملف `.p8` في الالتزامات البرمجية ولا تضعه ضمن نسخة المستودع المحلية.

## مسارات الاكتشاف

### Bonjour (الشبكة المحلية)

يستعرض تطبيق iOS القيمة `_openclaw-gw._tcp` على `local.`، وعند ضبطه، يستعرض أيضًا نطاق اكتشاف DNS-SD واسع النطاق نفسه. تظهر بوابات Gateway الموجودة على الشبكة المحلية نفسها تلقائيًا من `local.`؛ ويمكن للاكتشاف عبر الشبكات استخدام النطاق واسع النطاق المضبوط من دون تغيير نوع الإشارة.

### Tailnet (عبر الشبكات)

إذا كان mDNS محظورًا، فاستخدم منطقة DNS-SD أحادية البث (اختر نطاقًا؛ مثال: `openclaw.internal.`) وDNS المنقسم في Tailscale. راجع [Bonjour](/ar/gateway/bonjour) للاطلاع على مثال CoreDNS.

### المضيف/المنفذ اليدوي

في Settings، فعّل **Manual Host** وأدخل مضيف Gateway والمنفذ (القيمة الافتراضية `18789`).

## بوابات Gateway متعددة

يحتفظ التطبيق بسجل لكل بوابات Gateway التي اقترن بها، بحيث يمكنك التبديل بينها من دون الاقتران مرة أخرى:

- يعرض **Settings -> Gateway** قائمة **Paired Gateways** مع تمييز Gateway النشط. اضغط على إدخال للتبديل؛ ينهي التطبيق الجلسات الحالية ويعيد الاتصال بـ Gateway المحدد. تظهر قائمة تبديل سريع بجوار صف الاتصال عند اقتران أكثر من Gateway واحد.
- تُخزّن بيانات الاعتماد وقرارات الثقة بـ TLS والتفضيلات الخاصة بكل Gateway وسجل المحادثات المخزّن مؤقتًا لكل Gateway على حدة. لا يؤدي التبديل أبدًا إلى خلط الحالة بين بوابات Gateway، ويتبع تسجيل الإشعارات Gateway النشط.
- مرّر Gateway مقترنًا (أو استخدم قائمة السياق الخاصة به) لتنفيذ **Forget**، ما يزيل بيانات اعتماده ورموز الجهاز وتثبيت TLS والمحادثات المخزّنة مؤقتًا.
- يجب أن تكون بوابات Gateway المكتشفة ظاهرة على الشبكة كي تتمكن من التبديل إليها؛ وتعيد بوابات Gateway اليدوية الاتصال باستخدام المضيف والمنفذ المحفوظين.

## Canvas وA2UI

يعرض Node الخاص بنظام iOS لوحة Canvas ضمن WKWebView. استخدم `node.invoke` للتحكم بها:

```bash
openclaw nodes invoke --node "iOS Node" --command canvas.navigate --params '{"url":"http://<gateway-host>:18789/__openclaw__/canvas/"}'
```

ملاحظات:

- يقدّم مضيف Canvas في Gateway الموردين `/__openclaw__/canvas/` و`/__openclaw__/a2ui/` من خادم HTTP الخاص بـ Gateway (المنفذ نفسه المستخدم لـ `gateway.port`، والقيمة الافتراضية `18789`).
- يحتفظ Node الخاص بنظام iOS بالهيكل المضمّن بوصفه العرض الافتراضي عند الاتصال. يستخدم `canvas.a2ui.push` و`canvas.a2ui.reset` صفحة A2UI المضمّنة والمملوكة للتطبيق.
- صفحات A2UI البعيدة الخاصة بـ Gateway مخصصة للعرض فقط على iOS؛ ولا تُقبل إجراءات أزرار A2UI الأصلية إلا من الصفحات المضمّنة والمملوكة للتطبيق.
- عُد إلى الهيكل المضمّن باستخدام `canvas.navigate` و`{"url":""}`.

## العلاقة مع Computer Use

تطبيق iOS هو واجهة Node محمولة، وليس واجهة خلفية لـ Codex Computer Use. يتحكم Codex Computer Use و`cua-driver mcp` في سطح مكتب macOS محلي عبر أدوات MCP؛ بينما يتيح تطبيق iOS إمكانات iPhone من خلال أوامر Node في OpenClaw، مثل `canvas.*` و`camera.*` و`screen.*` و`location.*` و`talk.*`.

لا يزال بإمكان الوكلاء تشغيل تطبيق iOS عبر OpenClaw من خلال استدعاء أوامر Node، لكن هذه الاستدعاءات تمر عبر بروتوكول Node في Gateway وتخضع لقيود iOS في المقدمة/الخلفية. استخدم [Codex Computer Use](/ar/plugins/codex-computer-use) للتحكم في سطح المكتب المحلي، وهذه الصفحة للاطلاع على إمكانات Node في iOS.

### تقييم Canvas / اللقطة

```bash
openclaw nodes invoke --node "iOS Node" --command canvas.eval --params '{"javaScript":"(() => { const {ctx} = window.__openclaw; ctx.clearRect(0,0,innerWidth,innerHeight); ctx.lineWidth=6; ctx.strokeStyle=\"#ff2d55\"; ctx.beginPath(); ctx.moveTo(40,40); ctx.lineTo(innerWidth-40, innerHeight-40); ctx.stroke(); return \"ok\"; })()"}'
```

```bash
openclaw nodes invoke --node "iOS Node" --command canvas.snapshot --params '{"maxWidth":900,"format":"jpeg"}'
```

## الإيقاظ الصوتي ووضع التحدث

- يتوفر الإيقاظ الصوتي ووضع التحدث في Settings.
- يستخدم Talk الفوري من OpenAI اتصال WebRTC مملوكًا للعميل عندما تكون `talk.realtime.transport` هي `webrtc`؛ ويظل إعداد `gateway-relay` الصريح مملوكًا لـ Gateway. راجع [وضع التحدث](/ar/nodes/talk).
- تعلن عقد iOS القادرة على Talk عن إمكانية `talk`، ويمكنها التصريح بـ `talk.ptt.start` و`talk.ptt.stop` و`talk.ptt.cancel` و`talk.ptt.once`؛ ويسمح Gateway افتراضيًا بأوامر الضغط للتحدث تلك للعقد الموثوقة القادرة على Talk.
- قد يعلّق iOS الصوت في الخلفية؛ لذا تعامل مع الميزات الصوتية على أنها تعمل بأفضل جهد عندما لا يكون التطبيق نشطًا.

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

- `NODE_BACKGROUND_UNAVAILABLE`: انقل تطبيق iOS إلى المقدمة (تتطلب أوامر Canvas/الكاميرا/الشاشة ذلك).
- `A2UI_HOST_UNAVAILABLE`: تعذّر الوصول إلى صفحة A2UI المضمّنة في WebView الخاص بالتطبيق؛ أبقِ التطبيق في المقدمة على علامة تبويب Screen وأعد المحاولة.
- لا تظهر مطالبة الاقتران مطلقًا: شغّل `openclaw devices list` ووافق يدويًا.
- لا تعرض Watch أي حالة لـ iPhone: تأكد من أن iPhone يبلغ عن `watchPaired: true`
  و`watchAppInstalled: true` في `watch.status`. إذا كانت حالة الاقتران false، فاقرن
  Watch في تطبيق Watch من Apple. وإذا كانت حالة التثبيت false، فثبّت التطبيق المصاحب
  من **My Watch -> Available Apps**. بعد أي من التغييرين، افتح OpenClaw على
  Watch مرة واحدة؛ لا تزال إمكانية الوصول الفورية تتطلب تشغيل كلا التطبيقين،
  بينما يمكن أن تصل التحديثات الموضوعة في قائمة الانتظار لاحقًا في الخلفية.
- تفشل إعادة الاتصال بعد إعادة التثبيت: مُسح رمز الاقتران من Keychain؛ أعد إقران Node.

## مستندات ذات صلة

- [الاقتران](/ar/channels/pairing)
- [الاكتشاف](/ar/gateway/discovery)
- [Bonjour](/ar/gateway/bonjour)
