מ-⁠Base44 ל-⁠App Store: איך עובדות גרסאות המובייל ואיפה הן נעצרות

איך עובדות גרסאות המובייל של Base44

המדריך של Base44 לחנויות האפליקציות מתאר את המודל בפשטות: אפליקציית המובייל מריצה את אפליקציית ה-⁠Base44 שפרסמתם בתוך תצוגת ווב מאובטחת (web view), עטיפה נייטיב קלה שפותחת רק את הכתובת של האפליקציה שלכם.

מתוך העורך אפשר:

• לסרוק את האפליקציה מול ההנחיות של Apple ו-⁠Google ולקבל ציון מוכנות (זמין גם במסלול Free).
• לתקן את הבעיות שסומנו בעזרת צ׳אט ה-⁠AI, ולסרוק שוב.
• להפיק את הקבצים לחנויות, ל-⁠App Store ול-⁠Google Play, מה שמחייב מסלול Builder ומעלה.
• להוסיף התראות פוש בזמן הפקת הקבצים, עם מפתח פוש של Apple ופרויקט Firebase, ולשלוח אותן מצד השרת דרך אינטגרציית התראות הפוש של Base44 (כקרדיט אינטגרציה אחד לכל התראה).

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

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

קובצי APK ו-⁠AAB, וחנות Play

ל-⁠Android, ‏Base44 מפיקה קובץ AAB (Android App Bundle), לא APK. ל-⁠iPhone היא מפיקה קובץ IPA. שתי ההורדות מחייבות מסלול Builder ומעלה.

קובץ AAB הוא הפורמט ש-⁠Google Play מבקשת: מאז אוגוסט 2021 אפליקציות חדשות חייבות להתפרסם כ-⁠App Bundle, ו-⁠Play הופכת את החבילה לקובצי ה-⁠APK שכל מכשיר מוריד (התיעוד למפתחי Android). לא צריך APK כדי להגיע למשתמשים בחנות Play.

אבל קובץ AAB אי אפשר להתקין ישירות בטלפון. אם צריך APK כדי לנסות את האפליקציה במכשיר שלכם או כדי למסור אותה לבודק:

• להשתמש במסלול הבדיקות הפנימיות (internal testing) של Play. מעלים את ה-⁠AAB, והוא מגיע לעד 100 בודקים תוך דקות, ובדיקות פנימיות עשויות לדלג על הסקירות הרגילות של Play (העזרה של Google Play Console). זו הדרך הפשוטה ביותר, והבודקים מקבלים בדיוק את אותה גרסה שתשמש את ההפצה הציבורית.
• להמיר אותו עם bundletool. הכלי bundletool של Google בונה קובצי APK מתוך App Bundle, כולל APK "אוניברסלי" יחיד, ומתקין אותם על מכשיר מחובר. זה כלי למפתחים, ו-⁠APK שאתם חותמים עליו בעצמכם בדרך הזו הוא לא העותק ש-⁠Play מפיצה, אז כדאי להשאיר אותו לבדיקות.

שלושה פרטים על Android מהמדריך לחנויות של Base44 שכדאי להכיר לפני שיוצרים את הדף בחנות: שם החבילה (package name) קבוע, והוא בנוי מ-com.base, ממזהה האפליקציה ומ-.app; אם יש באפליקציה התחברות עם Google, מוסיפים ב-⁠Base44 את טביעת האצבע SHA-256 של חתימת האפליקציה ב-⁠Play; ואם Play Console מבקשת להוכיח בעלות על שם החבילה, מדביקים את קטע הקוד של Google ב-⁠Base44, והיא בונה את הקבצים מחדש.

מה העטיפה עוד לא יודעת לעשות

Base44 גלויה לגבי המגבלות הנוכחיות:

• אין רכישות בתוך האפליקציה. Apple ו-⁠Google מחייבות שמוצרים דיגיטליים שנמכרים בתוך אפליקציה, כמו מנויים, יכולות פרימיום או קרדיטים, יעברו דרך מערכות התשלום שלהן. Base44 עדיין לא תומכת ב-⁠StoreKit או ב-⁠Google Play Billing, ומזהירה שאפליקציה שמוכרת תוכן דיגיטלי דרך Stripe תידחה. הפתרון המוצע הוא למכור באתר, ושהאפליקציה תבדוק מי שילם, בלי שום תהליך תשלום בתוך האפליקציה. Base44 גם מציינת שתוספים של צד שלישי, כמו RevenueCat או תוספי רכישה של Capacitor, צריכים גישה נייטיב שהאפליקציות שלה לא חושפות, ולכן הם לא עובדים.
• אין HealthKit, ואין מצב אופליין מלא.
• דף פתיחה קבוע. האפליקציה נפתחת בנקודת הכניסה ש-⁠Base44 בוחרת מתוך האפליקציה שפרסמתם; אי אפשר לבחור דף פתיחה אחר למובייל.
• מזהים קבועים. Base44 קובעת את מזהה החבילה (bundle ID) ואת מפתח החתימה בקבצים שהיא מפיקה, ואי אפשר לשנות אותם. אם כבר פרסמתם בעבר אפליקציה נייטיב לאותו מותג, החנויות עלולות לחסום את העדכון, וההמלצה של Base44 היא ליצור דף חדש בחנות.
• התחברות עם Google דורשת צעד נוסף. מוסיפים ל-⁠Base44 את טביעת האצבע של חתימת האפליקציה ב-⁠Google Play, כדי שההתחברות עם Google תעבוד באפליקציה המותקנת.

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

מה החנויות דורשות, לא משנה במה בונים

הדברים האלה חלים על כל אפליקציה, לא משנה איך היא נבנתה:

