יישום מנויי iOS: StoreKit 2, תקופת חסד והצעות קידום מכירות

מנויים עם חידוש אוטומטי הם הסוג המורכב ביותר של רכישה בתוך האפליקציה. לא בגלל ש-StoreKit מסובך כשלעצמו, אלא בגלל כל המערכת האקולוגית שמסביבו: תקופות חסד, ניסיונות חיוב חוזרים, מעבר בין רמות (דאונגרייד/אפgrade), הצעות קידום מכירות, תמחור היכרות, ולבסוף — טיפול בנשירה באמצעות expirationIntent. שגיאה בכל שלב מובילה לאובדן הכנסות. אנו מיישמים מנויים במפתח מלא תוך 3–5 ימים, ומבטיחים לוגיקה נכונה בכל שלב במחזור החיים.

מחזור החיים של המנוי והיכן הוא נשבר

מנוי iOS אינו רק פעיל או לא. אפל מחדשת אותו אוטומטית 24 שעות לפני הפקיעה. אם התשלום נכשל, מתחילה תקופת ניסיונות חיוב חוזרים (עד 60 ימים). במהלך תקופה זו, סטטוס המנוי הוא expired, אבל אפל ממשיכה לנסות. רוב האפליקציות חוסמות גישה מיד לאחר expirationDate — זה לא נכון.

הלוגיקה הנכונה: בדוק את renewalInfo.isInBillingRetryPeriod. אם true, הענק תקופת חסד (מוגדרת ב-App Store Connect, בדרך כלל 6 ימים לשנתי, 3 ימים לחודשי). משתמש עם בעיית כרטיס לא צריך לאבד גישה מיד.

StoreKit 2 מטפל בתקופת החסד באופן שקוף, ומפחית נשירה ב-20–30% בהשוואה ליישום ידני עם StoreKit 1. הנה דוגמה לאימות נכון:

for await result in Transaction.currentEntitlements {
    guard case .verified(let transaction) = result else { continue }
    if transaction.productType == .autoRenewable {
        let renewalInfo = try? await transaction.subscriptionStatus.first?.renewalInfo
        let isInGracePeriod = renewalInfo?.gracePeriodExpirationDate != nil
        let isRetrying = renewalInfo?.isInBillingRetryPeriod == true
        if transaction.revocationDate == nil && (transaction.expirationDate ?? .distantPast > .now || isInGracePeriod || isRetrying) {
            unlockPremium()
        }
    }
}

למה תקופת החסד חשובה

ללא תקופת חסד, משתמשים עם בעיות תשלום מאבדים גישה באופן מיידי. אפל מאפשרת עד 16 ימי חסד — מספיק זמן כדי שהלקוח יעדכן את הכרטיס שלו וכדי שתשמרו אותו. הניסיון שלנו מראה ש-70% מהמשתמשים חוזרים לתשלום בתוך תקופת החסד. אם תחסמו גישה מיד, הם יעזבו לצמיתות.

רמות ומעברים ביניהן

אם לאפליקציה שלך יש מספר רמות (Basic, Pro, Enterprise), אתה צריך קבוצת מנויים ב-App Store Connect. כל הרמות שייכות לקבוצה אחת; משתמש יכול להיות עם מנוי פעיל אחד בלבד בקבוצה בכל זמן.

אפgrade (לרמה גבוהה יותר) נכנס לתוקף מיד; אפל מחשבת מחדש את היתרה שנותרה. דאונגרייד (לרמה נמוכה יותר) נכנס לתוקף בתקופת החיוב הבאה. מעבר רוחבי (אותו מחיר, רמה שונה) תלוי בהגדרה: מיידי או דחוי.

