Define the feature as an API specification
A feature in a mobile app is a sequence of network calls plus the local logic that decides when to make them. Turning it into Python means reproducing that sequence with the same inputs and outputs. Write down the trigger, the inputs a user provides, the calls the app makes, and the result the user sees. That API specification is the target.
Bound the feature early. "Sync the order list" is workable. "The whole app" is not, and an unbounded goal hides the parts that depend on hardware or on a server-side computation you cannot reach.
Inventory the calls
Record traffic while you perform the feature once from a fresh start. Note the order of requests, because a feature usually depends on state that an earlier call established. A token from login, a cart identifier from a create call, or a pagination cursor from the previous page all have to exist before the next request is valid.
Log at the interceptor layer rather than at the socket, so you see the final bytes the app sends. Requests that look identical in the app's own log can differ in a header added last by an interceptor, and that header is often the one the server checks.
Reproduce the derived values
Some fields in a request are computed at send time: a timestamp, a nonce, a signature over the body, a device identifier, or a hash of the parameters. A Python client has to produce them the same way, which means finding the routine that computes each one and reimplementing it. Values that are genuinely static, such as an API key in string resources, can be copied. Values that change per call cannot.
Where the computation lives in native code, the options are to reimplement the algorithm or to extract the key material and rebuild the routine. Both are feasible, and the choice depends on how much of the logic is native and how the key is protected.
Model the session and the flow
Most features sit inside a session. Model the token lifecycle, cookie handling, any CSRF value, and the refresh call that keeps the session alive. Then model the feature itself as a small state machine: which call can follow which, what the client does on a retry, and which errors are recoverable.
- Refresh the token before it expires rather than after the first failure.
- Preserve cookies the way the app's cookie jar does, including their attributes.
- Send the same idempotency key on a retry of the same logical action.
- Follow pagination until the server stops returning a cursor.
- Treat a validation error as information and surface the server's message.
Verify against the running app
Compare your client's output with the app's, field by field, on the same inputs. Differences usually come from small things: a timestamp in seconds against milliseconds, a locale-formatted number, a default value the app sends and you omit, or a header the app adds to every request. A recorded response is a useful fixture for tests, and a diff between the recorded response and your result catches drift before it reaches production.
Run the feature end to end more than once, on different accounts or different states, so you exercise the branches. A client that works only on the happy path is not finished.
Package it so someone else can use it
Wrap the calls in a module with typed request and response models, a session object that owns credentials, retries with a bounded backoff, and structured logging that redacts tokens. Add a command-line entry point for the operations the team actually runs, and tests built from recorded traffic. Document the endpoints, the fields and the values the client computes, because the next person to touch it will not have your session history.
Some features do not translate. Calls backed by hardware attestation, a hardware keystore key, or a vendor service bound to a specific app identity may refuse traffic from anywhere else. Report that limit instead of working around it, because a client that only runs on a modified device is not the same deliverable.
Related work
Reviewed 28 September 2026 · SReverse research desk