Native Modules ו-Bridging | בית הספר של Claude

למה Native Modules חשובים יותר מתמיד, ב-2025

ב-אוקטובר 2025 Anthropic, לא, Meta, שחררה את React Native 0.82. ההכרזה הייתה חד-משמעית: ה-Legacy Architecture הוסרה לחלוטין. newArchEnabled=false פשוט לא עושה כלום יותר. כל מי שכותב Native Module היום כותב TurboModules עם JSI, אין ברירה אחרת.

זה אומר שאם אתם מסתמכים על מדריכים ישנים שמדברים על RCTBridgeModule ו-JSON serialization דרך Bridge, אתם לומדים ארכיטקטורה שכבר לא קיימת. שיעור זה מלמד את הדרך הנכונה: TurboModules, JSI, וכן, גם Nitro Modules שמגיחות כאלטרנטיבה מהירה פי 15 לספריות ביצועיות.

דוגמה קונקרטית: סטארטאפ מ-תל אביב בתחום הפינטק בנה module לסריקת מסמכים עם OCR. ב-Old Architecture הסריקה לקחה 2.2 שניות בממוצע, המשתמש ראה UI קפוא. עם TurboModule שמריץ ML inference ב-native thread ומחזיר תוצאה ישירות ל-JavaScript דרך JSI, הזמן ירד ל-180ms. אותה חבילת לוגיקה, שינוי ארכיטקטורה בלבד.

מתי בכלל צריך Native Module?

לפני שכותבים שורת קוד native, בדקו שאין ספרייה קיימת. ב-npm יש עשרות אלפי packages ל-React Native, ורוב ה-use cases מכוסים. Native Module שווה את ה-effort רק כשעומדים בפני אחת מהסיטואציות הבאות:

SDK שאין לו RN wrapper: SDK של בנק ישראלי, ספק biometrics proprietary, מצלמה תעשייתית עם SDK מותאם.
Performance critical: Image processing, ML inference, crypto operations, כשJS thread פשוט לא מהיר מספיק.
Background tasks: כשה-JS thread לא יכול לרוץ, audio processing ברקע, location tracking רציף.
Hardware access ספציפי: NFC, BLE, barcode scanner חומרתי, sensors לא סטנדרטיים.

סיטואציה	הפתרון
SDK קיים מה-vendor	בדקו npm קודם, כנראה יש wrapper
Performance bottleneck ב-JS	TurboModule ב-native thread
Image/audio processing	שקלו Nitro Modules (15x מהיר)
Background + timing critical	Native Module + proper threading

ארכיטקטורת TurboModules, מה שונה מה-Bridge הישן

ה-Old Architecture עבדה כך: JavaScript קרא לנייטיב, הבקשה עברה serialization ל-JSON, עוברת Queue, מגיעה ל-native thread, מתבצעת, חוזרת ל-JS דרך event, הכל async, הכל עם overhead של serialization. JSI (JavaScript Interface) מחליף את כל זה: JavaScript מחזיק reference ישיר לאובייקט native, יכול לקרוא לו synchronously, ללא serialization. התוצאה בפועל: cold start מהיר ב-43%, rendering מהיר ב-39%, memory נמוך ב-26%.

TurboModule מורכב מארבעה חלקים:

TypeScript Spec file, מגדיר את ה-API. חייב prefix Native בשם הקובץ.
codegenConfig ב-package.json, Codegen יודע מאיפה לקרוא את ה-spec.
Native implementation, Swift/Kotlin שמממשים את ה-spec.
Registration, הוספת המודול ל-app packages.

כתוב native module לביומטריקה

Write a complete React Native TurboModule (New Architecture) for biometric authentication. Module name: NativeBiometric (prefix Native is mandatory for Codegen). TypeScript spec must declare: - isBiometricAvailable(): Promise returning { available: boolean, biometryType: string | null } - authenticate(reason: string): Promise returning { success: boolean, error: string | null } - getBiometricType(): synchronous string (JSI allows sync) iOS: LocalAuthentication framework, Swift, handle FaceID + TouchID. Android: BiometricManager + BiometricPrompt API 28+, Kotlin, MUST call prompt.authenticate() on UI thread via activity.runOnUiThread. Handle Android case where currentActivity is null, reject Promise with clear error. Include: spec file, iOS Swift impl, Android Kotlin impl, codegenConfig for package.json, usage example in TypeScript.

