See how AppCompliance turns technical evidence from a compiled application into a clear release-gate result.
The walkthrough shows:
1 minute 15 seconds · Captions available
$ appcompliance gate --build 3.2.1
BLOCK
exit code 1
2 findings must be resolved before this gate can pass.The application was analysed successfully.
The release gate did not pass because two confirmed findings meet the configured blocking conditions.
Every finding separates what was detected from the action your team needs to consider.
The compiled application references APIs that require declared reasons, but matching declarations were not found in its privacy manifest.
Required Reason API references were detected in the compiled binary.
No matching entries were found in PrivacyInfo.xcprivacy.
The analysed build does not meet the declaration requirement evaluated by this supported check.
AppCompliance therefore blocks the configured release gate.
Add an approved reason for each detected API to the application’s privacy manifest.
Review whether each API is called directly by the application or introduced through an embedded SDK.
Build the application again and run a new scan.
The finding clears when every detected API reference has a matching supported declaration.
The application configuration permits unrestricted non-secure network connections.
An App Transport Security configuration allowing arbitrary network loads was found in the compiled application.
Remove the unrestricted exception.
When an exception is technically necessary, restrict it to the smallest possible set of domains and document why it is required.
Build the application again and run a new scan.
The finding clears when the unrestricted exception is no longer present.
A string matching a supported credential pattern was found in the compiled application.
The detected value is withheld from the report.
The extracted string matches the structure of a supported third-party provider credential.
The pattern match is confirmed. AppCompliance cannot determine from the binary alone whether the value is active, expired or intentionally non-production.
Confirm whether the detected value is an active credential.
When it is active:
Build the application again and run a new scan.
The finding clears when the supported credential pattern is no longer detected.
An SDK version detected in the application is associated with a published medium-severity vulnerability.
The version match is confirmed.
The practical risk still depends on how the SDK is used, whether the affected functionality can be reached and which mitigations are already in place.
Review the published vulnerability and the SDK vendor’s release information.
Upgrade to a version without the known issue or document an accepted risk with the supporting reasoning.
The name of an embedded library resembles an entry associated with known tracking functionality.
AppCompliance could not confirm tracking behaviour from the available binary evidence.
A name match is a signal, not proof of behaviour.
AppCompliance does not block a release solely because a library name resembles a known tracker.
Confirm the identity and purpose of the embedded library.
Review whether its behaviour is reflected accurately in the application’s privacy declarations.
AppCompliance does not present every signal as a proven problem.
The technical condition described by the rule was detected in the compiled application.
This can include:
A confirmed detection can still require human judgment about its practical impact.
A signal may be relevant, but the binary does not provide enough evidence for a definitive conclusion.
This can include:
Indicative evidence does not block the release gate on its own.
A useful report should do more than tell your team that something may be wrong.
Every supported finding answers six questions.
The technical condition found in the compiled application.
The binary, configuration, manifest, entitlement or embedded component that produced the result.
Whether the technical condition is confirmed or remains indicative.
The relevant platform guideline or technical risk connected to the evidence.
The recommended investigation or remediation step.
The condition that must change before the finding clears on a new scan.
AppCompliance provides the technical evidence. Your team decides what happens next.
The report includes an inventory of supported embedded SDKs detected in the application.
| SDK | Detected version | Published vulnerability matches |
|---|---|---|
| Networking library | 4.9.0 | None detected |
| Analytics SDK | 2.4.1 | 1 medium |
| Crash reporting SDK | 8.1.2 | None detected |
When AppCompliance cannot determine a version with sufficient confidence, the report states that explicitly rather than estimating one.
Review the findings inside AppCompliance or send the result to the tools that already support your release process.
Use the gate result and exit code inside CI/CD and automated release workflows.
Send supported findings to compatible code-scanning and security tooling.
Export the supported software inventory as a software bill of materials.
Share a readable report with release owners, clients or other stakeholders.
This report shows the results of supported technical checks performed on the compiled application.
It helps your team identify:
AppCompliance does not:
A passing report means that no unresolved findings were detected within the supported checks and configured gate. It does not mean that every possible platform guideline has been evaluated.
Approval decisions remain with Apple and Google.
This is a sanitized demonstration report created to show the structure and level of detail returned by AppCompliance.
The application name and identifying information are fictional.
No.
Every report is based on evidence detected in the uploaded IPA, APK or AAB.
Your report only contains findings and inventory results relevant to your compiled application.
No.
AppCompliance analyses the compiled IPA, APK or AAB.
Source-code access is not required for the supported binary checks shown in this report.
No.
The uploaded build is deleted when the scan finishes.
The applicable processing and retention details are described in the AppCompliance data policy.
A blocked gate means that one or more findings meet the configured conditions for stopping the next automated release step.
Your team controls how the result is used inside its workflow.
No.
Findings are separated by the action they require and the strength of the available evidence.
A confirmed technical finding may block the configured gate. Other evidence may require review or be shown for information only.
No.
AppCompliance evaluates supported requirements that can be detected objectively from the compiled application.
Apple and Google may evaluate additional technical, runtime, metadata, content-based and subjective requirements.
They make the final approval decision.
Upload your compiled IPA, APK or AAB. Review the technical evidence. Resolve what needs attention. Run the scan again. Make the release decision with a clearer view of the application your team intends to submit. Join the waitlist and use AppCompliance on your own builds before the public launch.
One email when your invitation is ready. No spam, nothing else.