מובייל וחוויית משתמש — Mobile and Cross-Platform

1. המציאות של מובייל — The Mobile Reality

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

מה זה אומר בפועל? נניח שבנית אתר מושלם למסעדה ישראלית. הבעלים מרוצים, זה נראה מדהים על ה-iMac שלהם במשרד. אבל 70% מהלקוחות פותחים את האתר בזמן שהם בדרך, עומדים ברחוב, אור שמש חזק על המסך, מחזיקים את הטלפון ביד אחת בזמן שהשנייה מחזיקה שקית. אם הכפתור "הזמן שולחן" קטן מדי, אם הטלפון של המסעדה חתוך, אם התפריט לא נטען — הפסדת לקוח. בגלל UX גרוע במובייל, לא בגלל האוכל.

כ-Vibe Coder, המציאות הזו דווקא לטובתך. Claude Code מצוין בבניית ממשקים רספונסיביים — הוא מכיר את כל ה-CSS, את כל ה-Media Queries, ואת כל הטריקים של מובייל. הוא גם יכול להריץ בדיקות אוטומטיות על הקוד שלך דרך כלי Bash מובנה, או להשתמש ב-Playwright MCP כדי לפתוח את האתר שלך בגדלי מסך שונים ולצלם מסך. אבל אתה צריך לדעת מה לבקש ואיך לבדוק את התוצאה. בואו נתחיל עם שלוש הגישות העיקריות לבניית חוויית מובייל:

שלוש הגישות לבניית חוויית מובייל

הפילוסופיה של Mobile-First

Mobile-First זו לא סתם טכניקה — זו דרך חשיבה שמשנה את כל תהליך העבודה שלך. הגישה המסורתית היא "Desktop First": מעצבים למסך גדול ואז "מדחסים" הכול למובייל. התוצאה? אתר שנראה כמו דסקטופ מכווץ — לא נעים, לא נוח, לא מזמין. Mobile-First הפוך לגמרי: אתה מתחיל מהמסך הקטן ביותר — 375 פיקסלים (אייפון SE) — ומוסיף מורכבות ככל שהמסך גדל.

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

איך אומרים את זה ל-Claude? במקום "Design my page", אמור: "Design this page mobile-first: start with a single-column layout for 375px screens, then add a 2-column layout for tablets (768px), and a 3-column layout for desktop (1024px+)." הפירוט הזה מבטיח ש-Claude יתחיל ממובייל.

מה המשתמשים מצפים לראות במובייל? ארבעה דברים קריטיים:

• טעינה מהירה — מתחת ל-3 שניות. אם האתר שלך איטי, המשתמש כבר הלך. Google מדווחת ש-53% מהמשתמשים נוטשים אתר שנטען יותר מ-3 שניות.
• כפתורים שאפשר ללחוץ עליהם — Touch Targets של לפחות 44x44 פיקסלים. האצבע הרבה יותר גדולה מסמן העכבר. אם הכפתור קטן מדי, המשתמש מתוסכל.
• תנועות מגע טבעיות — Swipe לניווט, Pull-to-Refresh לרענון, Pinch-to-Zoom לתמונות. המשתמש מצפה לאינטראקציות שמרגישות טבעיות לטלפון.
• בלי גלילה אופקית — אף פעם. זה הסימן הראשון שמשהו שבור בעיצוב שלך.

2. עיצוב רספונסיבי — Responsive Design Mastery

אנשים חושבים שעיצוב רספונסיבי זה "להוסיף Media Queries". זו רק חלק קטן מהתמונה. Media Query (שאילתת מדיה) הוא כלל CSS שאומר "אם המסך קטן מ-768 פיקסלים, עשה כך". זה חשוב, אבל זה רק אחד מהכלים. עיצוב רספונסיבי אמיתי (Responsive Design) מבוסס על שלושה עמודי תווך: פריסות גמישות (Fluid Layouts), תמונות מתאימות (Flexible Images), ותעדוף תוכן (Content Priority). Claude Code מצוין בכל השלושה — אם אתה יודע מה לבקש.

תהליך העבודה הרספונסיבי עם Claude Code

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

1. תאר את ה-Layout ב-Prompt — "Build a responsive product grid: 1 column on mobile, 2 on tablet, 3 on desktop"
2. Claude כותב את הקוד — CSS Grid + Media Queries + HTML
3. בדוק בדפדפן — פתח DevTools, לחץ Ctrl+Shift+M להדלקת Device Toolbar, ובדוק ב-375px, 768px, 1024px
4. צלם מסך ושלח ל-Claude — "Here's how it looks on mobile [screenshot]. The cards are too close together and the text is cut off. Fix the spacing and font size."
5. חזור על 3-4 — עד שזה מושלם בכל גודל מסך

הטריק: תמיד תבדוק בשלושה גדלים — 375px (אייפון SE, המסך הצר ביותר שרלוונטי), 768px (טאבלט / iPad), ו-1024px+ (דסקטופ). אם זה עובד בשלושת הגדלים האלה, זה יעבוד בכל מכשיר.

CSS Grid ו-Flexbox — שתי מערכות הפריסה

אם אתה זוכר רק שני דברים מהסעיף הזה, שיהיו אלה:

