הטמעת עדכוני Push עבור כרטיסי Wallet באפליקציות מובייל

באפליקציה ניידת לתוכניות נאמנות, נוצר מצב נפוץ: נקודות נזקפות, אך הלקוח רואה את היתרה הישנה עד שהוא פותח את הכרטיס ידנית. עדכוני Push עבור Wallet Pass פותרים זאת—הנתונים במכשיר מתעדכנים תוך שניות ללא מעורבות המשתמש. הגדרנו מנגנון זה עבור למעלה מ-5000 כרטיסי Pass, וזמן המעבר משינוי בשרת לעדכון במכשיר אינו עולה על 2 שניות. הטמעת עדכוני push מפחיתה את זמן עדכון הנתונים במכשירים ב-90%, ומגבירה את נאמנות המשתמשים. אם ברצונך להטמיע עדכוני push, קבל ייעוץ.

כיצד פועל מנגנון עדכון ה-Push עבור Wallet Pass

מבחינה ארכיטקטונית, התוכנית נראית כך: השרת שלך רושם את המכשיר דרך PassKit Web Service API, מאחסן את הצמד deviceLibraryIdentifier + pushToken, וכאשר הנתונים משתנים, שולח push דרך APNs לאסימון זה. iOS "מתעורר", מבצע בקשת GET לשרת עבור קובץ ה-.pkpass המעודכן, והכרטיס מתעדכן ללא מעורבות המשתמש.

ההטמעה מחולקת לשני חלקים—שרת ולקוח—כשהחלק של הלקוח כמעט אפסי: PassKit מטפל בכל מחזור הרישום אם השרת מיישם את הפרוטוקול כראוי.

פרוטוקול PassKit Web Service בצד השרת

השרת חייב ליישם ארבעה נקודות קצה:

• POST /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber} — רישום מכשיר
• DELETE /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}/{serialNumber} — ביטול רישום
• GET /v1/devices/{deviceLibraryIdentifier}/registrations/{passTypeIdentifier}?passesUpdatedSince={tag} — רשימת ה-Pass המעודכנים
• GET /v1/passes/{passTypeIdentifier}/{serialNumber} — הורדת ה-.pkpass העדכני ביותר

הטעות הנפוצה ביותר היא קוד מצב HTTP שגוי. Apple PassKit רגיש ביותר: 200 עם גוף ריק על DELETE שובר את ביטול הרישום. יש צורך ב-204 No Content. ב-GET עבור רשימת עדכונים ללא שינויים, יש להחזיר בדיוק 204, לא 200.

// Пример структуры ответа на GET /registrations
{
  "serialNumbers": ["ABC123", "DEF456"],
  "lastUpdated": "1711234567"
}

שדה ה-// Пример структуры ответа на GET /registrations { "serialNumbers": ["ABC123", "DEF456"], "lastUpdated": "1711234567" } הוא חותמת זמן UNIX כמחרוזת. iOS מחזיר אותה ב-lastUpdated בבקשה הבאה. אם תחזיר את חותמת הזמן בפורמט שגוי, המכשיר יבקש כל הזמן את כל ה-Pass, תוך התעלמות מהלוגיקה המצטברת.

APNs Push לעדכונים

ה-push עבור Wallet אינו סטנדרטי. ה-payload מינימלי:

{ "aps": {} } 

בדיוק—passesUpdatedSince ריק. אין { "aps": {} } , aps, alert. iOS, עם קבלת push כזה, פונה בשקט לשרת לעדכונים. יש לשלוח דרך APNs עם badge השווה ל-passTypeIdentifier של האפליקציה (פורמט: sound), לא ל-apns-topic.

האישור עבור PassKit הוא נפרד—זהו Pass Type ID Certificate מפורטל המפתחים של Apple, לא אישור APNs רגיל עבור האפליקציה. לעתים קרובות מבלבלים ביניהם, מה שגורם לכך ש-APNs מקבל את הבקשה אך ה-push לא נמסר.

# Пример отправки через httpx (Python, APNs HTTP/2)
headers = {
    "apns-topic": "pass.com.example.loyalty",
    "apns-push-type": "background",
    "apns-priority": "5",
    "authorization": f"bearer {jwt_token}"
}
payload = json.dumps({"aps": {}})
response = await client.post(
    f"https://api.push.apple.com/3/device/{push_token}",
    content=payload,
    headers=headers
)

