פיתוח מקצועי של הרחבת מקלדת ל-iOS לפרסום ב-App Store

אנו מפתחים הרחבות מקלדת מותאמות אישית ל-iOS—ממקלדות אמוג'י פשוטות ועד כאלה עם תכונות מלאות הכוללות תיקון אוטומטי ותמיכה רב-לשונית. הרחבת מקלדת מותאמת אישית היא סוג ההרחבה היחיד שעובד בכל האפליקציות בו-זמנית, אך דווקא בגלל זה היא הקשה ביותר לשחרור: אפל דורשת עמידה קפדנית בכללי אבטחה, אחרת דחייה. בעיות נפוצות בהרחבות מקלדת ל-iOS כוללות תצורה שגויה של App Group וטיפול לא נכון ב-RequestsOpenAccess. עם ניסיון של למעלה מ-10 שנים ויותר מ-10 פרויקטים מוצלחים, אנו מבטיחים אישור ראשון של סקירת App Store (אחוז הצלחה של 95%).

מדוע הרחבת מקלדת מותאמת אישית היא סוג ההרחבה התובעני ביותר?

מבחינה ארכיטקטונית, המקלדת חיה בתהליך מבודד באמצעות UIInputViewController. אין לה גישה ישירה ל-UserDefaults של האפליקציה הראשית ללא App Groups, הרשת עובדת רק כאשר הדגל RequestsOpenAccess מופעל, ושדות מערכת (כמו שדות סיסמה) חוסמים את הקשר הקלט.

מה קורה אם לא מגדירים App Group?

הטעות האופיינית הראשונה: המפתח מגדיר App Group כדי להעביר הגדרות מהאפליקציה הראשית להרחבה אך שוכח להוסיף את הקבוצה ל-Capabilities של יעד ההרחבה עצמו—לא רק לאפליקציה הראשית. Xcode אינו מזהיר. הקריסה מתרחשת במכשיר כ-nil בעת קריאת UserDefaults(suiteName:). אנו מגדירים App Group בשני היעדים מיד ובודקים זמינות של ה-suite בקוד.

כיצד להגדיר כראוי את RequestsOpenAccess?

אפל דורשת שאם הדגל RequestsOpenAccess הוא YES, המקלדת חייבת לתאר במפורש במדיניות פרטיות כיצד נעשה שימוש בנתוני הקלט. אם התיאור מעורפל או חסר—דחייה לפי הנחיה 5.1.1 (איסוף ואחסון נתונים). בינתיים, אם הדגל הוא NO, בקשות רשת מההרחבה ייכשלו בשקט ללא שגיאות ביומנים. אנו תמיד מתעדים את המדיניות ובודקים עקביות בין הדגל לפונקציונליות.

מפתחות למעקב ב-Info.plist של ההרחבה

<key>NSExtension</key>
<dict>
  <key>NSExtensionAttributes</key>
  <dict>
    <key>IsASCIICapable</key>
    <false/>
    <key>PrefersRightToLeft</key>
    <false/>
    <key>PrimaryLanguage</key>
    <string>en-US</string>
    <key>RequestsOpenAccess</key>
    <true/>
  </dict>
  <key>NSExtensionPointIdentifier</key>
  <string>com.apple.keyboard-service</string>
  <key>NSExtensionPrincipalClass</key>
  <string>$(PRODUCT_MODULE_NAME).KeyboardViewController</string>
</dict>

אם הדגל <key>NSExtension</key> <dict> <key>NSExtensionAttributes</key> <dict> <key>IsASCIICapable</key> <false/> <key>PrefersRightToLeft</key> <false/> <key>PrimaryLanguage</key> <string>en-US</string> <key>RequestsOpenAccess</key> <true/> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.keyboard-service</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).KeyboardViewController</string> </dict> מוגדר ל-YES, אתה מקבל גישה מלאה להקשר הקלט ויכולת לבצע בקשות רשת. בלעדיו, לא ניתן ליישם בדיקת איות דרך שירותים חיצוניים או לטעון אמוג'ים משרת. אבל אפל דורשת מסמך מדיניות עיבוד נתונים מפורש, אחרת דחייה. אם הדגל הוא NO, המקלדת מאובטחת יותר (ללא רשת), אך הפונקציונליות מוגבלת. אנו עוזרים לבחור את התצורה האופטימלית לצרכי המוצר שלך.