• Flexbox — מסדר אלמנטים בכיוון אחד: שורה או עמודה. מושלם לסרגלי ניווט, רשימות כפתורים, וכרטיסים בשורה. תחשוב עליו כמו חוט שמחרז עליו חרוזים.
• CSS Grid — מסדר אלמנטים בשני כיוונים: שורות ועמודות. מושלם ל-Layouts מורכבים, דשבורדים, וגלריות. תחשוב עליו כמו גליון Excel שאתה ממלא.

מתי להשתמש בכל אחד? Flexbox מושלם כשיש לך אלמנטים בכיוון אחד — תפריט ניווט אופקי, רשימת כפתורים, כרטיסים בשורה. CSS Grid מושלם כשצריך שליטה דו-מימדית — דשבורד עם כרטיסים בגדלים שונים, גלריית תמונות, או Layout של עמוד שלם עם Header, Sidebar ו-Content.

אגב, ברוב המקרים אתה תשתמש בשניהם באותו פרויקט. CSS Grid ל-Layout הכללי של העמוד, Flexbox בתוך כל רכיב. ב-Vibe Coding, אתה לא צריך לכתוב CSS Grid או Flexbox בעצמך. אתה מתאר את מה שאתה רוצה, ו-Claude עושה את השאר:

טיפוגרפיה רספונסיבית — טקסט שמתאים את עצמו

טקסט שנראה מושלם על מסך 27 אינץ' נראה ענקי על טלפון, ולהיפך. כותרת font-size: 48px תיראה נהדר בדסקטופ אבל תתפוס שתי שורות על טלפון ותרגיש מגושמת. הפתרון: פונקציית clamp() ב-CSS.

בקש מ-Claude: "Make all headings responsive using clamp() so they scale smoothly between mobile and desktop. Use rem units." — והוא יטפל בזה. גם ב-paragraph text כדאי להשתמש ב-clamp — למשל font-size: clamp(0.95rem, 1.5vw, 1.1rem) כדי שטקסט הגוף יהיה קריא בכל מסך.

תמונות רספונסיביות — שלוש טכניקות

• srcset — מגדיר גרסאות שונות של אותה תמונה בגדלים שונים. הדפדפן בוחר את הגודל המתאים למסך.
• <picture> — מאפשר חיתוכים שונים לפי גודל מסך. למשל: תמונה רחבה בדסקטופ, חיתוך מרובע במובייל.
• Lazy Loading — תמונות נטענות רק כשגוללים אליהן. חוסך זמן טעינה ורוחב פס. פשוט מוסיפים loading="lazy" ל-img.

Touch Targets — כפתורים שאפשר באמת ללחוץ עליהם

הכלל הוא פשוט: 44x44 פיקסלים מינימום לכל אלמנט שאפשר ללחוץ עליו. זה הסטנדרט של Apple ו-Google. כפתורים קטנים יותר גורמים לטעויות לחיצה ולתסכול. תחשוב על האצבע שלך מול סמן העכבר — האצבע מכסה שטח של לפחות 40 פיקסלים, ולרוב יותר. כשלוחצים על כפתור קטן, קל "לפספס" וללחוץ על הלינק שלידו.

מה נחשב Touch Target? כל דבר שלוחצים עליו: כפתורים, לינקים, תיבות בחירה (checkboxes), כפתורי רדיו, אייקונים של סגירה (X), חיצים של ניווט, ושורות בטבלה שניתן ללחוץ עליהן. אלמנטים נפוצים שבדרך כלל קטנים מדי: כפתור ה-X בפינה (לסגירת מודאל), לינקים בתוך טקסט, אייקוני מדיה חברתית בפוטר.

בקש מ-Claude: "Audit all clickable elements and ensure they meet the 44x44 pixel minimum touch target size. Add padding where needed without changing the visual design." — והוא יעבור על כל הכפתורים, הלינקים, והאייקונים ויתקן. הטריק: לפעמים אפשר להגדיל את אזור הלחיצה (עם padding) בלי להגדיל את הכפתור עצמו ויזואלית.

3. Progressive Web Apps — אתר שמתנהג כמו אפליקציה

PWA = אפליקציית ווב שמתנהגת כמו אפליקציה רגילה. אפשר להתקין אותה על מסך הבית, היא עובדת גם בלי אינטרנט, היא יכולה לשלוח התראות Push, והיא נפתחת במסך מלא בלי סרגל כלים של הדפדפן. וכל זה — מאתר רגיל, בלי App Store, בלי תשלום ל-Apple, בלי המתנה לאישור.

למה PWA היא המהלך הגדול עבור Vibe Coders? כי אתה מקבל 80% מהיתרונות של אפליקציה נייטיב בעשירית מהמאמץ. תחשוב על זה: אפליקציה נייטיב דורשת חשבון מפתח (כ-100 דולר בשנה ל-Apple), תהליך בנייה מורכב, בדיקות Apple/Google, והמתנה לאישור. PWA? אתה מוסיף שני קבצים לאתר הקיים שלך ו-BANG — אפליקציה שניתן להתקין. בואו נבין מה הופך אתר רגיל ל-PWA:

שלושת המרכיבים של PWA

בקש מ-Claude: "Convert my website into a PWA" — והוא יוסיף manifest.json, ירשום Service Worker, ויגדיר Cache בסיסי. בפקודה אחת, האתר שלך הפך לאפליקציה שניתן להתקין.

