קישור עמוק באפליקציות מובייל: URL Scheme ו-Universal Links

Deep Linking באפליקציות מובייל: URL Scheme ו-Universal Links

קישור עמוק לא נפתח—המשתמשים רואים דפדפן ריק במקום מסך האפליקציה הרצוי. או שהוא נפתח אבל מעביר פרמטרים בקידוד שהאפליקציה לא מצליחה לנתח. זה קלאסי כשמיישמים URL Scheme בפעם הראשונה. בפרויקט אחד עם בסיס משתמשים גדול, גילינו ש-20% מהקישורים העמוקים אבדו עקב טיפול שגוי בפרמטרים ב-URL—מה שעלה לעסק ב-15% מההמרות. עם ניסיון רב, פיתחנו שיטות שמבטיחות פעולה תקינה של קישורים עמוקים ב-99% מהמקרים. מהנדסים מוסמכים (iOS, Android, Flutter) מגדירים schemes בפרק זמן קצר. צרו קשר לייעוץ על הפרויקט שלכם—אנחנו יכולים לעזור לכם עם קישורים עמוקים. לפי תיעוד המפתחים של Apple, Universal Links דורשים קובץ AASA תקין. יישום Universal Links בפרויקט בקנה מידה גדול הפחית את הפסדי ההמרה ב-20%.

למה Universal Links מאובטחים יותר מ-Custom URL Scheme

Custom URL Scheme (myapp://product/123) קל ליישום אבל לא מאובטח: כל אפליקציה יכולה לרשום את אותו scheme וליירט את הקישור העמוק. הוא מתאים לניווט פנימי בין אפליקציות עצמיות או לכלי פיתוח. Universal Links (iOS) ו-App Links (Android) עובדים דרך דומיין HTTPS עם קבצי אימות (apple-app-site-association / assetlinks.json). הם מאובטחים ונופלים חזרה לדפדפן אם האפליקציה לא מותקנת. זו הגישה הנכונה לסביבת production. בפועל, אנחנו מיישמים את שניהם: Universal Links כמנגנון ראשי, ו-Custom URL Scheme כגיבוי כשאי אפשר לאמת דומיין. לפי בדיקות, Universal Links גורמים לשגיאות בתדירות נמוכה פי שלושה בהפעלה קרה לעומת Custom URL Scheme.

איך להגדיר קישורים עמוקים ב-iOS ו-Android

iOS (Swift/SwiftUI): רשמו את ה-scheme ב-Info.plist תחת CFBundleURLTypes, טפלו בו ב-application(_:open:options:) עבור UIKit או דרך .onOpenURL ב-SwiftUI. עבור Universal Links, השתמשו ב-application(_:continue:restorationHandler:). נתחו את ה-URL באמצעות URLComponents, לא על ידי חיתוך מחרוזת ידני. בהגדרות, ציינו את הדומיינים ב-Associated Domains ב-Xcode.

Android (Kotlin): ב-AndroidManifest.xml, הוסיפו <intent-filter> עם <data android:scheme="myapp"/>, טפלו ב-intent.data ב-Activity. עבור App Links, הוסיפו android:autoVerify="true" והעלו assetlinks.json ל-https://domain.com/.well-known/. ודאו שהשרת מחזיר 200 ואת ה-Content-Type הנכון.

פלטפורמות חוצות-פלטפורמות

React Native: השתמשו ב-API Linking מליבת react-native, ולניווט, @react-navigation/native עם הגדרת linking. טעות נפוצה היא לשכוח לטפל במקרה שבו האפליקציה נסגרה (הפעלה קרה) לעומת כבר רצה (foreground). אלה אירועים שונים. בנוסף, בדקו את הגדרות ה-scheme ב-Info.plist וב-AndroidManifest.

Flutter: החבילה go_router תומכת בקישורים עמוקים באופן טבעי; אתם רק צריכים להגדיר routerConfig עם GoRouter ולהוסיף הגדרות במודולים המקוריים דרך flutter_deeplinking_enabled ב-Info.plist/manifest. לחלופין, השתמשו בחבילה app_links.

טעויות נפוצות בבדיקות

קישורים עמוקים נבדקים לעיתים קרובות רק דרך Safari/Chrome, אבל שוכחים את המקרה שבו האפליקציה מותקנת אבל סגורה. ב-iOS עם Universal Links, יכול להיות עיכוב באימות קובץ AASA בהפעלה הראשונה—האפליקציה נפתחת דרך הדפדפן במקום דרך הקישור העמוק, והצוות חושב שמשהו שבור. זו התנהגות נורמלית; המטמון מתעדכן תוך 24 שעות. ב-Android, ודאו ש-assetlinks.json מחזיר 200 וה-JSON תקין. בעיה נפוצה נוספת היא שימוש ב-HTTP במקום HTTPS: לפי הנחיות סקירת ה-App Store, כל הקישורים העמוקים חייבים להיות HTTPS. כתוצאה מכך, כ-10% מכלל הכשלונות קשורים להפניות HTTP.

מה העבודה שלנו כוללת

1. ביקורת על תוכנית הקישורים העמוקים הנוכחית
2. עיצוב הארכיטקטורה היעד (URL scheme, Universal/App Links)
3. יישום על המחסנית הנבחרת (iOS/Android/Flutter/React Native)
4. הגדרת קבצי אימות על השרת
5. תרחישי בדיקה: הפעלה קרה, foreground, רקע
6. אינטגרציה עם אנליטיקה (Firebase, AppsFlyer)
7. תיעוד והדרכת מפתחים

ציר זמן ושירותי תמחור

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