The job to be done
How does TestDock help with multi-app device labs?
Keep unrelated schemes, domains, push tokens, payloads, and test histories separated by app profile on one testing device.
Testing stays close to the installed app. Open links or share/open-in flows through the operating system; inspect AASA and assetlinks configuration; validate and send through Expo Push, APNs, or FCM; and keep redacted results and scenario evidence on the device. TestDock has no account, sync service, analytics, or backend.
Recommended path
Create an app profile
Record the app name, current-platform identifier, URL schemes, and verified-link settings that define the installed target.
TestDock keeps the app profile, resolved link or push input, protected provider setup, scenario state, and redacted outcome together on the device where the check runs.
Capabilities involved
The parts of TestDock used here.
Related manual
Set up your first TestDock app profile
Create a persistent profile for an installed mobile app and record the schemes and platform metadata its tests depend on.
Its sections cover choose the app boundary, add the app identity, record every custom scheme, use profile readiness. Use it when you are ready to reproduce this workflow with your own project data.
Read the guideDirect answers
Questions about this use case.
How does TestDock help with multi-app device labs?
Keep unrelated schemes, domains, push tokens, payloads, and test histories separated by app profile on one testing device. The recommended path starts with create an app profile and uses persistent app profiles, deep-link workbench, reusable share inputs.
Does TestDock switch the environment of the app under test?
No. An external app controls its own configuration. TestDock models the app identity and stores the links, push setups, payloads, and scenarios you can actually exercise from the device.
Does TestDock require an account or backend?
No. It has no TestDock account, synchronization service, analytics, advertising, or collaboration backend.