- • Each protected screen or container your team intends to market or rely on.
- • At least one real device for every major iOS version family you support.
- • Foreground interaction, app-switcher exposure, background transitions, and capture-related states relevant to your product.
- • Successful activation and at least one intentional failure case so degraded behavior is known in advance.
ShiftOne ScreenVeil Web
Validate ScreenVeil before you sign off
The point is not to prove abstract perfection. It is to verify the app surfaces, devices, and state transitions your own deployment actually depends on.
Minimum validation scope
Recommended execution order
1. Confirm licensed activation
Begin by checking that the build activates correctly with the intended license and Bundle ID.
2. Test normal user flow
Make sure the protected screen remains usable in the app’s everyday interaction path.
3. Test state changes
Exercise app switching, backgrounding, return-to-foreground flow, and any capture-related visibility states your product plans to react to.
4. Record observations clearly
Capture the device, OS version, screen name, chosen protection style, and the exact state where behavior matched or diverged from expectations.
What should trigger re-validation
App-side changes
Navigation rewrites, view hierarchy changes, new presentation patterns, or new sensitive surfaces should trigger another validation pass.
Release changes
Major iOS updates, SDK updates, or production license changes should all be treated as reasons to re-check the protected experience.
Support signals
If QA, support, or customers report a surprising exposure case, re-validate the full affected flow rather than only the one reported screen.
Sign-off questions
- • Did we test the exact screens we intend to describe as protected?
- • Did we test on the OS and device mix that matters to our deployment?
- • Can support or operations explain the degraded behavior if activation fails?
- • Did we review the limitations language so nobody overstates what the rollout guarantees?
SDK runtime validation flow
Each step that runs when sv_enableProtectionWithLicenseJSON:configuration:error: is called, with the error code returned if that step fails.
1. Parse JSON payload
Malformed JSON or missing required fields → SVLicenseErrorMalformedPayload (1000) / SVLicenseErrorMissingRequiredField (1001)
2. Verify bundle identifier
License bundle_id must match your app → SVLicenseErrorBundleIdentifierMismatch (1002)
3. Check valid_from
License not yet active → SVLicenseErrorNotYetValid (1004)
4. Check expires_at
License past expiry → SVLicenseErrorExpired (1003)
5. Evaluate revocation policy
Revocation check required but not satisfied → SVLicenseErrorRevoked (1006) / SVLicenseErrorRevocationCheckRequired (1007)
6. Confirm signature metadata
Algorithm, key ID, or signature data missing → SVLicenseErrorMissingRequiredField (1001)
7. Verify cryptographic signature
Signature mismatch → SVLicenseErrorInvalidSignature (1008) / SVLicenseErrorUnknownKeyIdentifier (1009)
8. Allow activation
All checks passed — protection can be applied to the view.
Related manuals
These manuals work best when read as part of the full rollout path, not in isolation.
Getting started
Use the rollout order that leads into validation cleanly.
Open manualProtection styles
Validate the actual style choices planned for production.
Open manualLimitations
Set expectations before final sign-off.
Open manual