בואו נראה איך כל מרכיב נראה בפועל:

manifest.json — כרטיס הביקור של ה-PWA

Service Worker — המוח מאחורי הקלעים

ה-Service Worker הוא סקריפט JavaScript שרץ ברקע, נפרד מהדף הראשי. הוא כמו עוזר אישי שיושב בין האתר שלך לבין האינטרנט ומחליט מה לעשות עם כל בקשה. הוא יכול:

• לשמור קבצים ב-Cache — כדי שהאתר יטען מהר (ויעבוד אופליין)
• ליירט בקשות רשת — ולהחליט אם לפנות לרשת או להגיש מה-Cache
• לקבל Push Notifications — גם כשהמשתמש לא גולש באתר
• לסנכרן נתונים ברקע — כשהחיבור חוזר אחרי שהיה אופליין

בקש מ-Claude: "Create a Service Worker that caches all static assets on install, and serves them from cache when offline, falling back to a custom offline page for uncached routes." — והוא ייצור את כל הלוגיקה.

Push Notifications — התראות למשתמשים

אחת היכולות החזקות ביותר של PWA היא Push Notifications — התראות שמופיעות על הטלפון של המשתמש גם כשהאתר סגור. "שלח התראה למשתמש כשהמשימה שלו מגיעה לדדליין" — Claude מחבר את Web Push API ומגדיר הכול.

חשוב להבין את הנושא של הרשאות: המשתמש חייב לאשר קבלת התראות. אל תבקש הרשאה ברגע שהמשתמש נכנס לאתר — זה מרגיז ורוב האנשים דוחים. במקום, חכה שהמשתמש יבצע פעולה רלוונטית (כמו "הזכר לי על המשימה הזו"), ואז בקש הרשאה בהקשר — שיעורי האישור קופצים פי 3. ב-Android ההתראות עובדות מעולה — בדיוק כמו אפליקציה נייטיב. ב-iOS זה נתמך מ-iOS 16.4 (2023) ומעלה, עם כמה מגבלות: ההתראה מגיעה רק כשהאפליקציה "מותקנת" (Added to Home Screen), ואין תמיכה ב-Silent Push.

שימושים פרקטיים נפוצים ל-Push Notifications:

• תזכורות למשימות — "המשימה 'להגיש הצעת מחיר' מגיעה לדדליין בעוד שעה"
• עדכוני סטטוס — "ההזמנה שלך נשלחה!" או "הבקשה שלך אושרה"
• התראות מחיר — "המוצר שעקבת אחריו ירד ב-30%!"
• עדכוני תוכן — "מאמר חדש פורסם בנושא שמעניין אותך"

Claude Code ו-PWA — תהליך העבודה המלא

הנה תהליך העבודה המומלץ להפיכת אתר קיים ל-PWA עם Claude Code:

1. שלב 1 — יצירת קבצי ה-PWA: "Convert my website into a PWA: add manifest.json, service worker with cache-first for static assets, and register it in index.html"
2. שלב 2 — יצירת אייקונים: "Create a simple SVG icon for my app and generate PNG versions at 192x192 and 512x512 pixels" — או השתמש בכלי כמו favicon.io ליצירת אייקונים מלוגו קיים
3. שלב 3 — בדיקה ב-DevTools: פתח Application → Manifest → בדוק שאין שגיאות. פתח Application → Service Workers → בדוק שרשום ופעיל.
4. שלב 4 — בדיקת אופליין: ב-DevTools, לשונית Network → סמן "Offline" → רענן את הדף. האם התוכן נטען? אם לא — שלח ל-Claude: "The page doesn't load offline. Check the service worker cache and fix."
5. שלב 5 — Lighthouse PWA audit: הרץ Lighthouse → בדוק ש-PWA מסומן בירוק. Claude יכול לתקן כל בעיה שנמצאת.

4. בניית אפליקציות שניתן להתקין

ההתקנה היא הרגע הקסום של PWA. המשתמש לוחץ "התקן", ופתאום האפליקציה שלך יושבת על מסך הבית שלו — בדיוק כמו WhatsApp או Instagram. אייקון, שם, ופתיחה במסך מלא. בלי App Store, בלי עמלה של 30%, ובלי המתנה של שבועיים לאישור.

manifest.json — כרטיס הביקור של האפליקציה

הקובץ manifest.json הוא מה שהדפדפן קורא כדי להבין שהאתר שלך הוא אפליקציה. הנה מה שצריך להגדיר:

• name ו-short_name — השם המלא והשם המקוצר (מופיע מתחת לאייקון)
• icons — אייקונים במספר גדלים. מינימום: 192x192 ו-512x512 פיקסלים. Claude יכול ליצור placeholder או לעזור לך להכין אותם.
• start_url — העמוד שנפתח כשמשתמשים פותחים את האפליקציה
• display — מצב התצוגה: standalone (בלי סרגל דפדפן — מרגיש כמו אפליקציה), fullscreen (מסך מלא), minimal-ui (סרגל מינימלי)
• background_color — צבע הרקע של מסך הפתיחה (Splash Screen)
• theme_color — צבע סרגל הסטטוס בטלפון

Splash Screen — מסך פתיחה