עקוב אחר מעברים בצד הלקוח באמצעות for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.productType == .autoRenewable { let renewalInfo = try? await transaction.subscriptionStatus.first?.renewalInfo let isInGracePeriod = renewalInfo?.gracePeriodExpirationDate != nil let isRetrying = renewalInfo?.isInBillingRetryPeriod == true if transaction.revocationDate == nil && (transaction.expirationDate ?? .distantPast > .now || isInGracePeriod || isRetrying) { unlockPremium() } } } ו-originalTransactionID. בשרת, שמור היסטוריית עסקאות מלאה וטפל ב-Apple Server Notifications v2 (App Store Server Notifications). סוגי אירועים קריטיים: subscriptionGroupID, DID_RENEW, DID_FAIL_TO_RENEW, EXPIRED, GRACE_PERIOD_EXPIRED.

איך לטפל במעברים בין רמות?

אפgrades מופעלים מיד — אפל מחשבת את העלות באופן יחסי. דאונגריידים נדחים עד למחזור הבא. מעברים רוחביים יכולים להיות מיידיים או דחויים כפי שהוגדר ב-App Store Connect. עדכן את ממשק המשתמש בהתאם, והצג את התאריך שבו השינוי נכנס לתוקף. השתמש ב-REFUND ו-renewalInfo.renewalDate.

הצעות היכרות וקידום מכירות

תמחור היכרות (תקופות ראשונות N במחיר מוזל) מוגדר ב-App Store Connect ומוחל אוטומטית על מנויים חדשים. בעיה: משתמש שביטל ורוצה לחזור לא מקבל שוב את מחיר ההכרות. לשם כך קיימות הצעות קידום מכירות — אתה יכול להעניק אותן על סמך הלוגיקה שלך (קמפיינים להחזרת לקוחות).

החתימה להצעת קידום מכירות נוצרת בשרת עם המפתח הפרטי מ-App Store Connect:

// На клиенте создаём paymentDiscount
let discount = SKPaymentDiscount(
    identifier: "winback_3months",
    keyIdentifier: keyID,
    nonce: nonce, // UUID с сервера
    signature: signature, // подпись с сервера
    timestamp: timestamp
)
payment.paymentDiscount = discount

ללא חתימה שנוצרת בשרת, הצעת הקידום אינה תקפה — אפל מאמתת את החתימה בצד השרת.

מה כלול בעבודה

• ביקורת על יישום הרכישות בתוך האפליקציה הנוכחי וקבוצות המנויים
• עיצוב סכמות רמות וקבוצות (קבוצות מנויים) בהתאמה ללוגיקה העסקית
• שילוב StoreKit 2 עם תמיכה בתקופת חסד, ניסיונות חיוב חוזרים וטיפול בשגיאות
• הגדרת App Store Server Notifications (v2) בקצה האחורי עם עיבוד אירועים קריטיים
• יישום לוגיקת החזרת לקוחות באמצעות הצעות קידום מכירות
• תיעוד קוד ושילוב אנליטיקת נשירה
• הדרכת צוות על Sandbox ובדיקות מנויים
• תמיכה לאחר השקה (חודש אחד בחינם)

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

ביקורת יישום נוכחי → עיצוב מבנה קבוצות מנויים ורמות → שילוב StoreKit 2 עם תקופת חסד וניסיונות חיוב חוזרים → הגדרת App Store Server Notifications בקצה האחורי → יישום לוגיקת החזרת לקוחות והצעות קידום → בדיקות ב-Sandbox עם פקיעה מדומה (Sandbox דוחס זמן: חודש = 5 דקות).

לוח זמנים: 3–5 ימים תלוי במספר הרמות, קיום קצה אחורי ודרישות אנליטיקת נשירה. העלות נקבעת באופן אישי לאחר ניתוח הפרויקט שלך. צור קשר לייעוץ — נעריך את ההיקף ונציע את הפתרון הטוב ביותר. קבל ייעוץ ממפתח iOS מוסמך עם ניסיון של 5+ שנים ביישום מנויים.

אנו מבטיחים: טיפול נכון בניסיונות חיוב חוזרים, תקופת חסד וכל סוגי המעברים, עמידה בהנחיות בדיקת ה-App Store (סעיפים 4.2 ו-5.1), ותמיכה מלאה במהלך הבדיקות וההשקה.