AppCompliance is designed around the artifact Apple or Google will receive.
Upload an IPA, APK or AAB through the dashboard, API or CLI.
AppCompliance examines the compiled application package, including its configuration, permissions, embedded components and platform-specific declarations.
Deterministic rules evaluate technically detectable properties against supported Apple and Google requirements.
Findings show what was detected, why it matters, which official requirement is relevant and what to review next.
Run the updated build again and confirm whether the technical finding has been resolved.
AppCompliance currently applies 137 supported static checks across iOS and Android.
The checks that apply depend on the platform and properties of the compiled application.
Packaging and signing: Check supported properties of the compiled package, embedded frameworks, architectures and signing-related configuration. Security configuration: Detect supported issues in application security settings, transport configuration and compiled application properties.
Privacy-related declarations: Check supported privacy manifests, usage descriptions and other technically detectable privacy declarations included in the build. Permissions: Review requested permissions and related configuration against supported platform requirements.
Embedded SDKs: Identify embedded third-party SDKs and flag supported technical or policy concerns associated with them.
Entitlements and capabilities: Validate supported iOS entitlements, Android capabilities and platform-specific configuration. Networking configuration: Review technically detectable networking configuration, endpoint indicators and transport settings. Static analysis does not observe actual production traffic. Platform and tooling requirements: Identify supported issues involving operating-system targets, build tooling and other submission-related technical requirements.
Apple and Google do not review your source repository.
They receive the compiled application package.
That package can contain platform-specific information that is not obvious from source code alone:
Analysing the final artifact gives your team evidence about the application prepared for submission.
It does not replace source-code analysis, functional testing or runtime testing. It answers a different question:
What does the compiled application itself show?
Every AppCompliance report is structured to help a technical team investigate and act.
Each finding can include:
Sample data for demonstration purposes.
Validation should be predictable.
Running the same compiled application twice should produce the same result.
AppCompliance therefore uses deterministic logic for supported pass-or-fail checks.
A finding is based on reproducible technical evidence from the binary.
Artificial intelligence does not decide whether a supported check passes or fails. AI may help explain a finding in clearer language, but the underlying result remains rule-based.
Every supported rule is connected to the relevant Apple or Google requirement.
The report shows which detected property caused the finding.
AppCompliance evaluates supported requirements that can be assessed objectively from a compiled IPA, APK or AAB.
A scan without unresolved findings means that no unresolved deviations were found within the supported static checks.
The interface can change.
Upload builds, inspect findings, compare scan results and review monitoring alerts.
Run static analysis from a local development or release workflow.
Connect AppCompliance to internal systems, developer portals and release tooling.
Analyse compiled artifacts automatically and use supported results as a release gate.
A completed scan creates a technical record that can be compared with future supported platform changes. AppCompliance monitoring follows relevant Apple and Google requirement updates and identifies relationships with previous scan results. The binary is not retained after the scan. Monitoring uses retained technical results.
Explore monitoring →The compiled package contains the platform-specific configuration and embedded components that reach the store-review process.
Source code remains useful for other forms of analysis, but it does not always represent the final submitted artifact.
No.
Only requirements that AppCompliance supports and can evaluate through deterministic static analysis are included.
Many guidelines depend on runtime behaviour, content, metadata, business context or human judgment.
AppCompliance is designed to base findings on reproducible technical evidence.
Some findings identify a condition that requires context rather than proving a policy violation. These are labelled accordingly so the team can review the evidence before deciding what to do.
Supported results can be integrated into CI/CD and used as release-gate criteria defined by your team.
The uploaded binary is deleted when analysis finishes.
Report data and technical scan results may be retained according to the data policy so users can review findings and use monitoring.
Run supported static checks on your next compiled iOS or Android release.