כשהמשתמש פותח את ה-PWA שלך, הוא רואה Splash Screen — מסך טעינה עם האייקון, השם, וצבע הרקע. זה מייצר תחושת אפליקציה נייטיב. הדפדפן יוצר את זה אוטומטית מהנתונים ב-manifest.json. אתה רק צריך לוודא שהאייקון ברזולוציה טובה (512x512 פיקסלים, PNG שקוף) והצבעים תואמים את העיצוב שלך. טיפ: השתמש ב-background_color שתואם לרקע של האתר שלך, כך שהמעבר מ-Splash Screen לתוכן יהיה חלק.

Custom Install Prompt — הודעת התקנה מותאמת

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

בקש מ-Claude: "Create a beautiful install prompt that appears after the user has visited 3 pages. Show benefits: offline access, faster loading, and home screen icon. Include a 'Not now' button that delays the prompt for 7 days." — כך מקבלים הודעת התקנה שמרגישה טבעית ולא מעצבנת.

5. עיצוב Offline-First — לעבוד גם בלי אינטרנט

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

אפילו חיבור שנראה "תקין" יכול להיות בעייתי. מה שנקרא "Lie-Fi" — חיבור WiFi שמראה חיבור מלא אבל בפועל כמעט לא מעביר נתונים. קורה במלונות, בתי קפה, ומשרדים עם WiFi עמוס. Offline-First מגן גם ממצבים כאלה, כי הנתונים כבר ב-Cache.

אסטרטגיות Cache — שלוש גישות

בקש מ-Claude: "Implement a Service Worker with Cache First for static assets and Stale While Revalidate for API responses" — והוא ייצור Service Worker מקצועי עם אסטרטגיות Cache נכונות.

IndexedDB — בסיס נתונים בדפדפן

כשצריך לאחסן נתונים מורכבים אופליין — לא רק קבצים סטטיים אלא רשימות משימות, הגדרות משתמש, או טפסים שלא נשלחו — משתמשים ב-IndexedDB. זה בסיס נתונים מלא שחי בתוך הדפדפן. בניגוד ל-localStorage שמאחסן רק מחרוזות פשוטות (ומוגבל ל-5MB), IndexedDB תומך באובייקטים מורכבים, חיפוש לפי אינדקס, ויכול לאחסן עד מאות מגהבייטים. Claude יודע לבנות מערכת CRUD מלאה שעובדת אופליין עם IndexedDB.

למשל: "Create an offline task manager: when the user adds a task, save it to IndexedDB. When the user marks a task as complete, update it in IndexedDB. When the internet connection returns, sync all changes to Supabase." — Claude יבנה את כל הלוגיקה: שמירה מקומית, תור סנכרון (sync queue), ושליחה לשרת כשהחיבור חוזר.

Conflict Resolution — מה קורה כשיש סתירות

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

• Last Write Wins — מי שכתב אחרון, שלו זה. פשוט, אבל אפשר לאבד שינויים.
• Client Wins — תמיד מעדיפים את מה שהמשתמש עשה. טוב ל-UX אבל מסוכן לנתונים.
• Merge — מנסים למזג את שני השינויים. מורכב אבל שומר הכול.

ברוב פרויקטי Vibe Coding, Last Write Wins מספיק. בקש מ-Claude: "Implement offline-first CRUD for the task list: save to IndexedDB when offline, sync to Supabase when back online, use last-write-wins for conflicts."

דף אופליין מותאם אישית

מה קורה כשמשתמש מנסה לגשת לדף שלא נשמר ב-Cache? במקום "No Internet" גנרי ומפחיד, הראה לו דף אופליין מותאם אישית עם הלוגו שלך, הסבר ידידותי, וכפתור "נסה שוב". זה מעלה את התחושה המקצועית ומבטיח שהמשתמש לא חושב שהאתר שלך "מת".

בקש מ-Claude: "Create a beautiful custom offline fallback page with my app's branding. Show a friendly message in Hebrew that says the user is offline and their data is safe. Add a retry button." — זה לוקח דקה ומשדרג את החוויה בצורה משמעותית.

Workbox — הספרייה שמפשטת Service Workers

כתיבת Service Worker מאפס היא מורכבת ומלאת מלכודות. Workbox היא ספרייה של Google שמפשטת את הכול — במקום לכתוב 200 שורות של Cache logic, אתה כותב 20 שורות עם Workbox. Claude מכיר את Workbox מצוין. בקש: "Rewrite my service worker using Workbox with precaching for static assets and runtime caching for API calls" — והוא ימיר את הקוד לגרסה נקייה ומקצועית יותר. Workbox גם מתאים לפרויקטים שבנויים עם bundlers כמו Webpack או Vite — Claude יגדיר את ה-plugin המתאים אוטומטית.

6. React Native דרך Claude Code

React Native מאפשר לך לבנות אפליקציות מובייל אמיתיות — אלה שמופיעות ב-App Store וב-Google Play — בעזרת React, אותו פריימוורק שלמדת (או שתלמד) לפיתוח ווב. הרעיון: כותבים קוד אחד, מריצים על שתי הפלטפורמות. אבל — ויש כאן "אבל" גדול — React Native מורכב יותר מפיתוח ווב. תגיע לכאן רק אם באמת צריך.

