Parive
Public preview · open July 13, 2026

Your iOS and Android apps have drifted. Parive shows you exactly where, and when.

Parive reads both native codebases and lines them up: every screen, feature, and behavior, aligned concept by concept, with a severity on each difference. It's running on Wikipedia's apps right now. No signup, real code, real analysis.

The differences summary on the public preview: the features of Wikipedia's two apps have 8 significant differences — 1 intentional, 7 long-standing — with the top easy-to-miss findings, untouched for 6, 5, and 3 years

The preview analyzes wikipedia-ios and apps-android-wikipedia: two excellent apps that Wikimedia's teams build in the open. Their openness is what makes a public preview on real code possible, and we're grateful for it. They're not affiliated with Parive.

The comparison

Today, no one knows all the gaps. Parive does, on day one.

Every product built twice has differences. Most are platform conventions or intentional divergence. The dangerous ones are neither, and they surface as bug reports, support tickets, and "why does Android do that?"

Parive aligns both apps concept by concept: present here, different there, missing on one side. Each difference gets a severity, ranked with evidence from your commit history and connected tools. When one needs a closer look, an agent investigates it across both codebases and reports back with receipts.

Feature comparison table from the public preview: the eight significant differences between Wikipedia's iOS and Android apps, each with a comparison status, estimated value, investigation verdict, and date of last significant change
Screen documentation from the public preview: the Article reading screen concept, with its full definition and a difference status of none — the platforms are in parity
The documentation

A picture of what each app actually does, not what everyone remembers it doing.

The comparison stands on a full inventory of both codebases: screens, features, a domain dictionary, user stories, each one traceable back to source. It reads like product documentation your team would have written with unlimited time.

And it will stay current on its own. When new features land, Parive will re-analyze what they touched and update the affected documentation. Freshness won't be anyone's job.

Feature map from the public preview: 210 features clustered by product area, from Editing & Contributions (41) down to Shared UI (1), each dot colored by difference severity and sized by estimated value
The workflow

From difference to merged fix.

Pick a difference worth closing. Build the plan with a planning agent in a shared document, edit the same text together, approve it when it's right. An implementation agent writes the code and tests on the lagging platform and runs them until they pass. The result comes back as reviewable work: a plan you approved, a diff you can read, tests that prove behavior parity.

Prefer your own team or tools? Assign the approved plan to an engineer, or reach everything over the API.

01 · Difference

Pick the gap

Start from a ranked difference with its evidence attached: where it lives in each codebase, and what it costs users.

02 · Plan

Agree the fix

You and the planning agent edit the same plan document. Nothing runs until you approve it.

03 · Review

Reviewable work

Code and tests on the lagging platform, run until they pass, linked back to the difference and the plan.

The plan workspace from the public preview: an executed implementation plan closing the Article search gap on iOS — the approved plan of record beside the agent's activity log, with a View PR link

The planning and implementation agents run in private demos today. Ask us and we'll show you, on your apps.

Where this goes

One source of truth for the product you built twice.

Documentation, tests, and domain language that are maintained, reviewed, and trusted. Your issue tracker, CI, and every agent your team runs ask Parive instead of digging through code and wasting time and tokens. The apps stop drifting because the thing they are both derived from is kept true. Porting a feature stops being a project and becomes a task you assign.

Design partners

We're looking for ten teams.

You have native iOS and Android in production. We'll run Parive's analysis on your codebases, walk the results with you, and get your feedback to shape the product. You work directly with the founding team, in your Slack, on your priorities.

A founder replies within a day. Or just explore the preview first.

Thanks — a founder will reply within a day.

In the meantime, explore the preview.