Device Integration

Purpose

Design the integration strategy for device hardware APIs (camera, sensors, biometrics, Bluetooth, etc.), including permission flows, fallback behavior, and cross-platform abstraction.

Inputs

• •Feature requirements involving hardware capabilities
• •Target platforms and OS version minimums
• •Cross-platform framework (if applicable)
• •Privacy requirements and data sensitivity

Process

Step 1: Inventory Required Capabilities

List every hardware API the feature needs:

• •Camera (photo, video, barcode scanning)
• •Location (GPS, network-based, background location)
• •Biometrics (Face ID, Touch ID, fingerprint, device PIN fallback)
• •Bluetooth (BLE scanning, pairing, data transfer)
• •Sensors (accelerometer, gyroscope, compass, barometer)
• •Push notifications (remote, local, rich notifications)
• •Haptics (impact, selection, notification feedback)
• •Other (NFC, ARKit/ARCore, HealthKit)

Step 2: Map Permission Requirements

For each capability, document:

• •iOS permission: NSCameraUsageDescription, NSLocationWhenInUseUsageDescription, etc.
• •Android permission: CAMERA, ACCESS_FINE_LOCATION, USE_BIOMETRIC, etc.
• •Runtime vs install-time: Which permissions need runtime prompts
• •Purpose strings: User-facing explanation for each permission
• •Privacy manifest entries: (iOS 17+ privacy manifest requirements)

Step 3: Design Permission Flow

For each permission:

• •Pre-prompt education: Explain why the permission is needed before the system dialog
• •First request timing: When in the user flow to request (not on launch — at the moment of need)
• •Denial handling: What the feature does if permission is denied
• •Settings redirect: How to guide the user to Settings if they denied and changed their mind
• •Partial permission: Handle "While Using" vs "Always" for location, "Limited" for photos

Step 4: Evaluate Cross-Platform Abstraction

If using a cross-platform framework:

• •Identify which APIs have mature cross-platform libraries
• •Flag which capabilities require native modules or platform-specific code
• •Assess abstraction quality (does the library expose all platform-specific options?)
• •Plan for platform differences (Face ID vs fingerprint, iOS haptics vs Android vibration)

Step 5: Design Fallback Behavior

For each capability, define behavior when:

• •Hardware is absent (no NFC chip, no biometric sensor)
• •Permission is denied (camera denied, location denied)
• •Hardware fails (GPS can't get a fix, Bluetooth disconnects)
• •OS version doesn't support the API

Step 6: Power and Performance Impact

Assess battery and performance cost:

• •Background location tracking power draw
• •Continuous sensor polling vs event-driven
• •Bluetooth scanning intervals and power modes
• •Camera session lifecycle management

Output Format

# Device Integration Plan

## Capability Matrix
| Capability | iOS | Android | Cross-Platform Library | Native Required |
|-----------|-----|---------|----------------------|-----------------|
| Camera    | Yes | Yes     | expo-camera          | No              |
| BLE       | Yes | Yes     | react-native-ble-plx | No              |
| Face ID   | Yes | N/A     | expo-local-auth      | Partial         |

## Permission Map
| Capability | iOS Permission | Android Permission | Timing | Purpose String |
|-----------|---------------|-------------------|--------|----------------|
| Camera    | NSCameraUsageDescription | CAMERA | On first scan | "Scan barcodes..." |

## Permission Flow
### [Capability Name]
1. User taps [action]
2. Show education screen: "[Why we need this]"
3. System permission dialog
4. If granted: [proceed]
5. If denied: [fallback behavior]
6. If denied permanently: [settings redirect with instructions]

## Fallback Matrix
| Capability | Hardware Absent | Permission Denied | Hardware Failure |
|-----------|----------------|-------------------|-----------------|
| Camera    | [Fallback]     | [Fallback]        | [Fallback]      |

## Power Impact
| Capability | Active Draw | Mitigation |
|-----------|------------|------------|
| GPS       | ~50mA      | Use significant-change monitoring |

Quality Checks

• • Every required permission has a user-facing purpose string
• • Permission requests happen at moment of need, not on app launch
• • Every capability has fallback behavior for denial, absence, and failure
• • Cross-platform libraries are evaluated for API completeness
• • Power impact is assessed for continuous-use capabilities
• • iOS privacy manifest requirements are addressed (iOS 17+)
• • Android runtime vs install-time permissions are correctly categorized

Evolution Notes