כיצד פועלת מקלדת מותאמת אישית תקינה

UIInputViewController מספק textDocumentProxy—האובייקט שדרכו המקלדת מתקשרת עם שדה הטקסט של האפליקציה המארחת. הכנסת טקסט: textDocumentProxy.insertText("a"). מחיקת תו: textDocumentProxy.deleteBackward(). החלפת שפה: advanceToNextInputMode(). סגירת מקלדת: dismissKeyboard().

קריטי: textDocumentProxy.documentContextBeforeInput ו-documentContextAfterInput מחזירים טקסט סביב הסמן—אך לא תמיד. בחלק מהשדות (שדות טקסט מוגנים, שדות עם isSecureTextEntry), ה-proxy מחזיר nil. יש לטפל בזה במפורש, אחרת כל לוגיקת תיקון אוטומטי או חיזוי מילים תישבר בשדות סיסמה.

בעיית גובה המקלדת

מקלדת המערכת מתאימה את עצמה אוטומטית ל-Safe Area. המקלדת המותאמת אישית לא. יש להגדיר גובה באמצעות אילוץ גובה על inputView, ולחשב מחדש בעת שינוי כיוון:

override func viewWillLayoutSubviews() {
    super.viewWillLayoutSubviews()
    let newHeight: CGFloat = view.bounds.width > view.bounds.height ? 180 : 256
    if heightConstraint?.constant != newHeight {
        heightConstraint?.constant = newHeight
        view.layoutIfNeeded()
    }
}

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

שמירת מצב בין הפעלות

להרחבה אין מצב מתמשך בזיכרון—התהליך מסתיים עם הקלט. יש לאחסן הגדרות (פריסה, ערכת נושא, תיקון אוטומטי) ב-UserDefaults דרך App Group. נתונים גדולים יותר (מילון נלמד, היסטוריית אמוג'ים) נשמרים במיכל CoreData משותף או בקובץ במיכל משותף באמצעות override func viewWillLayoutSubviews() { super.viewWillLayoutSubviews() let newHeight: CGFloat = view.bounds.width > view.bounds.height ? 180 : 256 if heightConstraint?.constant != newHeight { heightConstraint?.constant = newHeight view.layoutIfNeeded() } } .

השוואת גישות לאחסון מילון (CoreData מהיר פי 3 עבור מילונים גדולים):

מה כלול בפיתוח מקלדת מותאמת אישית?

• ביקורת דרישות מלאה וניסוח מדיניות פרטיות בהתאם לכללי אפל.
• יישום ההרחבה מאפס או שינוי קיים (Swift, SwiftUI/UIKit).
• הגדרת App Group, מיכל משותף, CoreData (אם נדרש מילון).
• התאמה ל-iPad ולכיוונים שונים.
• בדיקות על מכשירים אמיתיים דרך TestFlight, כולל בדיקות ב-UISearchBar, UITextView עם FileManager.containerURL(forSecurityApplicationGroupIdentifier:), שדות סרגל הכתובות של Safari.
• סיוע בסקירת App Store (בדיקה מול הנחיות 4.2 ו-5.1).
• תיעוד והמלצות לתמיכה שוטפת.

לוחות זמנים ועלות

לוח הזמנים לפיתוח נע בין 2 ל-4 שבועות בהתאם לתכונות (תיקון אוטומטי, תמיכה רב-לשונית, מילון נלמד). העלות נעה בין $5,000 ל-$15,000 בהתאם למורכבות. התהליך היעיל שלנו יכול להפחית את ההשקעה הכוללת שלך בעד 40% בהשוואה למפתחים פחות מנוסים. צור קשר להערכת פרויקט חינמית—נבחן את הדרישות שלך ונספק הצעת מחיר מפורטת.

כיצד להימנע מדחיית App Store?

אנו משיגים אישור ראשון ב-95% מהמקרים. לשם כך:

1. בדיקת עקביות בין הפונקציונליות המוצהרת ליישום.
2. הכנת מדיניות פרטיות מפורטת אם הדגל isEditable = false פעיל.
3. בדיקת התנהגות בשדות מאובטחים ואחרי מעבר פריסה.
4. הבטחה שהמקלדת לא אוספת נתונים ללא הסכמה מפורשת.

צור קשר—ונבצע ביקורת חינמית של מוכנות הפרויקט שלך לפרסום. מידע נוסף: UIInputViewController — תיעוד רשמי של אפל.