שתי הטעויות שגורמות לשעות של debug

מפתחים ב-r/reactnative מדווחים שוב ושוב על אותן שתי בעיות:

טעות 1, Codegen drift: שיניתם את ה-TypeScript spec אבל לא הרצתם Codegen מחדש ולא עשיתם clean build. ה-crash שתקבלו יהיה מסתורי לחלוטין, שום רמז שה-spec לא תואם. הכלל: כל שינוי ב-spec = cd ios && pod install ב-iOS ו-clean build ב-Android. בלי יוצאים מן הכלל.

טעות 2, Promise שלא נסגרת: אם יש if/else בקוד ה-native ואחד מהם לא קורא ל-resolve() או reject(), ה-JavaScript Promise תישאר pending לנצח. ה-app לא יקרוס, הוא פשוט יקפא. בדקו כל code path ב-native code שמסתיים בקריאה לאחד מהם, אפשר לבקש מ-Claude לסרוק את הקוד ולמצוא paths שלא מסתיימים בresolve/reject.

טעות בונוס ל-Android: currentActivity יכול להיות null כאשר ה-Activity ב-background. תמיד null-check לפני שימוש ב-FragmentActivity, ו-reject Promise עם הודעה ברורה.

Nitro Modules, מתי לשדרג

Nitro Modules מ-Margelo (mrousavy) הן ארכיטקטורה של native modules שמבוססת JSI עם C++ core. הנתונים מה-benchmarks: ב-iPhone 15 Pro, Nitro Modules מהירות פי 15 מ-TurboModules לפונקציות פשוטות, פי 5 לstring operations. היתרון הגדול נוסף: תמיכה ישירה ב-Swift ו-Kotlin ללא ObjC bindings. Hybrid Objects, בניגוד ל-TurboModules שהם singletons, Nitro Modules יוצרים אובייקטים שאפשר ליצור, להעביר ולמחוק.

מתי Nitro Modules שווים את ה-complexity הנוסף? כאשר כותבים ספרייה open-source לשימוש נרחב, כאשר עוסקים ב-image processing, real-time audio, או ML inference. לרוב ה-modules הרגילים, גישה ל-SDK, biometrics, storage, TurboModules מספיקים לחלוטין.

Old Architecture כתובה ב-ObjC, JSI כתובה ב-Swift

Old Bridge: JSON serialization + async queue. JSI: reference ישיר מ-JavaScript לnative, קריאות sync, ללא serialization

JSI עובד רק עם Android, לא iOS

Old Architecture תמכה ב-iOS בלבד

איך Claude עוזר בכתיבת Native Modules

Native Modules הם מהתחומים שבהם Claude מוסיף ערך אמיתי, הסיבה: צריך לכתוב קוד בשלוש שפות (TypeScript, Swift, Kotlin) שצריכות להיות מסונכרנות. טעות בסוג באחת מהן גורמת לבאג קשה לדיבג. Claude יכול לכתוב את כל השלושה בבת אחת ולוודא עקביות.

שלושה prompts עיקריים לעבוד עם Claude על Native Modules:

יצירה מלאה: תנו ל-Claude את ה-use case המדויק, שם המודול, פרמטרים ו-return types. בקשו spec + שתי implementations + codegenConfig.
Debug: הדביקו את ה-error message, ציינו RN version, האם New Architecture, ומה כבר בדקתם. בקשו step-by-step debug procedure.
Code review: בקשו מ-Claude לסרוק את ה-native code ולמצוא code paths שלא קוראים ל-resolve() או reject().

נקודות מפתח

React Native 0.82, Legacy Architecture הוסרה לחלוטין. כותבים TurboModules בלבד.
שם ה-spec file ושם המודול חייבים prefix Native, Codegen לא יעבוד בלי זה.
כל שינוי ב-spec = Codegen מחדש + clean build. אין קיצורי דרך.
Android BiometricPrompt חייב לרוץ על UI thread, activity.runOnUiThread {}.
בדקו כל code path ב-native, כולם חייבים לסיים ב-resolve() או reject().
Nitro Modules: עבור ספריות ביצועיות (image, audio, ML), 15x מהיר. לרוב המקרים, TurboModules מספיקים.