The Simulator accelerates development but does not represent every hardware and security condition of a physical device. Protection acceptance must state the test environment's limits.
Evaluation approach
Test key operations, platform attestation and device-dependent controls separately on real hardware. Define expected behavior for unsupported features.
Application example
After a successful Simulator launch, run the application with its distribution signature on a physical device and verify critical enrollment.
Limits and considerations
A control failing in the Simulator does not always indicate a production defect. The reverse also holds.
Which question does a Simulator result answer?
The Simulator supports quick UI and application-flow testing. It is not equivalent to real hardware for hardware-backed features, signing conditions or device integrity. A security feature unavailable there should not immediately be classified as a product defect.
Separate Simulator-suitable tasks from those requiring physical devices. Explicitly record unsupported checks. The final release decision needs evidence covering critical flows of the distributed application on actual hardware.
Checks and decisions
- Label test types
- Include real devices
- Distinguish unsupported results
Verify critical platform evidence and key operations on physical devices.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.