Summary

WPMAM (the Tiny Screen Labs publishing service) is the upstream system that builds, signs, and submits iOS / Android apps to App Store Connect and Google Play Console. mam-main packages the per-customer settings into a Fastlane-compatible payload and POSTs to the WPMAM publish endpoint.

Implementation is in includes/publish-app/.

Components

Settings persisted

mam_main_app_publishing::local_app_save_publish_app_settings() writes ~20 options from POST. Most are option-key frozen against past customer expectations; renaming requires migrating existing values.

Publish flow

Admin opens Publish Your App
        │
        ▼
mam_app_submit::render()
        │ verify_account_code() against WPMAM
        │ render UI with persisted values
        ▼
Admin fills form / saves
        │
        ▼
local_app_save_publish_app_settings() writes options
        │ JSON-respond with success
        ▼
Admin clicks Submit Publish Request
        │
        ▼
Build Fastlane settings array from persisted options
        │
        ▼
apply_filters( 'mam_fastlane_settings', $settings )
        │ ← sibling plugins inject build-time config here
        ▼
HTTP POST to the WPMAM publish endpoint
        │ fire-and-forget (no synchronous build status)
        ▼
Render the response as the publish-status panel

Account-code verification

Before each publish action the page calls verify_account_code():

1. Reads local-app-account_code from the local site
2. Calls WPMAM with the site URL
3. Compares — surfaces a mismatch warning if WPMAM has a different code (or no code) for this URL

⚠️ Verification is a guard, not a fix. A mismatch means contact Tiny Screen Labs support. See Recipe: Customer enrollment and account code.

mam_fastlane_settings filter

The only extension point for the publish payload. Sibling plugins that need to inject build-time config (third-party SDK keys, custom Info.plist entries, gradle properties) hook here:

add_filter( 'mam_fastlane_settings', function ( array $settings ): array {
    $settings['custom_url_schemes'][] = 'myplugin-callback';
    $settings['ios_extra_plist']['MyPluginAPIKey'] = get_option( 'myplugin_api_key' );
    return $settings;
} );

What WPMAM does with these keys is documented on the WPMAM side — coordinate with the build pipeline team before adding new keys.

Submit semantics

• Fire-and-forget. The submit POSTs and immediately returns the response panel. The build runs async on WPMAM’s CI.
• Status is polled separately. The publish-status panel polls WPMAM for build state; the original submit doesn’t synchronously wait.
• Build numbers must increment. Apple and Google reject duplicate build numbers within a release train. The settings page does not auto-increment; admin must bump.

Frozen surface callouts

• Bundle id options (ios_pn_app_bundle_id, android_pn_app_bundle_id) are frozen — they predate the mam_* rename convention. Renaming would orphan customer Apple/Google submissions.
• mam_fastlane_settings is the only extension point. Don’t try to intercept the HTTP POST or modify the persisted options post-save.
• local-app-account_code is the single most-frozen option in the codebase. Verification reads it; never write it directly.

Gotchas

• app-submit.php is 1076 lines of admin-page UI + save flow. Most of the size is HTML in PHP heredocs. Treat as shared mutable presentation code.
• Account-code verification is a guard, not a fix. Mismatches require support intervention.
• Submit is fire-and-forget. Don’t expect a synchronous success/failure from the submit POST — the build runs async.
• Build-number bumps are admin’s responsibility. Forgetting to bump produces a store-side rejection 30+ minutes after the submit.
• Option keys are frozen. Renaming bundle ids, version numbers, etc. orphans customer submissions.

Related articles

• Recipe: Publish your app to iOS and Android
• Recipe: Customer enrollment and account code
• Hook: mam_fastlane_settings
• Frozen public contracts reference

Metadata