Understand the on-device model
App profiles, links, share fixtures, templates, scenarios, and redacted logs remain on the device. TestDock has no application account, sync service, analytics, advertising, or collaboration backend.
Network access occurs only for an explicit action such as fetching association data or sending a provider push. Share testing only invokes the operating system's share/open-in UI and cannot observe the receiving app.
Protect provider credentials
Target-app push tokens, optional Expo access tokens, APNs .p8 signing bundles, and Firebase service-account JSON use platform secure storage and are excluded from profile exports. Do not paste them into link parameters, notes, scenario evidence, or support reports.
TestDock generates short-lived APNs provider JWTs and Google OAuth access tokens in memory when sending; those generated tokens are not user-maintained or exported.
Troubleshoot deep links
Confirm the selected app profile, exact URL, parameter values, installed app build, platform identifiers, and associated-domain configuration. Separate operating-system acceptance from the destination actually rendered by the app.
For web links, inspect the exact host's AASA or assetlinks response and account for platform caching after deployment or entitlement changes.
Troubleshoot push delivery
Separate credential rejection, invalid target token, malformed payload, provider acceptance, device delivery, and app handling. They are distinct stages with different fixes.
Use the redacted log response and the target app's on-device behavior together; neither alone proves the entire path succeeded.
Prepare a safe support report
Record the TestDock version, device and operating-system version, selected provider or link type, visible error, and the smallest reproducible non-secret profile definition.
Never share secure-store values. Review ordinary notes and screenshots manually because free-form evidence can contain sensitive information even when structured profile exports omit secrets.