Why Checking Compliance Only Before Release Is Too Late

Automating Compliance Checks in Your CI/CD Pipeline

You don't find out about compliance issues when you're deploying to production. You find out when Apple or Google tells you something is wrong. By then, your release is blocked and your team scrambles to fix it under pressure.

The fix isn't better QA. It's earlier detection. Compliance checks belong in CI/CD, right next to your unit tests and linting.

Why should compliance checks run in your CI/CD pipeline?

Compliance checks belong in CI/CD because the highest-impact violations are binary-level facts that can be detected automatically from the build artifact, before submission. Most teams treat compliance as a pre-submission activity. Someone checks the binary manually, reviews the privacy declarations, and hopes nothing slipped through.

This works until it doesn't.

Common failure scenarios:

• a new SDK is added that collects device identifiers
• a dependency update bundles a commercial font
• the Android target API level falls below the current requirement
• a privacy manifest entry is missing after a framework swap

All of these are detectable before submission. None of them require human judgment. They're binary-level facts.

If you can automate linting and test execution, you can automate compliance scanning.

What compliance signals can you check at build time?

Not every compliance signal can be verified in CI. But the highest-impact ones can.

Privacy manifest coverage (iOS)

After building your IPA, verify that every required reason API has a corresponding entry in a PrivacyInfo.xcprivacy file. This covers both your own code and embedded frameworks.

Apple actively rejects apps that lack the required entries, so a missing declaration is a submission blocker.

Target API level (Android)

Your APK or AAB has a targetSdkVersion embedded in its manifest. Google requires this to meet a minimum threshold that increases regularly.

Checking this in CI catches the issue before you upload to Play Console, not after.

Embedded SDK inventory

The SDKs in your compiled binary aren't always the ones in your lockfile. Transitive dependencies, bundled resources, and build-time code generation all contribute.

Scanning the binary gives you the real picture.

Font and asset licensing

Commercial fonts embedded in binaries are a licensing issue that's hard to catch at source level. Many SDKs bundle fonts you didn't choose. Binary analysis surfaces these.

Deprecated API usage

Both platforms regularly deprecate APIs and set deadlines for removal. Detecting usage in the compiled binary catches cases that source-level analysis misses, especially in precompiled frameworks.

What are the common pipeline integration patterns?

Post-build step

The most common pattern: build the IPA, APK, or AAB first, then run the compliance scan as a separate step.

# GitHub Actions example
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build APK
        run: ./gradlew assembleRelease
      - name: Compliance scan
        run: |
          curl -X POST https://api.appcompliance.io/v1/scans \
            -H "Authorization: Bearer ${{ secrets.AC_API_KEY }}" \
            -F "file=@app/build/outputs/apk/release/app-release.apk"

This approach works for any CI system. The scan runs against the same artifact you'd submit to the store.

Gate vs notify

Two strategies for handling scan results:

Gate: fail the pipeline if critical findings exist. This blocks the release until issues are resolved. Works well for teams with established compliance processes.

Notify: report findings without blocking. Post results to Slack, create tickets, or add a PR comment. Better for teams adopting compliance checks gradually.

Most teams start with notify and move to gate once they've resolved the initial backlog.

Strategy	When Pipeline Fails	Best For	Tradeoff
Gate (block)	Critical/high severity findings	Release branches, production builds	Slower releases, higher confidence
Notify (warn)	Never, reports only	Feature branches, early development	Fast feedback, risk of ignoring
Hybrid	Critical only blocks, rest warns	Most teams	Balanced, requires severity tuning

Branch strategy

Running compliance scans on every commit is usually excessive. The binary doesn't change on every code push.

Recommended triggers:

• release branches
• tags
• manual dispatch for ad-hoc checks
• merge to main (if you build artifacts there)

This keeps scan volume manageable without missing issues.

What can't CI/CD catch?

Automated binary scanning covers a lot, but not everything.

Store compliance also includes:

• screenshot and metadata accuracy
• content policy adherence
• behavioral guidelines (how the app functions at runtime)
• design and UX requirements specific to each platform

These require human review. The point of CI integration isn't to replace manual review entirely. It's to eliminate the category of issues that are objective, binary-level facts.

Handling findings in your workflow

Compliance findings are similar to security vulnerabilities. You need a workflow for triaging and resolving them.

A practical approach:

1. Scan results produce a list of findings with severity levels
2. Critical findings block the release (or get escalated immediately)
3. Medium findings are reviewed in the current sprint
4. Low findings are tracked and addressed in regular maintenance

The key is treating compliance findings as first-class work items, not as an afterthought during release week.

Common mistakes

Scanning source instead of binary

Source code analysis is valuable, but it misses what matters most for store compliance. The stores evaluate your compiled artifact. Your CI should too.

Running scans too late

If your first compliance check happens in a release branch, you've already done the work that caused the issue. Shifting the scan earlier (to feature branches or PR builds) catches problems when they're cheap to fix.

Ignoring transitive dependencies

Your direct dependencies are only part of the picture. The libraries they pull in, and the resources those libraries bundle, are all part of your binary.

Not scanning AAB files

Android App Bundles are the artifact you upload to Google Play. The AAB is the canonical source of truth for compliance content (manifest, SDKs, fonts, code). If your pipeline only produces APKs for local testing, you might miss scanning the actual upload artifact.

Making it sustainable

Compliance scanning in CI works best when it's:

• automatic (no manual steps required)
• fast (doesn't block the pipeline for long)
• actionable (results are clear and specific)
• integrated (findings show up where your team already works)

AppCompliance is built for this workflow. Upload your IPA, APK, or AAB via API, get structured findings back, and integrate results into your existing CI system. If you're new to the platform, the getting started guide walks through your first scan. No tool guarantees store approval, but catching technical issues before submission reduces delays and rejection risk.

Teams that treat compliance as a continuous engineering practice instead of a release-day checklist ship more reliably.