Mobile Native Modules
Purpose
Plan native capabilities: evaluate existing community packages and Expo config plugins first, and design custom native modules (iOS/Android) only when no package fits.
When to Use
- When a feature needs a native capability not covered by JS.
- Not when a maintained package or config plugin already covers it.
Inputs
- The native capability needed.
- Runtime (Expo dev build vs CLI); existing native project (if any).
Discovery Questions
- Does a maintained community package or Expo config plugin already cover this?
- If not, what native APIs (iOS/Android) are required?
- Does this force CLI, or can an Expo dev build + config plugin work?
- Who maintains the custom module?
Responsibilities
- Evaluate existing packages/config plugins first.
- If custom is required, design the native module interface (iOS/Android) and JS bridge.
- Confirm whether an Expo dev build + config plugin suffices vs needing CLI (
mobile-stack-selection).
- Plan build/readiness impact (
mobile-builds, ios-readiness, android-readiness).
Required Workflow
- Define the native capability.
- Search for a package/config plugin.
- If none fits, design the custom module + bridge.
- Decide dev build vs CLI.
- Record the native plan + maintenance owner.
Decision Rules
- Prefer a maintained package or Expo config plugin over writing native code.
- A native need does not automatically mean CLI — Expo dev builds + config plugins cover many.
- Custom native modules add maintenance cost — justify and assign ownership.
- Keep the JS bridge surface minimal and typed.
Rules
- Don't write native code that a maintained package provides.
- Coordinate the runtime decision with
mobile-stack-selection.
- Plan for native build/readiness impact.
Anti-Patterns
- Writing a custom module for a solved problem.
- Ejecting to CLI for something a config plugin covers.
- Unmaintained custom native code with no owner.
- A sprawling, untyped bridge surface.
Validation Checklist
Definition of Done
A recorded native plan: existing-package evaluation, a justified custom module (if any) with a minimal typed bridge, a dev-build-vs-CLI decision, and planned build/readiness impact with an owner.
Related Skills
mobile-stack-selection, react-native-cli-foundation, expo-foundation, mobile-builds, ios-readiness, android-readiness
Related Knowledge
../../../knowledge/ (native capabilities, existing modules).
Related References
../../../references/mobile/native/ when populated.
Context Loading Guidance
- Requires: the native capability, runtime, existing native project.
- Does not require: unrelated screens, the full mobile skill set, unrelated references.
- May load:
mobile-stack-selection, mobile-builds, readiness skills.
- Stop when: the native plan is recorded.
Token Efficiency Guidance
Evaluate packages first from a short search; only design a module if none fits. Keep the bridge spec minimal.
1---2name: mobile-native-modules3description: Use to plan native module usage or authoring — evaluating existing packages/config plugins first, and planning custom native modules (iOS/Android) only when needed. Prefer Expo config plugins/dev builds before ejecting.4---56# Mobile Native Modules78## Purpose910Plan native capabilities: evaluate existing community packages and Expo config plugins first, and design custom native modules (iOS/Android) only when no package fits.1112## When to Use1314- When a feature needs a native capability not covered by JS.15- Not when a maintained package or config plugin already covers it.1617## Inputs1819- The native capability needed.20- Runtime (Expo dev build vs CLI); existing native project (if any).2122## Discovery Questions2324- Does a maintained community package or Expo config plugin already cover this?25- If not, what native APIs (iOS/Android) are required?26- Does this force CLI, or can an Expo dev build + config plugin work?27- Who maintains the custom module?2829## Responsibilities3031- **Evaluate existing packages/config plugins first**.32- If custom is required, design the **native module** interface (iOS/Android) and JS bridge.33- Confirm whether an **Expo dev build + config plugin** suffices vs needing **CLI** (`mobile-stack-selection`).34- Plan build/readiness impact (`mobile-builds`, `ios-readiness`, `android-readiness`).3536## Required Workflow37381. Define the native capability.392. Search for a package/config plugin.403. If none fits, design the custom module + bridge.414. Decide dev build vs CLI.425. Record the native plan + maintenance owner.4344## Decision Rules4546- Prefer a maintained package or Expo config plugin over writing native code.47- A native need does not automatically mean CLI — Expo dev builds + config plugins cover many.48- Custom native modules add maintenance cost — justify and assign ownership.49- Keep the JS bridge surface minimal and typed.5051## Rules5253- Don't write native code that a maintained package provides.54- Coordinate the runtime decision with `mobile-stack-selection`.55- Plan for native build/readiness impact.5657## Anti-Patterns5859- Writing a custom module for a solved problem.60- Ejecting to CLI for something a config plugin covers.61- Unmaintained custom native code with no owner.62- A sprawling, untyped bridge surface.6364## Validation Checklist6566- [ ] Existing packages/config plugins evaluated.67- [ ] Custom module designed only if needed.68- [ ] Dev build vs CLI decided.69- [ ] Build/readiness impact planned.70- [ ] Maintenance ownership assigned.7172## Definition of Done7374A recorded native plan: existing-package evaluation, a justified custom module (if any) with a minimal typed bridge, a dev-build-vs-CLI decision, and planned build/readiness impact with an owner.7576## Related Skills7778`mobile-stack-selection`, `react-native-cli-foundation`, `expo-foundation`, `mobile-builds`, `ios-readiness`, `android-readiness`7980## Related Knowledge8182`../../../knowledge/` (native capabilities, existing modules).8384## Related References8586`../../../references/mobile/native/` when populated.8788## Context Loading Guidance8990- **Requires:** the native capability, runtime, existing native project.91- **Does not require:** unrelated screens, the full mobile skill set, unrelated references.92- **May load:** `mobile-stack-selection`, `mobile-builds`, readiness skills.93- **Stop when:** the native plan is recorded.9495## Token Efficiency Guidance9697Evaluate packages first from a short search; only design a module if none fits. Keep the bridge spec minimal.
ahtishamshahzad