pass.com.yourcompany.appname הוא חובה עבור push ברקע. עדיפות bundleIdentifier אינה פועלת כמצופה עבור Wallet.

curl -v \
  --header "apns-topic: pass.com.example.loyalty" \
  --header "apns-push-type: background" \
  --header "apns-priority: 5" \
  --header "authorization: bearer $(jwt_token)" \
  --data '{"aps":{}}' \
  https://api.push.apple.com/3/device/$(push_token)

חתימה על .pkpass

כל # Пример отправки через httpx (Python, APNs HTTP/2) headers = { "apns-topic": "pass.com.example.loyalty", "apns-push-type": "background", "apns-priority": "5", "authorization": f"bearer {jwt_token}" } payload = json.dumps({"aps": {}}) response = await client.post( f"https://api.push.apple.com/3/device/{push_token}", content=payload, headers=headers ) הוא ארכיון ZIP עם קובץ apns-priority: 5 (גיבובי SHA-1 של כל הקבצים) וקובץ 10 (חתימה מנותקת PKCS#7). בעת עדכון Pass, יש לחשב מחדש את ה-manifest וליצור מחדש את החתימה. שימוש בחתימה ישנה עם נתונים חדשים גורם ל-iOS להתעלם בשקט מהקובץ.

יצירת החתימה דרך curl -v --header "apns-topic: pass.com.example.loyalty" --header "apns-push-type: background" --header "apns-priority: 5" --header "authorization: bearer $(jwt_token)" --data '{"aps":{}}' https://api.push.apple.com/3/device/$(push_token) :

openssl smime -binary -sign \
  -certfile AppleWWDRCA.pem \
  -signer passcertificate.pem \
  -inkey passkey.pem \
  -in manifest.json \
  -out signature \
  -outform DER

הספרייה .pkpass של Apple שימושית לבדיקות, אך בייצור עדיף ליישם חתימה באופן מקורי על השרת—ללא קבצי בינאריים חיצוניים.

טעויות אופייניות במהלך ההטמעה

מניסיוננו בהטמעת עדכוני push עבור Wallet Pass בפרויקטים בקנה מידה שונה, אנו מדגישים שלוש בעיות נפוצות ביותר:

כל אחת מהטעויות הללו מובילה לכך שעדכונים לא נמסרים, למרות שהכל נראה תקין בשרת. פיתחנו רשימת בדיקה המאפשרת לאבחן את הבעיה תוך 30 דקות.

תהליך העבודה שלנו

1. ניתוח תשתית: בדיקת השרת הנוכחי, ה-backend ויכולות אחסון אסימוני push.
2. עיצוב: הגדרת הארכיטקטורה של PassKit Web Service, בחירת מחסנית ליצירת קבצי Pass.
3. הגדרת אישורים: יצירת Pass Type ID, הפקת אישור בפורטל המפתחים של Apple.
4. הטמעת נקודות קצה: הגדרת ארבעת נקודות הקצה לפי מפרט PassKit Web Service.
5. יצירת Pass וחתימה: הטמעת יצירה אוטומטית של .pkpass בעת שינוי נתונים.
6. שילוב APNs: הגדרת שליחת push עם כל שינוי.
7. בדיקות: שימוש ב-Charles Proxy ליירט בקשות, בדיקת המחזור המלא.
8. ניטור: הגדרת רישום והתראות לכשלים בשליחת push.

מה כלול בהטמעה

כתוצאה מכך, אתה מקבל:

• צד שרת: PassKit Web Service API מלא עם אחסון אסימונים ותמיכה בעדכונים מצטברים.
• שילוב לקוח: שינויים מינימליים באפליקציה (רישום בעת הוספת Pass).
• תיעוד: תיאור כל נקודות הקצה, פורמטי הנתונים ונוהל העדכון.
• קבצי Pass לבדיקה: דוגמאות מוכנות לניפוי באגים.
• תמיכה במהלך ההטמעה: ייעוץ לגבי שינויים בצד הלקוח.

למה לסמוך עלינו

• 10+ שנות ניסיון בפיתוח נייד ושילובי שרת.
• 5000+ Wallet Passes מיושמים עבור תוכניות נאמנות ומערכות כרטוס שונות.
• עמידה בכל הדרישות של מפרט Apple PassKit Web Service והנחיות בדיקת ה-App Store.
• זמינות של 99.9% בפתרונות השרת שלנו עבור לקוחות.

קבל ייעוץ לפרויקט שלך—נעריך לוחות זמנים ועלויות.