SubmitCheck service information
Security model
SubmitCheck is being built for iOS and iPadOS submission checks with offline local inspection, separate portal access, and evidence-based findings. Hosted capabilities remain subject to launch verification.
Ce document est disponible en anglais.
Local artifact handling
The CLI and macOS app use the same local scanner. It treats archives as hostile input and protects against path traversal, symlink escapes, decompression bombs, excessive file counts, nested depth, and unbounded memory use. Native tools contain no App Store Connect credentials or networking.
App Store Connect access
Only the protected web portal accepts an App Store Connect .p8 key. The authenticated backend stores it in workspace-isolated Google Secret Manager, signs short-lived scoped JWTs on the server, and permits only approved Apple GET requests. Stored keys and Apple tokens are never returned to the browser. Read-only describes SubmitCheck’s behavior, not the Apple key’s permissions elsewhere. Supported key types and endpoint coverage require launch verification; unavailable evidence stays Not checked. SubmitCheck never requests an Apple Account password.
Evidence integrity
Reports compare the exact build with separately collected App Store Connect facts and versioned Apple requirements. Findings include observed and expected evidence, source citations, rule versions, and remediation. Missing or ambiguous evidence becomes Not checked or Manual review, never a pass. Historical reports retain the ruleset used; rescans can reveal changes in build, submission, or requirements evidence.
Hosted authorization
Verified Google identity, exact tenant ownership, entitlement, payload schema, bundle binding, and quotas are enforced by callable backend functions. Firestore and Cloud Storage deny direct client access. Admin additionally requires an exact verified emonster.com allowlist entry, a server-set claim, and recent authentication for publication, rollback, and destructive actions.
Knowledge and AI controls
The planned source-monitoring workflow checks official Apple sources for changes and creates drafts for human review. New rules are not published automatically. Optional AI risk guidance is separately labeled and cannot change deterministic status, severity, evidence, or citations. These capabilities require configuration and verification before public enablement; none predicts Apple approval.