App Intents iOS: מדוע האפליקציה אינה נראית ב-Siri וב-Shortcuts
לרוב הבעיה אינה ב-Siri ולא ב-Shortcuts, אלא בכך שהאפליקציה פשוט אינה מוסרת למערכת את התרחישים שלה. המשתמש פותח את גלריית הפקודות המהירות, מחפש את הפונקציה שלכם — ואינו מוצא אותה; מנסה להפעיל בקול — Siri עונה שאינה מכירה פעולה כזו. התמיכה מקבלת פניות אחידות, אף שהפונקציה עצמה באפליקציה עובדת כשורה.
הסיבה היא ש-App Intents iOS אינו "מופעל מעצמו". כל פעולה צריכה להיות מתוארת כישות נפרדת עם פרמטרים וביטוי-טריגר, להירשם בתיאור האפליקציה ולהיות מקושרת כראוי לקוד שמבצע את הפעולה.
אם הישות הוצהרה אך לא נכנסה לבנייה, אם הביטויים אינם מתורגמים לשפת המכשיר או שהפרמטרים אינם מסומנים כחובה — המערכת מדלגת על התרחיש בשקט. לא שגיאה ולא אזהרה: רק גלריה ריקה והפעלה קולית לא עובדת של האפליקציה.
מלכודת נפרדת היא ביצוע ברקע. Siri מפעילה את הפעולה מחוץ להקשר של מסך פתוח, ולכן קוד שבאפליקציה נשען על מצב הממשק הנוכחי קורס במצב זה או פועל חלקית. התרחיש נראה ב-Shortcuts, אך בעת הקריאה דבר אינו קורה — ושוב פנייה לתמיכה.
אינטגרציית Siri Shortcuts נשברת גם בבניית הפצה: בגרסת הדיבוג הכול נראה, אך לאחר הפרסום התרחישים נעלמים, משום שחלק מההצהרות נותרו בקונפיגורציית הבדיקה. אנו מפרקים כיצד זה נסגר: מתכנון מערך הפעולות והביטויים ועד לבדיקה שכל תרחיש אכן נראה למערכת ומופעל בקול במכשיר אמיתי.
מה נותנת האינטגרציה: השפעות מדידות למוצר
אינטגרציית App Intents הופכת את פונקציות האפליקציה לפעולות הזמינות למערכת: המשתמש מפעיל אותן בקול דרך Siri, מהחיפוש, ממסך הנעילה או מאוטומציות, מבלי לפתוח את האפליקציה עצמה. עבור המוצר זה לא קוסמטיקה, אלא נתיב אחר לתרחישי המפתח — קצר יותר בכמה שלבים וללא ניווט ידני בין מסכים.
ההשפעה המדידה הראשונה — שיעור התרחישים הזמינים בקול. אם באפליקציה יש פעולות חוזרות (הזמנה, סטטוס, הוספת רשומה, הפעלת מעקב), העברתן ל-App Intents סוגרת חלק ניכר מהפניות ללא פתיחת הממשק.
נתיב המשתמש מתקצר מ"פתח → מצא מדור → מלא → אשר" הטיפוסי לביטוי אחד, והזמן עד לתוצאה יורד פי כמה — זה נראה במשפך ובמספר הפעולות שהושלמו לכל משתמש.
ההשפעה השנייה — מדדי מעורבות. פעולות דרך Siri ורמזי המערכת מחזירות למוצר את אלה שלא פתחו את האפליקציה זמן רב: התרחיש מופעל ממקום רגיל, ולא דרך האייקון.
עולה תדירות הפעולות החוזרות והשימור, והעומס על התמיכה יורד — שאלות טיפוסיות ("איך לראות סטטוס", "איפה לבצע") נסגרות בקול ללא פנייה לנציג.
ההשפעה השלישית — צפיות האינטגרציה. App Intents מתוארים באופן הצהרתי: המערכת עצמה מציעה פעולות ברגע הנכון ומתאימה את הניסוחים, והאפליקציה מקבלת חוזה אחיד ל-Siri, לחיפוש ולאוטומציות.
עובדים על הענף העדכני של Apple — התרחישים נשארים תואמים לגרסאות חדשות של המערכת, ולא נשברים בעת עדכון.
דרכי אינטגרציה: App Intents, Shortcuts ותרחישים ידניים
הפעלה קולית של פונקציות האפליקציה מיושמת בשלושה מסלולים, והבחירה ביניהם קובעת עד כמה עמוק התרחיש ישתלב במערכת. App Intents מקוריים רושמים פעולות ישירות במעטפת: המערכת עצמה מציגה אותן בחיפוש, מציעה אותן ברגע המתאים ומעבירה פרמטרים ללא מעורבות המשתמש.
Shortcuts קלאסיים פועלים דרך אפליקציית מתווכת נפרדת — הפעולה זמינה, אך דורשת שהמשתמש ירכיב תחילה תרחיש. הגדרה ידנית אינה מספקת אינטגרציה מערכתית כלל: הפונקציה נקראת רק מתוך האפליקציה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| App Intents | נדרשת הפעלה מ-Siri, מהחיפוש ומאוטומציות ללא הגדרה מצד המשתמש | דורש ענף מערכת עדכני; חלק מהתרחישים אינם זמינים במכשירים ישנים |
| Shortcuts קלאסיים | הפונקציה צריכה לעבוד גם בגרסאות מערכת קודמות | המשתמש מרכיב את התרחיש ידנית; הפרמטרים מועברים באופן מוגבל |
| תרחישים ידניים | פעולות פנימיות שאינן דורשות קריאה קולית | אין גילוי מערכתי; התרחיש אינו בשימוש חוזר בין אפליקציות |
המגבלה המרכזית היא תאימות לאחור. App Intents נחשפים רק בענף המערכת העדכני, ולכן עבור מלאי מכשירים ישנים יש להחזיק שכבה מקבילה על Shortcuts קלאסיים.
אנו מתכננים את שתי השכבות כך שהלוגיקה של הפעולה תתוארה פעם אחת, ורק נקודת הכניסה תהיה שונה — אחרת ההתנהגות מתפצלת בין הגרסאות והתמיכה מתייקרת.
המגבלה השנייה היא גישה לנתונים. קריאה קולית עשויה לפעול כאשר האפליקציה סגורה או המסך נעול, והתרחיש מחויב לעבוד כראוי ללא פתיחת הממשק. אנו מגדירים מראש אילו פעולות בטוחות לביצוע ברקע ואילו דורשות אישור, — זה מסיר סוג של כשלים שבהם הפקודה מופעלת, אך המשתמש אינו רואה את התוצאה.
שלבי הטמעת App Intents באפליקציה קיימת
הטמעת App Intents באפליקציה פעילה אינה "הוספת כמה קיצורי דרך", אלא בנייה מחדש של חלק מהארכיטקטורה להתאמה לתרחישים מערכתיים. להלן הרצף שלפיו אנו מובילים פרויקטים כאלה, כדי שהאינטגרציה לא תשבור מסלולי משתמש קיימים ולא תדרוש כתיבה מחדש לקראת גרסה הבאה.
- סקירת תרחישים ונקודות כניסה. בוחנים אילו פעולות המשתמש באמת מבצע לעיתים קרובות ומה הגיוני להוציא אל Siri ו"קיצורי דרך": יצירת רשומה, סטטוס מהיר, חזרה על הפעולה האחרונה. מסננים החוצה את מה שאין לו משמעות ללא הקשר המסך.
- עיצוב מודל האינטנטים. מגדירים את מערך האינטנטים, הפרמטרים שלהם, סוגי הישויות והקשרים למודל הדומיין של האפליקציה. בשלב זה קובעים אילו נתונים יוצאים אל המערכת ואילו נשארים בפנים — הדבר משפיע על הפרטיות ועל הסקירה.
- הגדרה ורישום. רושמים את האינטנטים בקונפיגורציית האפליקציה, מתארים ביטויי הפעלה, ומקשרים לשירותים ולאחסון הקיימים. כאן גם מטמיעים טיפול בשגיאות ותשובות ברורות כאשר אין נתונים.
- בדיקה על מכשירים. בודקים לא בסימולטור אלא על מכשירים אמיתיים: גרסאות מערכת שונות, מצבי נעילה, היעדר רשת, שלילת הרשאות. בודקים שהקריאה מ-Siri ומ"קיצורי דרך" מניבה תוצאה זהה.
- טיפול בכשלים ובמצבי קצה. מריצים בנפרד תרחישים שבהם המשתמש אינו מאומת, שבהם הרשומה כבר נמחקה, ושבהם האינטנט נקרא שוב. בלי זה האינטגרציה נראית עובדת בהדגמה ומתפרקת בשימוש אמיתי.
- תיעוד ומסירה. מוסרים לצוות הלקוח תרשים אינטנטים, רשימת ביטויים נתמכים, הוראות להוספת פעולות חדשות וצ'ק-ליסט בדיקה לפני שחרור.
כל שלב מסתיים בארטיפקט שניתן לבדוק: מפת תרחישים, מפרט אינטנטים, דוח בדיקות על מכשירים. כך האינטגרציה נשארת ניתנת לניהול ולא הופכת לאוסף של תיקונים נקודתיים.
מה הלקוח מקבל לידיו לאחר האינטגרציה
אינטגרציה של App Intents היא לא רק קוד בפרויקט. כדי שהתרחישים יעבדו באופן צפוי וניתן יהיה לפתח אותם ללא המחבר, אנו מעבירים ללקוח סט מלא של ארטיפקטים.
- תיאור מודל האינטנטים — אילו פעולות של האפליקציה פתוחות ל-Siri ולמערכת, אילו פרמטרים מקבל כל אינטנט, אילו סוגי נתונים הוא מחזיר וכיצד הם קשורים זה לזה.
- קונפיגורציות והרשאות — הרכב ה-capabilities, ה-entitlements והגדרות הפרויקט הנדרשים לעבודת האינטנטים, עם הסבר מה ולשם מה מופעל.
- תרשימי תרחישים — מפות של מסלולי משתמש: כיצד ביטוי הופך לקריאת אינטנט, היכן פועל דיאלוג הבהרה, מה קורה בהיעדר נתונים.
- נהלי תמיכה — סדר הוספת אינטנטים חדשים, כללי ניהול גרסאות של ביטויים ופרמטרים, צ'ק-ליסט בדיקה לפני שחרור.
- תיעוד לצוות — הוראות להרצה מקומית ולדיבוג של תרחישים, תיאור נקודות ההרחבה ושגיאות טיפוסיות עם סיבותיהן.
- סט תרחישי בדיקה — רשימת בדיקות להרצה ידנית ואוטומטית, כולל מקרי קצה והתנהגות ללא רשת.
- מטריצת תאימות — באילו גרסאות מערכת וסוגי מכשירים התרחישים זמינים, והיכן הם מתדרדרים להתנהגות חלופית.
כל ארטיפקט מקושר לקוד אמיתי ומתעדכן יחד איתו — התיעוד אינו מתפצל מהאפליקציה כבר после השחרור הראשון. כך הצוות של הלקוח יכול להוסיף אינטנטים בעצמו, בלי לחזור אלינו על כל שינוי.
תארו את המשימה — נחזור עם הערכה ותוכנית להיקף הארטיפקטים הללו עבור הפרויקט שלכם.
מקרה בוחן: כיצד תרחישי קול שינו את עבודת האפליקציה
הלקוח — שירות משלוחי מצרכים עם אפליקציה ב-iOS — הגיע עם תלונה קונקרטית: שיעור ההזמנות החוזרות ירד, והאנליטיקה הראתה שמשתמשים פותחים את האפליקציה, מגיעים לקטלוג ועוזבים מבלי לבצע הזמנה.
המסלול עד לרכישה חוזרת כלל 6-7 מסכים: למצוא את האפליקציה, להמתין לטעינה, להיזכר מה הוזמן בפעם הקודמת, להרכיב את הסל מחדש. עבור התרחיש "להזמין את אותו הדבר כמו לפני שבוע" זה ארוך מדי, וחלק מהקהל просто דחה את הרכישה.
הטמענו תרחישי קול על בסיס App Intents: המשתמש אומר "לחזור על ההזמנה האחרונה" או "להוסיף חלב לסל", והמערכת מבצעת את הפעולה מבלי לפתוח את האפליקציה.
האינטנטים מתארים פעולות תחומיות — חזרה על הזמנה, הוספת פריט, סטטוס משלוח — והמערכת עצמה מציעה אותן ברגע המתאים: בבוקר, בדרך הביתה, לאחר הרכישה הקודמת. בנפרד הגדרנו העברת פרמטרים, כך שפקודת קול תציב מוצר ספציפי, ולא תפתח מסך ריק.
מה השתנה במדדים
| מדד | לפני | אחרי |
|---|---|---|
| שיעור ההזמנות החוזרות | בסיסי | +18% |
| ביצוע הזמנה דרך תרחיש קול | 0 | 22% מההזמנות |
| מסכים עד לרכישה חוזרת | 6-7 | 1 (קול) |
| חזרה לאפליקציה בחודש | בסיסי | +11% |
הצמיחה נבעה לא מקלט הקול עצמו, אלא מקיצור המסלול: במקום שבו קודם היה צריך להיזכר ולהרכיב את הסל מחדש, כעת די במשפט אחד. התרחישים פועלים גם על מסך נעול, וגם דרך העוזר המערכתי — האפליקציה הפסיקה להיות נקודת כניסה הכרחית.
מדוע זה עבד
המפתח היה לא הממשק, אלא החיבור בין האינטנטים להיסטוריית ההזמנות: המערכת מציעה פעולה כאשר היא מתאימה, ולא כאשר המשתמש עצמו נזכר באפליקציה. הוצאנו את הלוגיקה של הזמנה חוזרת לשכבה נפרדת, כך שיוכלו לעשות בה שימוש חוזר גם תרחישי הקול, גם הווידג'טים, וגם ההתראות.
גישה זו Apple מקדמת דרך App Intents — פעולות האפליקציה הופכות לנגישות למערכת, ולא רק בתוך האפליקציה עצמה.
שלושה חודשים לאחר ההשקה, שיעור ההזמנות שבוצעו מבלי לפתוח את האפליקציה התייצב ברמה של כחמישית — זה לא זינוק חד-פעמי, אלא ערוץ חדש. אם יש לכם תרחיש דומה עם פעולות חוזרות, נבחן אילו אינטנטים יניבו אפקט בדיוק באפליקציה שלכם.
במה App Intents נבדלים מ-Shortcuts הקלאסיים?
Shortcuts הקלאסיים הם תרחישים שנוצרים על ידי המשתמש עצמו באפליקציית «פקודות» (Команды) מרכיבים מוכנים. האפליקציה במבנה הזה רק חושפת החוצה סט פעולות דרך הרחבה, ואת ההיגיון של חיבור השלבים, התנאים וסדר הקריאות קובע המשתמש.
מכאן גם המגבלות: התרחיש חי במכשיר של אדם מסוים, אינו מועבר בין משתמשים באופן אוטומטי ואינו יודע את ההקשר של המערכת — מה פתוח על המסך, איזו שפה, איזו שעה ביום.
App Intents משנים את תפקיד האפליקציה: היא עצמה מצהירה למערכת מה היא יודעת לעשות, והמערכת מחליטה מתי מתאים להציע זאת. האינטנט מתאר לא «כפתור», אלא כוונה עם פרמטרים וטיפוסים — המערכת מבינה ש«להוסיף משימה» דורש טקסט, ו«להציג מסלול» — כתובת.
לאחר מכן התרחיש יכול להיבנות לא רק באופן ידני: המערכת מכניסה פעולות לחיפוש, לרמזים על מסך הנעילה, לקריאה קולית ולאוטומציות. ההבדל הוא בדיוק במי ששולט בהיגיון — המשתמש או הפלטפורמה.
בגמישות התרחישים גם כן יש יתרון מבני. אינטנט אחד עם פרמטרים מחליף עשרה פעולות מקודדות קשיח: המשתמש משלב אותן ביניהן ועם פעולות של אפליקציות אחרות, והמערכת עצמה פותרת תלויות לפי טיפוסי נתונים.
Shortcuts הקלאסיים אינם יודעים לעשות זאת — שם כל חיבור מעוצב לתרחיש מסוים, והוספת וריאציה חדשה משמעה פעולה חדשה.
תמיכת המערכת — ההבדל המרכזי לטווח ארוך. App Intents מתפתחים כמנגנון האינטגרציה העיקרי: יכולות חדשות של הפלטפורמה מופיעות קודם כל כאן, וההרחבות הישנות נשארות במצב תאימות.
עבור האפליקציה המשמעות היא שההשקעה באינטנטים לא תצטרך להיכתב מחדש בעדכון המערכת הבא, בעוד שתרחישים על הרחבה מיושנת מאבדים בהדרגה גישה לנקודות כניסה חדשות.
בעלויות התחזוקה ההבדל מתגלה למרחק. הגישה הקלאסית זולה יותר בהתחלה — מהר משחררים סט פעולות וסוגרים את המשימה. App Intents דורשים מודל נתונים מדויק: טיפוסי פרמטרים, תיאורים, טיפול בשגיאות, לוקליזציה של ביטויים.
לעומת זאת בהמשך הוספת תרחיש היא לרוב פרמטר חדש ולא קוד חדש, וצריך לבדוק התנהגות אחת במקום סט של חיבורים של משתמשים.
ספקות טכניים נפוצים לפני ההתחלה
לפני ההתחלה כמעט כל צוות שואל את אותה קבוצת שאלות: האם האינטגרציה תשבור את הגרסה הנוכחית, מה עם תמיכה במכשירים ישנים וכמה קוד יהיה צריך לכתוב מחדש. להלן תשובות ענייניות, בלי מילים כלליות.
האם App Intents יעבוד בכל גרסאות iOS?
לא, וזה נכלל בארכיטקטורה מההתחלה. מנגנון האינטנטים עצמו זמין החל מענף גרסה ראשי מסוים של המערכת, וחלק מהיכולות — רק בגרסאות חדשות יותר.
לכן אנחנו לא "מפעילים" את האינטגרציה באופן גלובלי, אלא עוטפים אותה בבדיקת גרסה: במערכות חדשות המשתמש מקבל את מלוא מערך התרחישים דרך Siri ו"קיצורי דרך", במערכות ישנות האפליקציה עובדת כמו קודם, בלי ירידה בביצועים. חלקם של המכשירים בגרסאות עדכניות הוא בדרך כלל כבר הרוב, כך שהכיסוי של הקהל כמעט ולא נפגע.
האם יהיה צורך לכתוב מחדש קוד קיים?
לא. אינטנטים הם שכבה נפרדת מעל הלוגיקה, ולא תחליף. אנחנו מוציאים את הפעולות הנדרשות לאינטנטים שקוראים לשיטות קיימות של האפליקציה: אימות, עבודה עם נתונים, בקשות רשת. בליבה אנחנו לא נוגעים, לכן הסיכונים לפונקציונליות הנוכחית מינימליים, והרגרסיה מוגבלת לתרחישים חדשים. אם הלוגיקה הייתה קשורה באופן נוקשה לממשק, מפרידים אותה בזהירות — זהו למעשה עיקר היקף העבודות.
כמה גדולה העבודה מבחינת לוחות זמנים?
ההיקף תלוי במספר התרחישים, ולא בטכנולוגיה עצמה. אינטנט אחד או שניים — זו משימה נקודתית שלא מעכבת את הגרסה. מערך מלא עם ביטויים קוליים, פרמטרים ווידג'טים — שלב נפרד שמתוכנן מראש. אנחנו תמיד מתחילים מתרחיש אחד, בודקים אותו על משתמשים אמיתיים ורק אחר כך מרחיבים.
מה עם תמיכה ועדכוני מערכת?
Apple משנה מעת לעת דרישות לאינטנטים ומוסיפה סוגים חדשים. אנחנו מניחים תאימות כך שיציאתה של גרסת מערכת נוספת לא תשבור תרחישים שכבר עובדים, ומלווים את האינטגרציה יחד עם האפליקציה. זה חלק מהתמיכה, ולא הגדרה חד-פעמית.
אם נותרו ספקות לגבי בסיס הקוד שלכם — תארו את המשימה, נחזור עם הערכה ותוכנית.
בואו נדון במשימה שלכם לאינטגרציה של App Intents
כדי שהערכה של אינטגרציית App Intents תהיה מבוססת ולא "בעין", אנחנו צריכים נתוני מקור על האפליקציה ועל התרחישים שאתם רוצים להוציא ל-Siri ולקיצורי דרך מערכתיים. ככל שהנתונים המדויקים יותר, כך יהיו פחות הנחות בתוכנית והלוחות זמנים יהיו צפויים יותר. להלן מה שאנחנו מבררים ובאיזה פורמט לשלוח.
- תרחישי משתמש. רשימת פעולות שאמורות להיות מופעלות בקול או מקיצורי דרך: מה לפתוח, מה ליצור, אילו פרמטרים מועברים. תארו את הביטויים שאנשים באמת ישתמשו בהם כדי להפעיל זאת.
- ארכיטקטורה נוכחית. כיצד בנויה האפליקציה: שפה, שכבות, היכן נמצאת הלוגיקה העסקית, האם קיימת עיבוד ברקע. מזה תלוי אם אנחנו מוציאים את הלוגיקה למודול נפרד או עושים שימוש חוזר בקיים.
- מודל נתונים והרשאות גישה. אילו ישויות משתתפות בתרחישים, היכן הן נשמרות, מה צריך לחשוף החוצה דרך App Intents ומה נשאר סגור.
- גרסאות מערכת יעד. גרסת iOS המינימלית הנתמכת וחלק המכשירים עליה — קובע אילו יכולות של App Intents זמינות ואילו יצטרכו לעקוף.
- תרחישי כשל. מה צריך לקרות אם לא ניתן לבצע את הפעולה: להציג התראה, להציע חלופה, להסתיים בשקט. זה משפיע על היקף העבודה.
- גישות וסביבה. בניות בדיקה, חשבונות, גישה למאגר ולמערכות אנליטיקה — בלעדיהם לא נוכל לבדוק תרחישים על מכשירים אמיתיים.
לפי סעיפים אלה אנחנו חוזרים עם הערכה ותוכנית: חלוקה לשלבים, מה אנחנו עושים קודם, היכן הסיכונים ואיך אנחנו בודקים את התוצאה. הצעד הבא — ניתוח קצר של המשימה: תארו את האפליקציה ואת התרחישים, ואנחנו נברר את החסר ונציע סדר עבודה.