# لماذا تتأخر بطاقة Apple Wallet في التحديث

> على Android يتغير العداد في الحال، وعلى iPhone يتغير حين يفتح الزبون محفظته. ليس هذا خللا، بل بروتوكول لا يستطيع Kanz التحدث به من حيث يعمل.

- المصدر: https://usekanz.com/ar/blog/tahdith-apple-wallet
- اللغة: ar
- لغات أخرى: [fr](https://usekanz.com/blog/apple-wallet-mise-a-jour), [en](https://usekanz.com/en/blog/apple-wallet-pass-updates)
- الصيغة: Markdown، مُولَّد من المصدر نفسه الذي تُولَّد منه الصفحة.

- نُشر في: 2026-08-04
- الكاتب: Kanz
- المواضيع: المحفظة, تقني, المنتج
- مدة القراءة: 3 دقيقة

تضيف ختما. على هاتف Android يكون عداد البطاقة قد تغير. وعلى iPhone سيتغير حين يفتح الزبون
محفظته، لا في الثانية التي تمسح فيها الرمز.

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

ويشرح هذا المقال السبب، لأن السبب نفسه جدير بالاهتمام، ولأن منتجا يوهم بالفورية ينتهي به
الأمر إلى أن يؤاخذ على كذبة بدل أن يؤاخذ على حد من حدوده.

## المحفظتان لا تتحدثان بالطريقة نفسها

في جهة Google، تحديث بطاقة نداء ويب عادي. يستدعي Kanz، فيتغير الكائن، وينتهي الأمر.

في جهة Apple، البطاقة الموجودة على الهاتف لا تذهب من تلقاء نفسها لتجلب حالتها الجديدة.
المفروض أن يرسل الخادم إشعارا صامتا صغيرا يقول لـiPhone: «بطاقتك تغيرت، تعال فاجلبها». وهو
ليس إشعارا مرئيا: إنه إيقاظ بمحتوى فارغ، ثم يأتي الهاتف بعده ليأخذ النسخة الجديدة.

ويمر هذا الإيقاظ عبر خدمة الإشعارات لدى Apple، وهي لا تتحدث **إلا** بروتوكول HTTP/2 وترفض
HTTP/1.1.

## حيث يعمل Kanz، هذا البروتوكول غير متاح

يعمل Kanz على بيئة تنفيذ في حافة الشبكة، وهي البيئة التي تجعل المسح سريعا في كل مكان. وهذه
البيئة لا تعرف كيف تفتح اتصال HTTP/2 نحو خادم اعتباطي. جربت ثلاث طرق للقيام بذلك، وهذا ما
ترد به كل واحدة منها:

```text
http2.connect(...)                       → method not implemented
tls.connect({ ALPNProtocols: ['h2'] })   → option not implemented
fetch('https://api.push.apple.com/…')    → network connection lost
```

ونداء تحقق نحو موقع أيا كان، من العزلة نفسها، يرد 200. فالأمر إذن ليس حجبا شبكيا ولا مسألة
جدار حماية: إنه البروتوكول فعلا.

وهذا يستبعد كذلك رد الفعل المعتاد في صورتيه. إعادة كتابة الوحدة بـ`fetch` لا تنفع، وقد كانت
هي الفرضية الأولى وقد قتلها القياس. ونقل الشفرة إلى الخدمة الأخرى لا ينفع بدوره، لأنها البيئة
نفسها من حيث النوع.

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

الفورية وحدها، وعلى iPhone وحده.

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

أما ما يضيع فهو تلك المتعة الصغيرة، متعة رؤية العداد يتحرك أمام عيني الزبون وهو ممسك بهاتفه.
وهي متعة حقيقية وليست بلا قيمة، لكنها لا تمس العد ولا المكافأة ولا الموثوقية.

## ما يلزم لإعادتها

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

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

## ثلاثة تفاصيل تجعل هذا يفشل بصمت

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

موضوع الإشعار يجب أن يكون **معرف نوع البطاقة**، لا معرف تطبيق. والمحتوى يجب أن يكون كائنا
فارغا: فهو إيقاظ، لا إشعار. والإشعار من نوع الخلفية يقتضي الأولوية المنخفضة، أما مع الأولوية
المرتفعة فيقبل ثم يهمل.

## لماذا كتب هذا هنا

لأن مستخدما يلاحظ الفارق الزمني يستحق أفضل من «يفترض أن تتحدث وحدها». ولأن منتجا يوثق حدوده
حيث يمكن قراءتها أسهل تصديقا حين يؤكد ما تبقى.

وعمل البطاقة عموما، من أول مسح إلى المكافأة، [موصوف هنا](/ar/blog/bitaqat-wala-wallet).

## إنشاء حساب

تدوم الفترة التجريبية 30 يومًا ولا تطلب أي بطاقة بنكية.

- [إنشاء حساب](https://usekanz.com/signup)
- [لوحة صاحب المتجر](https://usekanz.com/panel)