- Shopify Engineering describes Reflex, which lets one test file check both its native iOS and Android apps without a simulator or emulator.
- Shopify says it writes the code twice and the tests once, because agents make a second implementation cheap. Its timings are self-reported.
- Leaders can ask whether their own apps expose a clear contract that agents, and tests, can use.
Shopify argues that when agents write most of the code, a second version of an app stops being the costly part. The costly part, on this account, is proving the two versions behave the same. Shopify Engineering has described an architecture, called Reflex, that is built around that shift.
The bottleneck moved from writing to proving
Shopify's engineers describe a lopsided workflow. An agent drafts a new screen in a few minutes. Checking it then means starting an emulator, building the app and scripting taps, which Shopify sums up as needing "a lot of patience." The company says it invested in faster simulator tooling, but that approach stopped getting quicker.
Shopify is moving its apps back to native code: Swift on iOS and Kotlin on Android. Its reasoning is that agents now write most of the code, so building the same app a second time natively is much cheaper than before. That raises an obvious risk. Two codebases can drift apart.
Share the test, not the code
Shopify's answer is a principle it states plainly: the code is written twice, and the tests are written once. One test file runs against both platforms. The effect, as Shopify describes it, is that neither platform can release a feature while the other lags behind.
This is the idea worth taking away. The lesson here is that when code is cheap to produce, the shared test becomes the real specification. Shopify says that suite is now the shared source of truth between its two apps.
How Reflex works
Reflex has four parts. The first is a core module that holds the app's logic and contains no screen code, so it can run without a phone. The second is a strict pattern for each screen. Actions go in, state comes out, and there is one place where state changes.
The third part is a small layer that describes each screen as data. Each screen reports what it is called, what it currently holds, written as JSON (a plain text data format), and which actions it will accept. Think of it as a menu a screen hands to anyone who asks. The fourth part is a command-line tool that reads that menu and acts on it.
The tool has two main commands. One, called ls, prints the current screen, its state and its actions. The other, called do, runs one of those actions as a user would. Shopify says the tool talks only to this layer, never to the drawn interface.
What the tests do, and what they cost
Shopify calls its approach grey box testing. The test sees what the screen sees: state and actions. Underneath, it uses the real reducers, services, GraphQL client and navigation. Fixtures stand in only where the app would reach the network or the device. Shopify says the suite uses no mocking frameworks.
A guard blocks every HTTP request in the test process and fails the test if one is attempted. Shopify says this leaves the suite with no input/output and no flakiness. The price is that fixtures get large. Shopify notes that one user journey may need a dozen canned GraphQL responses (the app's data requests). Maintaining those by hand would be a chore for a person, but Shopify says an agent handles it well.
On speed, Shopify says a test runs in a couple of hundred milliseconds with no device, on both platforms. The same test takes around two seconds on an iOS simulator. Shopify adds that, run headlessly on CI, its suite completes thousands of tests within minutes. These are Shopify's own figures, and the post gives no independent measurement.
The limits Shopify names
These tests check logic, not pixels. Shopify says visual review against its reference app happens at every checkpoint in its separate Helix process. It also keeps screenshot tests for a few components where pixels matter.
Shopify also notes that it owns its codebase, which let it build this interface. Teams with apps they cannot change that way may face a different choice. Shopify has not released a library. It says its code is tied to its own session model and navigators, and that a capable coding agent can build the idea from the post.
One surface for tests and assistants
Shopify says the same state-and-actions surface also lets Sidekick, its AI assistant, act inside the app. It says there is no separate integration layer. The socket server that connects the tool to a running app is compiled out of release builds.
What to ask your team
This is one company's account, but the questions travel. Who owns the single test that defines correct behaviour across your platforms? How long does your suite take, and how much of that is waiting on devices? Do your apps describe their own state and actions in a form an agent can read? If the answer to the last question is no, an agent has to infer state from screenshots or the accessibility tree.
The lesson here is that cheap code moves the value to the contract. Write the code twice if you must, but write the proof once.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Shopify Engineering.