אם אתה זוכר Components ו-State מפרק 4 (Web Apps), יש לך בסיס טוב. React Native משתמש באותם עקרונות, אבל עם רכיבי UI שונים:

ההבדל העיקרי: ב-React Native אין HTML ואין CSS. במקום זה, אתה משתמש ברכיבים נייטיביים שנראים ומרגישים כמו אפליקציה אמיתית. אבל ב-Vibe Coding אתה לא צריך לזכור את כל זה — Claude יודע את ההבדלים ויכתוב את הקוד הנכון.

ההבטחה של React Native — ומה באמת קורה

ההבטחה: "כתוב קוד אחד, הרץ על iOS ו-Android." המציאות: ברוב המקרים זה עובד, אבל יש פערים. אנימציות שנראות חלקות ב-iOS מרגישות קצת אחרת ב-Android. רכיבי UI מסוימים מתנהגים שונה. ולפעמים צריך "native code" שדורש Xcode או Android Studio.

עבור Vibe Coders, הדבר הכי חשוב לדעת: React Native מצוין לאפליקציות פשוטות עד בינוניות — רשימות, טפסים, ניווט בין מסכים, חיבור ל-API. אם אתה בונה משחק 3D או אפליקציית עריכת וידאו, React Native כנראה לא הכלי הנכון. אבל לרוב הפרויקטים העסקיים — הוא מושלם.

הרצה על טלפון אמיתי

הנה הקסם של Expo: אתה מריץ npx expo start, מקבל קוד QR בטרמינל, סורק אותו עם Expo Go בטלפון, והאפליקציה שלך רצה. בזמן אמת. שומר שינוי בקוד — האפליקציה מתעדכנת על הטלפון תוך שנייה (Hot Reload). זה מרגיש כמו קסם, ובואו נודה — זה קצת קסם.

7. Expo — הדרך הקלה לאפליקציות מובייל

Expo היא ערכת כלים שהופכת את React Native מפחיד לנגיש. בלי Expo, היית צריך להתקין Xcode (Mac בלבד, 12GB), Android Studio (עוד 8GB), ולהתמודד עם תצורות מסובכות. עם Expo, אתה מתחיל עם npx create-expo-app ורואה את האפליקציה על הטלפון תוך דקה.

הלולאה של פיתוח ב-Expo

הנה איך תהליך הפיתוח עובד עם Expo:

1. יצירה — npx create-expo-app my-app → פרויקט מוכן
2. הרצה על הטלפון — npx expo start → סרוק QR עם Expo Go → האפליקציה חיה
3. פיתוח — אתה משנה קוד, האפליקציה מתעדכנת בזמן אמת על הטלפון (Hot Reload)
4. בדיקה — בדוק על טלפון אמיתי, לא על סימולטור
5. חזרה — שפר → בדוק → שפר → בדוק
6. בנייה לחנויות — eas build → קובצי APK/IPA מוכנים להעלאה

Expo Router — ניווט מבוסס קבצים

זוכר את Next.js ואיך הניווט עובד לפי שם קבצים? Expo Router עושה את אותו דבר לאפליקציות מובייל. קובץ app/index.tsx = מסך הבית. קובץ app/settings.tsx = מסך הגדרות. תיקיית app/(tabs)/ = ניווט Tabs — סרגל תחתון עם אייקונים, כמו שיש באינסטגרם או בוואטסאפ. פשוט וחזק.

מה שיפה בזה: אם למדת Next.js, אתה כבר מכיר את הקונספט. מבנה הקבצים קובע את הניווט. אין צורך להגדיר routes ידנית — יוצרים קובץ, ומסך חדש מוכן. בקש מ-Claude: "Set up Expo Router with tab navigation: Home, Search, Profile. Each tab should have its own icon." — והוא ייצר את כל המבנה.

Expo SDK — גישה לחומרת הטלפון

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

EAS Build — בנייה לחנויות האפליקציות

כשהאפליקציה מוכנה, EAS Build (Expo Application Services) בונה את קובצי ה-APK (Android) ו-IPA (iOS) בענן — בלי שתצטרך Mac עם Xcode. הפקודה: eas build --platform all. תוך 15-30 דקות מקבלים קבצים מוכנים להעלאה לחנויות. ה-Build הראשון חינם, אחר כך עולה כ-$5 לבנייה (כ-18 שקלים).

התהליך המלא מפיתוח עד חנות:

1. פיתוח — כותבים ובודקים עם Expo Go
2. בנייה — eas build --platform android → מקבלים קובץ APK
3. בדיקה — מתקינים את ה-APK על טלפון אמיתי ובודקים הכול
4. הגשה — eas submit --platform android → מעלה ל-Google Play Console
5. אישור — Google בודקת (1-3 ימים) → האפליקציה ב-Play Store!

עבור iOS, התהליך דומה אבל צריך חשבון Apple Developer ($99 לשנה, כ-360 שקלים) ואישור Apple (לוקח בדרך כלל 1-7 ימים, ולפעמים דוחים בפעם הראשונה בגלל דרישות מטה-נתונים). אם אתה רק מתחיל, תתחיל עם Android — זה פשוט יותר, זול יותר (חשבון Google Play עולה $25 חד-פעמי, כ-90 שקלים), ורוב השוק הישראלי ב-Android.

