פיתוח SDK ליישומים ניידים

SDK שלא מעצבן

השקעתם חודש בפיתוח API מצוין, אבל השילוב של ה-SDK שלכם באפליקציה ניידת נדחה שוב ושוב. מפתחים מתלוננים על קובץ בינארי של 50 מגה-בייט, חוסר בתיעוד, וקריסות בלתי צפויות לאחר עדכונים. כל כישלון כזה משמעותו אובדן לקוחות ומוניטין. במשך 5 שנים שחררנו 20+ SDKים ל-iOS, אנדרואיד ו-Kotlin Multiplatform — ואנחנו יודעים איך להפוך את השילוב למהיר וללא כאבים.

אילו בעיות אנחנו פותרים?

API ציבורי לא נוח

שטח ה-API חייב להיות מינימלי. כל השאר צריך להיות internal/private. עקרון החשיפה המינימלית אינו אופציונלי. כל מתודה שאתם חושפים היא התחייבות לשנים. אם אתם תוהים אם לפרסם אותה — אל תפרסמו.

תאימות לאחור

תאימות לאחור היא החוזה המרכזי עם הלקוחות. אנו משתמשים בניהול גרסאות סמנטי (ויקיפדיה): גרסה ראשית רק עבור שינויים שוברי תאימות. הוספת מתודות חדשות לממשק היא שינוי שובר תאימות עבור המיישמים, ולכן במקום להרחיב ממשק אנו מוסיפים ממשק חדש או משתמשים במימושים ברירת מחדל (הרחבות פרוטוקול ב-Swift, ברירות מחדל בממשקי Kotlin). אנו מסמנים API לא יציב: @Experimental ב-Kotlin, @available(*, deprecated) ב-Swift.

גודל בינארי

אף אחד לא רוצה להוסיף SDK ולקבל +5 MB לאפליקציה שלו. בקרה קפדנית על תלויות: מזעור תלויות טרנזיטיביות. אם ה-SDK צריך שכבת רשת — אנחנו לא מושכים OkHttp או Alamofire, אנחנו כותבים באמצעות ספריות סטנדרטיות (transitive dependencies, HttpURLConnection). חריג: אם ה-SDK מיועד למערכת אקולוגית ספציפית (למשל, Firebase SDK — קורוטינים של Kotlin צפויים שם).

איך אנחנו עושים את זה?

Kotlin SDK

אנו מפרסמים דרך Maven Central או GitHub Packages. URLSession עם build.gradle.kts, חתימה דרך GPG (תוסף MavenPublication), signing חובה עבור Maven Central. קואורדינטות Artifact: javadoc.jar. עבור SDK חוצה פלטפורמות — KMP עם פרסום של com.example:sdk-name:1.0.0, *-android, *-ios-arm64 artifacts.

Swift/iOS SDK

הפצה דרך Swift Package Manager (מועדף) או Cocoapods. SPM: *-ios-simulator-arm64 עם Package.swift מפורש, ייצוא דרך .supportedPlatforms אם יש קוד C/Objective-C מקורי. Cocoapods: XCFramework עם .podspec או spec.vendored_frameworks. מסגרת בינארית — דרך spec.source_files ב-SPM או binaryTarget ב-podspec.

למה בטיחות תהליכים (Thread Safety) היא חובה עבור SDK?

ה-SDK נקרא מהקוד של מישהו אחר — לא ניתן להבטיח את סדר הקריאות. כל ה-API הציבורי חייב להיות בטוח לתהליכים או מתועד במפורש כ"קריאה רק מה-main thread". ב-Kotlin — spec.vendored_frameworks/@WorkerThread annotations + כללי Lint. ב-Swift — @MainThread עבור רכיבי UI של ה-SDK, @MainActor עבור מצב משתנה.

מודעות למחזור חיים

SDK אנדרואיד שמחזיק Activity context הוא דליפת זיכרון. אנו משתמשים ב-actor או WeakReference<Context>. ב-iOS — באופן דומה, הפניות חלשות ל-delegate. אם ה-SDK רושם מאזיני מערכת (ApplicationContext, NotificationCenter) — חובה BroadcastReceiver/deinit מפורש עם תיעוד.

קונפיגורציה ואתחול

תבנית Builder במקום קונסטרוקטור עם 10 פרמטרים. באנדרואיד — close(). אתחול ב-MySDK.Builder(context).apiKey("...").timeout(30).build(), לא ב-Application.onCreate(). אם ה-SDK דורש אתחול אסינכרוני — ספקו callback ו-API תואם קורוטינים (Activity).

טיפול בשגיאות

Sealed classes לתוצאות (suspend fun initialize()), לא חריגים גולמיים. תיעוד כל Result<T, SDKError> אפשרי. ב-Swift — SDKError עם enum SDKError: Error. אין לכלול Crashlytics ומדווחי קריסות של צד שלישי ב-SDK — זו אחריות האפליקציה המשלבת.

איך למזער את גודל ה-SDK?

גודל בינארי הוא אחד מקריטריוני האיכות המרכזיים. אנו מבטיחים שה-SDK לא מנפח את האפליקציה של הלקוח. לשם כך:

• שימוש בתלויות צד שלישי מינימליות.
• ב-iOS, הימנעות מהכללת ארכיטקטורות מיותרות ב-XCFramework, שימוש בבינאריים דקים.
• באנדרואיד, הפעלת ProGuard/R8 כדי להסיר קוד שאינו בשימוש.
• ב-KMP, בחירת expect/actual לקוד ספציפי לפלטפורמה במקום שכפול.

מקרה בוחן: SDK לתשלומים ב-4 חודשים

עבור אפליקציית שותף (הלקוח שלנו הוא סטארטאפ פינטק) פיתחנו SDK לתשלומים ל-iOS ואנדרואיד. API ציבורי: LocalizedError ב-iOS ו-PaymentSDK.present(from: UIViewController, amount: Decimal, completion: @escaping (PaymentResult) -> Void) באנדרואיד. בפנים — UI מקורי (bottom sheet עם שדות כרטיס), הצפנה באמצעות AES-256-GCM, token שנשלח לשרת הלקוח. גודל SDK: 340 KB (xcframework של iOS) ו-280 KB (aar של אנדרואיד). בדיקות — בדיקות יחידה עם שכבת רשת מדומה, פרויקט בדיקות אינטגרציה באותו מאגר. זה צמצם את זמן השילוב עבור הלקוח ב-2–3 שבועות והפחית באגים ב-30%. בהשוואה למתחרים, ה-SDK שלנו ב-Kotlin Multiplatform היה מהיר יותר ב-40% לפיתוח וקטן יותר ב-25% בגודל.

מה כלול בפיתוח SDK?

אנו מספקים חבילה מלאה כדי להקל על הלקוחות שלכם לשלב את ה-SDK:

• תיעוד — API Reference (Dokka ל-Kotlin, DocC ל-Swift), README עם quickstart, changelog בפורמט Keep a Changelog.
• אפליקציית בדיקה — מאגר עם דוגמאות אינטגרציה המכסות תרחישים עיקריים.
• כללי Lint ו-annotations מותאמים אישית — לאנדרואיד דרך PaymentSDK.launch(activity, amount, callback), אזהרה על שגיאות בזמן קומפילציה.
• תמיכה באינטגרציה — ייעוץ בנושאי תאימות ואופטימיזציה.

val sdk = MySDK.Builder(applicationContext) .apiKey("") .timeout(30) .build() sdk.initialize() 

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

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