• Apple Developer Program: עלות של $99 לשנה, על שמכם או על שם החברה שלכם.
• Google Play Console: דמי הרשמה חד-פעמיים של $25.
• חשבונות Google Play אישיים חדשים צריכים 12 בודקים או יותר שהצטרפו לבדיקה סגורה, במשך 14 ימים רצופים, לפני שאפשר לבקש גישה לפרודקשן (דרישות הבדיקה של Google). כדאי לתכנן את השבועיים האלה מראש.
• כלל הפונקציונליות המינימלית של Apple (הנחיה 4.2): אפליקציה שהיא רק אתר בתוך מסגרת עלולה להידחות. צריך להראות שהאפליקציה שימושית כאפליקציה: התראות פוש, התחברות מסודרת ומסכים שעוצבו לטלפון עוזרים.
• מחיקת חשבון: אם אפשר לפתוח חשבון באפליקציה שלכם, Apple דורשת שאפשר יהיה גם למחוק אותו מתוך האפליקציה.
• גישה לסוקרים: נותנים לסוקרים חשבון הדגמה שעובד, ומוודאים שמדיניות הפרטיות ותנאי השימוש זמינים עוד לפני ההתחברות.

דרכים אחרות להגיע לטלפון

אפליקציית PWA: בלי חנות בכלל

אפליקציית ווב מתקדמת (PWA) היא אתר שאפשר להתקין בטלפון. Base44 מפיקה בשבילכם את ה-⁠manifest של אפליקציית הווב מהשם, מהתיאור ומהאייקון של האפליקציה, כך שאפשר להשתמש באפשרות Add to Home Screen (הוספה למסך הבית) ולקבל את האייקון שלכם ואפליקציה במסך מלא (יצירת האפליקציה ושימוש בה במובייל). אין חשבון מפתחים, אין סקירה ואין דמי חנות, וכל פרסום מגיע לכולם בבת אחת.

מה ש-⁠PWA לא מקבלת הוא דף בחנות, ואיתו החשיפה והאמון שבאים עם נוכחות ב-⁠App Store או ב-⁠Google Play. שימוש אופליין תלוי ב-⁠service worker, שאינו חובה כדי להתקין (MDN), והתיעוד של Base44 לא מתאר תמיכה באופליין בגרסת הווב. לכלי פנימי, לפורטל לקוחות או למוצר בשלב מוקדם, PWA היא לא פעם כל מה שצריך.

Capacitor, ‏PWABuilder ו-⁠Trusted Web Activities

דף המובייל של Base44 עצמה מזכיר שלושה כלים של צד שלישי, שבעזרתם אפשר לעטוף בעצמכם את הכתובת של האפליקציה או את הקוד המיוצא שלה: Capacitor, ‏PWABuilder וגם Trusted Web Activities. הוא גם מציין שהכלים האלה מנוהלים מחוץ ל-⁠Base44, שיכולות נייטיב כמו התראות פוש צריך להגדיר בנפרד, ושייצוא הקוד מחייב מסלול Builder ומעלה.

• Capacitor הופך אפליקציית ווב לפרויקטים נייטיב ל-⁠iOS ול-⁠Android, שאתם בונים וחותמים בעצמכם (התיעוד של Capacitor). הוא הגמיש מבין השלושה, והוא זה שמתואר בפרק הבא.
• PWABuilder אורז אפליקציות PWA לחנויות האפליקציות (PWABuilder ב-⁠GitHub).
• Trusted Web Activity פותחת את אפליקציית הווב שלכם במסך מלא בתוך אפליקציית Android. צריך להראות שהאפליקציה והאתר באים מאותו מפתח, וזה מאומת באמצעות קובץ Digital Asset Links בדומיין שלכם (התיעוד למפתחי Chrome), ולכן צריכה להיות לכם אפשרות לפרסם את הקובץ הזה בכתובת שלכם.

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

אפליקציית React Native נפרדת

Base44 מתעדת גם בנייה של אפליקציית מובייל ב-⁠React Native (Expo) מול שירות צד השרת שלה, עם אותו SDK (מדריך התחלה מהירה ל-⁠React Native). זו אפליקציה שנייה שמפתח כותב מול צד שרת של Base44, ולא עטיפה סביב האפליקציה שכבר יש לכם.

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

כשהקוד וצד השרת של האפליקציה שייכים לכם, העטיפה מפסיקה להיות מוצר קבוע והופכת לבחירה. הגדרה נפוצה היא Capacitor, שאורז אפליקציית React כפרויקט נייטיב ל-⁠iOS ול-⁠Android שנמצא בשליטתכם:

• רכישות בתוך האפליקציה דרך StoreKit ו-⁠Google Play Billing, ישירות או דרך שירות כמו RevenueCat, כשצד השרת שלכם מאמת כל רכישה.
• יכולות נייטיב: התראות פוש, קישורי עומק (deep links), זיהוי ביומטרי, גישה למצלמה ולקבצים, משימות ברקע, ו-⁠HealthKit אם צריך.
• מזהים וחתימה משלכם, כך שאפשר לשמור על דף קיים בחנות.
• התנהגות אופליין שאתם מתכננים, למשל שמירה במטמון של המסכים והנתונים החשובים.
• קצב גרסאות משלכם, מתוך המאגר (repository) שלכם.

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

Unbase44 ומובייל

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

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

בקרוב בעמוד של האפליקציה ב-⁠Unbase44: לחיצה אחת לבניית אפליקציית ה-⁠Android, וגרסאות iPhone שנבנות על Mac בענן ועולות ל-⁠TestFlight, בלי Mac משלכם.

רכישות של מוצרים דיגיטליים בתוך האפליקציה עדיין צריכות StoreKit או Google Play Billing, שהמפתח שלכם (או סוכן הקוד) מוסיף במאגר שלכם.