הנה תחשיב עלויות מהיר לאפליקציית מובייל דרך Expo:

• פיתוח — Claude Code (כבר יש לך) + Expo (חינם) = 0 שקלים
• Google Play — חד-פעמי: 90 שקלים ($25)
• Apple Developer — שנתי: כ-360 שקלים ($99) — רק אם רוצים להיות ב-App Store
• EAS Build — Build ראשון חינם, אחר כך כ-18 שקלים ($5) לבנייה
• סה"כ למינימום (Android בלבד) — כ-90 שקלים. זהו.

8. שיתוף קוד בין ווב למובייל

נניח שבנית אפליקציית ווב ב-Next.js ואפליקציית מובייל ב-Expo. שתיהן משתמשות באותו בסיס נתונים ב-Supabase. שתיהן צריכות לאמת משתמשים. שתיהן מעבדות אותם נתונים. למה לכתוב את אותו קוד פעמיים?

שיתוף קוד בין ווב למובייל = לבנות פעם אחת, להריץ בכל מקום. Claude Code מנהל את המבנה בשבילך. הרעיון מאוד הגיוני: הלוגיקה העסקית (Business Logic) — כמו חישובים, ולידציות של טפסים, ניהול State, פורמוט תאריכים, ותקשורת עם השרת — היא זהה לגמרי בין ווב למובייל. למה לכתוב את אותה פונקציה שמחשבת מחיר עם מע"מ פעמיים? ה-UI, מצד שני, שונה — ווב משתמש ב-HTML ו-CSS, מובייל משתמש ב-View ו-StyleSheet. אז משתפים את הלוגיקה ומפרידים את הממשק.

מה משתפים ומה לא

גישת Monorepo

Monorepo הוא מאגר קוד אחד שמכיל כמה פרויקטים. במקום שני repos נפרדים (אחד לווב, אחד למובייל), יש repo אחד עם שלוש תיקיות:

בקש מ-Claude: "Refactor the task manager so the Supabase client, types, and validation functions are in a shared package used by both the Next.js web app and the Expo mobile app" — והוא יבנה את מבנה ה-Monorepo.

Supabase — עובד בשני העולמות

אם אתה משתמש ב-Supabase (וסביר שכן, אם עברת את הפרקים הקודמים), יש חדשות טובות: ה-Supabase Client עובד בדיוק אותו דבר ב-Web וב-React Native. אותם קריאות, אותו API, אותו קוד. הדבר היחיד שמשתנה הוא אחסון הטוקנים — ב-Web משתמשים ב-localStorage, ב-React Native ב-AsyncStorage. Claude יודע לטפל בזה אוטומטית.

9. אופטימיזציית ביצועים למובייל

מכשירי מובייל איטיים יותר ממחשבים: פחות RAM, מעבד חלש יותר, מסך קטן יותר, ורשת לא יציבה. מה שנטען תוך חצי שנייה על ה-MacBook שלך יכול לקחת 5 שניות על טלפון ישן עם חיבור 3G. וזכור — לא כל המשתמשים שלך מחזיקים אייפון 16 Pro Max. הרבה אנשים גולשים עם טלפונים ישנים יותר, עם פחות זיכרון ועם חיבור אינטרנט לא מושלם. אופטימיזציית ביצועים למובייל היא לא בונוס — היא חובה.

Core Web Vitals — המדדים של Google

Google מודדת את הביצועים של אתרים בשלושה מדדים עיקריים שנקראים Core Web Vitals. ציון גבוה = דירוג טוב יותר בגוגל + חוויית משתמש טובה יותר:

Lighthouse — הכלי שבודק הכול

Lighthouse הוא כלי של Google שנותן ציון מ-0 עד 100 ב-4 קטגוריות: Performance (ביצועים), Accessibility (נגישות), Best Practices (שיטות עבודה), ו-SEO. הוא בנוי ב-Chrome DevTools — פתח DevTools → לשונית Lighthouse → לחץ "Analyze" → קבל דו"ח מפורט עם המלצות לתיקון.

למה זה חשוב? כי Google שופטת אותך

Core Web Vitals הם לא רק מספרים טכניים — הם משפיעים ישירות על הדירוג שלך בגוגל. מאז 2021, Google משתמשת ב-Core Web Vitals כסיגנל דירוג. אתר עם ציונים ירודים ידורג נמוך יותר ויקבל פחות תנועה אורגנית. אתר עם ציונים מצוינים מקבל העדפה בתוצאות החיפוש. זה לא רק UX — זה גם SEO וכסף.

Lighthouse דרך Claude Code — בדיקה אוטומטית

אתה לא חייב לפתוח DevTools ולהריץ Lighthouse ידנית. Claude Code יכול להריץ Lighthouse מהטרמינל באמצעות כלי ה-Bash המובנה. הנה איך:

טכניקות אופטימיזציה שClaude מיישם

בקש מ-Claude: "Optimize my site for mobile performance" — והוא יעשה את כל אלה:

