How it works

A technical walkthrough of Replicate's architecture, what data it accesses, and what it never touches.

Architecture overview #

Replicate has two components that work together:

1. The macOS app — runs on your Mac, manages snapshots, and controls simulator sessions via xcrun simctl.
2. The interceptor package — installed in your iOS Simulator app (Flutter or React Native), runs inside the simulator process.

Here is the complete flow during a recording session:

1. You hit Record in Replicate on your Mac.
2. Replicate writes a session config file (replicate_session.json) into the simulator app's Documents directory using xcrun simctl.
3. Replicate launches your app via xcrun simctl launch.
4. On startup, the interceptor package reads the session config and activates recording mode.
5. Every HTTP request and response is intercepted inside the simulator process and written as a JSON file to the simulator's sandboxed Documents/replicate_tape/ directory. Nothing leaves the simulator.
6. When you hit Stop, Replicate reads the tape files from the simulator container via xcrun simctl, copies your app's container directory, optionally dumps keychain entries, and packages everything into a .replica file on your Mac.
7. Replicate never connects to the internet to perform any of this. It is entirely local.

What Replicate collects #

The following data is captured locally, on your machine only. It is stored in a .replica file that never leaves your Mac unless you explicitly share it:

• App container files — your app's data directory in the simulator (Documents, Application Support, Caches, Preferences, etc.)
• Network tape — HTTP request and response bodies, headers, status codes, and timing from your recording session
• Keychain entries — entries from flutter_secure_storage (Flutter) or react-native-keychain (React Native), so auth state is preserved across restores

What Replicate never does #

• Never sends your network tape, request bodies, response bodies, API keys, tokens, or any app data to Replicate's servers
• Never uploads your .replica files anywhere — they stay on your machine unless you explicitly share them
• Never has access to your .replica files after they leave your machine — when you share one with a teammate it goes directly from your machine to theirs
• Never connects to Replicate's servers except for two things: licence validation and update checks (see below)

What licence validation sends #

When Replicate validates your licence it sends exactly two pieces of data to Replicate's servers:

• Your email address — to look up your account
• A device hardware UUID — a number that identifies your Mac, not you personally. This is used to enforce single-device licensing and prevent account sharing.

It never sends your snapshots, your network tape, or any data from your app.

What update checks send #

Replicate uses Sparkle for automatic updates. Sparkle checks for updates by fetching a public XML file from GitHub. It sends your current app version number. That is all.

How the Flutter interceptor works #

• Overrides Dart's HttpClient via HttpOverrides.global, and wraps http.Client and Dio
• Runs entirely inside the simulator process — no proxy, no system network changes
• Writes tape files to <AppContainer>/Documents/replicate_tape/
• Reads a session config from <AppContainer>/Documents/replicate_session.json
• No certificate installation required
• Is a no-op in release builds — zero impact on production apps

How the React Native interceptor works #

• Patches global.XMLHttpRequest before the app initialises
• Covers fetch, axios, and any XHR-based library automatically — no per-library configuration needed
• Uses the same file paths and tape JSON format as the Flutter package
• No proxy, no certificate installation, no system network changes
• Is a no-op in release builds — zero impact on production apps