guardianMOBILE RELEASE ANALYSISGet early access
Menu
WHEN TEAMS RUN A REVIEW

Eight moments a release review pays for itself.

Each one names who runs it, what triggers it, what comes back, where the data stays, and where the current limit is.

Before an App Store submission

Who
iOS developer or release manager
Trigger
A release build is ready and the submission window is this week.

Workflow

  1. Run detection and a release check against the project.
  2. Read the compliance findings and the coverage list together.
  3. Fix what blocks, record what you accept, re-run.
What you get
A release decision with the findings and coverage behind it.
Data boundary
The project never leaves the machine running the scan.
Current limit
Guardian does not predict or influence review outcomes. It catches the predictable, mechanical problems before a reviewer does.

Before a Google Play submission

Who
Android developer or release manager
Trigger
A release candidate is about to be uploaded.

Workflow

  1. Run a release check over the release configuration.
  2. Review transport and configuration findings.
  3. Generate an HTML report to attach to the release ticket.
What you get
A shareable report and a decision you can point at.
Data boundary
No artefact is uploaded to Guardian to produce the report.
Current limit
Store policies change independently of Guardian. A pass is not an approval.

Pull-request and branch review

Who
Mobile developer or reviewer
Trigger
A change is open and someone has to decide whether it is safe.

Workflow

  1. Scan the branch with a committed baseline.
  2. Use `--fail-on-new` so the review is about this change, not the backlog.
  3. Discuss the new findings in the review.
What you get
A short list of what this change introduced.
Data boundary
Runs wherever the checkout already is.
Current limit
Scoping to new findings is only as good as the baseline. A stale baseline hides real work.

A CI/CD release gate

Who
Engineering manager or platform engineer
Trigger
The team wants a consistent bar rather than a per-person one.

Workflow

  1. Add the release check to the pipeline inside your own runner.
  2. Commit a baseline so the gate is adoptable on day one.
  3. Preserve the report as a build artefact.
What you get
A build that fails for a stated, inspectable reason.
Data boundary
Analysis happens in your runner. Your CI provider processes your repository under your existing arrangement with them, not because of Guardian.
Current limit
A public installation route for CI has not been published. The templates mark that step explicitly.

Reviewing a Flutter project

Who
Flutter developer or tech lead
Trigger
One codebase ships to two stores and each has its own requirements.

Workflow

  1. Detect the project and its iOS and Android targets.
  2. Run a release check covering shared and platform-specific configuration.
  3. Read findings grouped by platform.
What you get
One review that covers both targets.
Data boundary
Local paths only.
Current limit
Which platform checks apply depends on the structure of your targets, and the ones that could not run are reported as incomplete.

A regulated or security-sensitive project

Who
Security reviewer
Trigger
The work requires evidence, not assurances.

Workflow

  1. Run a scan and generate SARIF for your existing tooling.
  2. Generate an SBOM for the dependency inventory.
  3. Retain both under your own retention policy.
What you get
Machine-readable evidence you control.
Data boundary
No account, no upload, and no network requirement for local analysis.
Current limit
Guardian produces evidence. It does not provide legal, regulatory or compliance advice, and it does not certify anything.

A review where source may not leave the machine

Who
Consultant, contractor or regulated team
Trigger
The client’s agreement prohibits uploading source to a third-party service.

Workflow

  1. Run the CLI on the machine that already holds the checkout.
  2. Generate the report locally.
  3. Share the specific findings, not the whole report.
What you get
A review that respects the agreement.
Data boundary
Nothing is transmitted. This is the case local-first exists for.
Current limit
You are responsible for what you share afterwards. Guardian writes a file; the disclosure decision is yours.

Preparing QA evidence for a release decision

Who
QA lead
Trigger
Someone has to say whether the release is ready.

Workflow

  1. Run the release check and read the coverage list.
  2. Identify checks that were incomplete or did not run.
  3. Attach the report to the release record.
What you get
A record of what was checked and, just as importantly, what was not.
Data boundary
Local files and a local report.
Current limit
Guardian reports the gaps in evidence. It does not execute your test suite for you.

What Guardian does not replace

It makes the routine, repeatable checks cheap enough to run on every release. That is a different job from any of these, and it does not substitute for them.

  • Manual penetration testing
  • Platform or store review
  • Legal, regulatory or compliance advice
  • Human security review
  • Running your QA suite
  • App Store or Google Play approval
See exactly what is checked
A CLEARER PATH TO RELEASE

Make the next release
an informed decision.

Register interest and we will get in touch when there is a build worth your time.

Get early access