• אופטימיזציית תמונות — המרה ל-WebP (קטן ב-30%), גדלים רספונסיביים עם srcset, Lazy Loading לתמונות מחוץ למסך.
• Code Splitting — טעינה רק של ה-JavaScript שצריך לעמוד הנוכחי, לא של כל האפליקציה. Claude מגדיר Dynamic Imports ב-Next.js אוטומטית.
• אופטימיזציית פונטים — שימוש בפונטים של המערכת (System Fonts) או טעינת Web Fonts עם font-display: swap כדי למנוע טקסט בלתי נראה.
• הקטנת Bundle — הסרת קוד מת (Tree Shaking), Minification, ו-Compression. Claude מגדיר את הכול ב-build configuration.
• Defer Third-party Scripts — סקריפטים של אנליטיקס, צ'אט, ופרסומות נטענים אחרי התוכן העיקרי.

אופטימיזציית תמונות — הבעיה הנפוצה ביותר

ברוב האתרים, תמונות הן 60-80% מהמשקל של הדף. תמונת JPEG של 3MB שצולמה בטלפון ועלתה ישר לאתר? היא נטענת 5 שניות ברשת 4G. אותה תמונה בפורמט WebP, בגודל מתאים למסך, ועם lazy loading? 200KB, חצי שנייה. ההבדל ענק.

בקש מ-Claude: "Optimize all images on this page: convert to WebP format, add responsive srcset with sizes for mobile (400w), tablet (800w), and desktop (1200w), add lazy loading for all images below the fold." — זה השיפור הכי משמעותי שתעשה בציון Lighthouse.

10. עקרונות עיצוב Cross-Platform

עיצוב Cross-Platform אומר: עצב פעם אחת, יעבוד בכל מקום. לא "אותו דבר בדיוק" — אלא אותה חוויה, מותאמת לכל מכשיר. מה שעובד עם עכבר לא בהכרח עובד עם אצבע. מה שנראה טוב על מסך 27 אינץ' לא בהכרח נראה טוב על מסך של 6 אינץ'. וזה בסדר גמור — זו לא בעיה, זו הזדמנות. עיצוב טוב מותאם להקשר שבו המשתמש נמצא. מישהו שגולש בטלפון בדרך לעבודה צריך מידע מהיר וכפתורים ברורים. מישהו שיושב מול מחשב במשרד מוכן לראות יותר פרטים ולהשתמש בממשק מורכב יותר.

Touch vs Mouse — שני עולמות שונים

• Touch Targets גדולים יותר — אצבע ≠ סמן עכבר. כפתורים של 44x44 פיקסלים מינימום.
• אין Hover — אם המידע החשוב מופיע רק ב-hover, משתמשי מובייל לעולם לא יראו אותו. בדוק שכל מה שחשוב נגיש בלי hover.
• Swipe במקום Right-Click — במובייל, תנועות כמו Swipe מחליפות את הלחצן הימני. "Swipe left to delete" במקום "Right-click → Delete".
• Pull-to-Refresh — תנועה טבעית במובייל שאין לה מקבילה בדסקטופ.

תעדוף תוכן — Content Priority

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

דוגמה מעשית: דשבורד ניהול עסק שיש בו 8 גרפים, טבלת נתונים, ותפריט צד. בדסקטופ הכול מוצג. במובייל? בחר את ה-KPI הכי חשוב (למשל מכירות היום) והציג אותו גדול בראש המסך. הגרפים — בגלילה אנכית, אחד מתחת לשני. התפריט — Hamburger Menu. הטבלה — מציגה רק 3 עמודות (במקום 8), עם אפשרות לגלול הצידה. בקש מ-Claude: "Redesign this dashboard for mobile: show the most important KPI first, stack charts vertically, simplify the data table to show only 3 columns." — והוא ייצר את זה.

טיפוגרפיה ונגישות

• גודל פונט מינימלי 16px — מתחת ל-16px, iOS מגדיל אוטומטית את הזום בטפסים. זה שובר את ה-UX.
• יחידות יחסיות (rem/em) — במקום px קבועים, השתמש ב-rem שמתאים את עצמו להגדרות המשתמש.
• ניגודיות WCAG AA — יחס ניגודיות של לפחות 4.5:1 בין טקסט לרקע. קריטי לקריאות על מסכים קטנים באור שמש.

RTL — עיצוב לעברית וערבית

כ-Vibe Coders שעובדים בעברית, יש לנו אתגר נוסף: RTL (Right-to-Left). רוב ה-Templates והספריות בנויים ל-LTR (שמאל לימין). כשמוסיפים תוכן בעברית, דברים יכולים להישבר: אייקוני חצים הפוכים, Padding בצד הלא נכון, תפריטים שנפתחים בכיוון הלא נכון.

הפתרון: בקש מ-Claude לבנות עם RTL מההתחלה. "Build this page with full RTL support for Hebrew content" מבטיח שהכיוון נכון. אם יש באגים: "Fix RTL issues — check arrow directions, padding, margin, and text alignment for Hebrew layout" — Claude יסרוק ויתקן.

טיפ נוסף: ב-CSS, השתמש ב-margin-inline-start ו-padding-inline-end במקום margin-left ו-padding-right. הגרסאות ה-"logical" מתאימות את עצמן אוטומטית לכיוון הטקסט. Claude יודע את זה, אבל כדאי לבקש במפורש.

בדיקה על כל הפלטפורמות

האתר שלך צריך לעבוד על:

1. Chrome דסקטופ — הדפדפן הנפוץ ביותר (65%+ נתח שוק)
2. Chrome מובייל (Android) — הדפדפן הנפוץ ביותר במובייל
3. Safari iOS — כל משתמשי אייפון (30%+ מהשוק הישראלי). חשוב! Safari מתנהג שונה מ-Chrome בהרבה דברים: CSS, JavaScript APIs, ו-PWA support.
4. Samsung Internet — דפדפן ברירת המחדל על טלפוני Samsung (נפוץ מאוד בישראל). בדרך כלל תואם ל-Chrome, אבל כדאי לבדוק.

איך בודקים בלי להחזיק 10 טלפונים שונים? Chrome DevTools כולל סימולטור מכשירים — Device Toolbar (Ctrl+Shift+M). אתה יכול לדמות iPhone, Pixel, iPad, ועוד. אבל זכור: זה סימולציה, לא המכשיר האמיתי. בדיקה סופית תמיד על טלפון אמיתי. אם אין לך אייפון, בקש מחבר עם אייפון לפתוח את הלינק ולשלוח צילום מסך.

באגים נפוצים של Safari שצריך לדעת

Safari (הדפדפן של Apple) הוא מקור לבאגים ייחודיים שלא קיימים ב-Chrome. הנה הנפוצים ביותר ואיך Claude מתקן אותם:

• 100vh Bug — ב-Safari מובייל, height: 100vh כולל את סרגל הכלים, כך שהתוכן "יוצא" מהמסך. הפתרון: height: 100dvh (dynamic viewport height).
• Safe Area Insets — אייפונים מודרניים עם "notch" (חריץ) צריכים env(safe-area-inset-top) כדי שתוכן לא יוסתר מאחורי ה-notch.
• Smooth Scrolling — Safari דורש -webkit-overflow-scrolling: touch ב-divs עם scroll.
• Input Zoom — אם font-size של input קטן מ-16px, Safari מגדיל אוטומטית. הפתרון: font-size: 16px מינימום לכל שדה קלט.

בקש מ-Claude: "Check and fix all Safari-specific CSS issues, including 100vh bug, safe area insets, and input zoom." — הוא מכיר את כל הבעיות האלה.

Claude Code כלים מתקדמים לבדיקת מובייל

Claude Code מציע כמה כלים מתקדמים שעוזרים לבדוק מובייל בלי לצאת מהטרמינל:

• Playwright MCP — אם מותקן, Claude יכול לפתוח את האתר שלך בדפדפן headless, לשנות גודל חלון ל-375px רוחב, לנווט בין עמודים, ללחוץ על כפתורים, ולצלם מסך. זה כמו בודק QA אוטומטי שרץ ישירות מ-Claude Code. בקש: "Open my site in Playwright at iPhone SE resolution, navigate through all pages, and report any layout issues."
• כלי Bash לבדיקות — Claude יכול להריץ Lighthouse, pa11y (לנגישות), ו-htmlhint ישירות מהטרמינל ולנתח את התוצאות. "Run an accessibility audit with pa11y on all pages and fix any issues" — ו-Claude ימצא ויתקן בעיות נגישות.
• /simplify — אחרי שסיימת לעבוד על רספונסיביות, הרץ /simplify. הפקודה הזו שולחת 3 סוכנים מקבילים שבודקים את הקוד שלך לשימוש חוזר, איכות, ויעילות — ומתקנים בעיות אוטומטית. מושלם אחרי Responsive Redesign גדול.
• WebFetch — Claude יכול לגשת לכלים אונליין כמו Google PageSpeed Insights דרך WebFetch ולקבל דו"ח ביצועים של האתר שלך בפרודקשן (לא רק localhost). "Check my live site at mysite.com with PageSpeed Insights and fix any mobile issues" — ו-Claude יבדוק ויתקן.

תרגילים מעשיים

צ'קליסט — סיכום פרק 7

• מבין/ה את ההבדל בין אתר רספונסיבי, PWA, ו-React Native ומתי להשתמש בכל אחד
• האתר שלך מותאם למובייל: Layout רספונסיבי, Touch Targets של 44px+, בלי גלילה אופקית
• יש Viewport Meta Tag: <meta name="viewport" content="width=device-width, initial-scale=1.0">
• תמונות רספונסיביות עם srcset ו-Lazy Loading
• טיפוגרפיה רספונסיבית עם clamp() או Media Queries
• הוספת manifest.json והפכת את האתר ל-PWA
• רשמת Service Worker עם אסטרטגיית Cache
• האתר עובד אופליין (לפחות התוכן הסטטי)
• בדקת על טלפון אמיתי (לא רק DevTools)
• ציון Lighthouse מעל 90 בכל 4 הקטגוריות
• מכיר/ה את Expo ואת תהליך בניית אפליקציית מובייל (גם אם לא בנית)
• מבין/ה מתי שיתוף קוד (Monorepo) שווה ומתי הוא מורכב מדי
• יש רשימת בדיקות Cross-Platform שאתה מריץ לפני כל Deploy
• מכיר/ה את Core Web Vitals (LCP, INP, CLS) ואיך לשפר אותם
• הוספת הוראות מובייל ל-CLAUDE.md של הפרויקט
• יודע/ת להשתמש ב-Plan Mode לתכנון Responsive Redesign