> ## Documentation Index
> Fetch the complete documentation index at: https://docs.gorules.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Mobile Rules Engine

> Deploy business rules to mobile applications for offline-capable evaluation.

The ZEN Engine runs natively on mobile devices, enabling offline rule evaluation without network round-trips.

## Why mobile rules?

**Offline evaluation.** Rules execute locally on the device, working without network connectivity.

**Low latency.** No network round-trips means instant evaluation, critical for responsive UX.

**Reduced server load.** Offload rule evaluation to client devices, reducing backend infrastructure costs.

**Privacy.** Sensitive data never leaves the device when rules are evaluated locally.

## Architecture patterns

### Bundled decisions

Ship decision files with your app bundle. Best for rules that change infrequently.

<Tree>
  <Tree.Folder name="App Bundle" defaultOpen>
    <Tree.Folder name="assets" defaultOpen>
      <Tree.Folder name="rules" defaultOpen>
        <Tree.File name="pricing.json" />

        <Tree.File name="eligibility.json" />
      </Tree.Folder>
    </Tree.Folder>
  </Tree.Folder>
</Tree>

**Pros:** Always available, no network dependency, fastest startup.

**Cons:** Requires app update to change rules.

### Remote decisions with caching

Fetch decisions from a remote source and cache locally. Best for rules that update periodically.

```mermaid theme={null}
flowchart LR
    A[App Start] --> B[Cache<br />Local]
    B --> C[Remote Source]
    B --> D[Evaluate Locally]
```

**Pros:** Rules can be updated without app releases, offline fallback.

**Cons:** More complex, requires cache invalidation strategy.

### Firebase Remote Config

Use Firebase to distribute decision files across your mobile fleet.

```mermaid theme={null}
flowchart LR
    A[BRMS Publish] --> B[Firebase<br />Remote Config] --> C[Mobile App]
```

**Setup:**

1. Export decision JSON from BRMS
2. Upload to Firebase Remote Config as a string parameter
3. Fetch and cache on app startup
4. Evaluate locally using the SDK

**Benefits:**

* Gradual rollouts and A/B testing
* Instant updates without app store review
* Built-in caching and offline support
* Analytics integration

### Cloud Storage distribution

Store decisions in cloud storage (S3, GCS, Azure Blob) and sync to devices.

**Setup:**

1. Configure BRMS to publish to cloud storage
2. Mobile app checks for updates on startup or periodically
3. Download and cache new versions locally
4. Evaluate using cached decisions

## Offline-first patterns

### Cache-first strategy

Always evaluate using cached decisions, update cache in background.

```mermaid theme={null}
flowchart LR
    subgraph Foreground
        A[App Starts] --> B[Load from Cache] --> C[Ready to Evaluate]
    end
    subgraph Background
        D[Check for Updates] --> E[Download if Newer]
    end
```

### Version checking

Include version metadata to minimize unnecessary downloads.

```json theme={null}
{
  "version": "1.2.3",
  "updated": "2024-01-15T10:30:00Z",
  "decisions": ["pricing.json", "eligibility.json"]
}
```

Check version before downloading full decision files.

### Fallback hierarchy

```mermaid theme={null}
flowchart TD
    A[Try Remote Decision] -->|Fail| B[Use Cached Decision]
    B -->|Fail| C[Use Bundled Decision]
    A -->|Success| D[Evaluate]
    B -->|Success| D
    C --> D
```

## Platform SDKs

<CardGroup cols={2}>
  <Card title="Android" icon="android" href="/developers/sdks/android">
    Native Android SDK with Kotlin coroutines support
  </Card>

  <Card title="iOS" icon="apple" href="/developers/sdks/ios">
    Native iOS SDK (closed beta)
  </Card>
</CardGroup>

## Best practices

**Bundle a fallback.** Always include a bundled decision as fallback for first launch or network failures.

**Cache aggressively.** Decision files are typically small; cache them persistently rather than in memory only.

**Version your decisions.** Include version metadata to enable efficient cache invalidation.

**Handle errors gracefully.** Network failures are common on mobile; design for offline-first.

**Test offline scenarios.** Simulate airplane mode and poor connectivity during development.