Zum Inhalt springen
WebViewGold Vibe Coding in den App Store
Deutsch
WebViewGold holen

Claude Code

Automatische Readiness-Checks für App Store und Google Play bei jedem Pull Request mit Claude Code

Sobald deine App live ist, ist jeder Merge ein Release, denn die WebViewGold-Apps laden deine Produktions-URL. Ein GitHub-Actions-Workflow mit Claude Code kann jeden Pull Request auf die Änderungen prüfen, an denen webbasierte Apps scheitern, und dir das vor dem Merge sagen. Hier sind zwei Setups, die zusammenarbeiten: ein Reviewer, der über die offizielle Action kommentiert, und ein hartes Gate auf Basis des Headless-Modus.

Ab $109 einmalig pro Plattform, oder unser Team erledigt alles ab $698.

  • Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen
  • Kein Programmieren nötig
  • Einmalzahlung, kostenlose Updates
  • 24/7 Support von echten Menschen
  • Made in Germany seit 2014 · ISO 27001

Warum eine veröffentlichte App bei jedem PR einen Store-Check braucht

Bei einer WebViewGold-App ist das Store-Binary eine Hülle, und deine Web-App ist das Produkt. Ein Pull Request, der einen Stripe-Button auf der Preisseite ergänzt, die Aktion zum Löschen des Kontos entfernt oder einen "Coming soon"-Tab ausliefert, ändert, was deine iOS- und Android-Nutzer sehen, sobald er deployt ist. Er ändert auch, was der Reviewer bei deinem nächsten nativen Update sieht, denn das App-Review testet die ganze App so, wie sie an diesem Tag ist, nicht dein Diff.

Ein normales Code-Review fängt das nicht ab, denn der Code ist in Ordnung; das Problem ist eine Store-Regel. Deshalb ist der Check unten bewusst eng gefasst: Er ignoriert Stil und Architektur und sucht nur nach Risiken für App Store und Google Play. Es gibt ihn in zwei Varianten:

  • Kommentar: anthropics/claude-code-action@v1 prüft das Diff und schreibt einen Kommentar in den Pull Request. Beratend, gut lesbar und günstig für den Einstieg.
  • Gate: Claude Code im Headless-Modus (claude -p) liefert strukturiertes JSON, und der Job schlägt fehl, wenn er einen Blocker findet. Mach ihn zum verpflichtenden Status-Check, sobald du ihm vertraust.

Setup

Du brauchst Admin-Zugriff auf das Repository und entweder einen Claude API-Key oder ein Token deines Claude-Abos.

  1. Die Claude GitHub App installieren und ein Secret anlegen

    Am schnellsten geht es mit /install-github-app in Claude Code; dafür brauchst du die GitHub CLI, angemeldet mit gh auth login. Von Hand: Installiere die Claude GitHub App im Repository und lege ANTHROPIC_API_KEY (ein API-Key aus der Claude Console) oder CLAUDE_CODE_OAUTH_TOKEN (erstellt mit claude setup-token) als Repository-Secret an.

  2. Die Regeln committen, die der Reviewer braucht

    Claude Code liest bei jedem Lauf die CLAUDE.md, also gelten der native Kontext und die Store-Regeln aus dem CLAUDE.md-Template auch in der CI. Halte die Datei kurz; sie wird bei jedem Lauf gelesen und bezahlt.

  3. Den Workflow hinzufügen

    Speichere das YAML unten als .github/workflows/store-readiness.yml und passe die Liste unter paths an deine Ordner an.

  4. Einen Test-Pull-Request öffnen

    Füge einen fest eingebauten "Credits kaufen"-Link auf einer Seite ein, die native Nutzer sehen. Der Kommentar sollte ihn unter Apple 3.1.1 und Google Play Billing anmerken. Schließ den Pull Request danach.

  5. Das Gate ergänzen, wenn du ihm vertraust

    Füge den Gate-Job und sein JSON-Schema hinzu, lass ihn ein paar Wochen parallel zum Kommentar laufen und markiere ihn dann in deinen Branch-Protection-Regeln als verpflichtenden Status-Check.

  6. Die Kosten planbar halten

    Der Workflow überspringt Entwürfe, läuft nur bei relevanten Pfaden, bricht überholte Läufe ab und begrenzt Turns und Minuten. Jeder Lauf verbraucht GitHub-Actions-Minuten plus API-Tokens oder Nutzung deines Abos.

Workflow 1: ein Store-Readiness-Kommentar bei jedem Pull Request

Baut auf der offiziellen Action im Automatisierungsmodus auf: Weil ein prompt gesetzt ist, läuft sie bei jedem passenden Pull Request, ohne dass jemand @claude tippt. Die erlaubten Tools lesen nur, dazu kommen die gh-Befehle, die nötig sind, um das Diff zu lesen und einen Kommentar zu schreiben. Den Prompt im YAML kannst du auch auf Deutsch formulieren, dann kommentiert Claude auf Deutsch.

yaml
# .github/workflows/store-readiness.yml
name: Store readiness

on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
    paths:
      - "src/**"
      - "app/**"
      - "public/**"
      - "native/**"
      - "CLAUDE.md"

concurrency:
  group: store-readiness-${{ github.event.pull_request.number }}
  cancel-in-progress: true

jobs:
  review:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 20
    permissions:
      contents: read
      pull-requests: write
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1

      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            REPO: ${{ github.repository }}
            PR NUMBER: ${{ github.event.pull_request.number }}

            This web app is also published as iOS and Android apps built with
            WebViewGold. The apps load our production URL in a native WebView, so
            every merged change is live in the store apps after the next deploy.
            CLAUDE.md describes the native context and the store rules we follow.

            Review only the changes in this pull request (gh pr diff) for App Store
            and Google Play risks:
            - digital goods, subscriptions, prices or external payment links that
              are visible when isNativeApp() is true (Apple 3.1.1, Google Play billing)
            - removed or broken /privacy, /terms, /delete-account or the in-app
              Delete account action (Apple 5.1.1, Google Play account deletion)
            - a new third-party login without Sign in with Apple (Apple 4.8)
            - placeholder content, "coming soon", dead links, beta labels (Apple 2.1, 2.3)
            - new data collection, SDKs or tracking the privacy policy does not
              cover (Apple 5.1.1 and 5.1.2, Google Play Data safety)
            - fixed bars without safe-area padding, tap targets under 44 px (Apple 4.0)
            - user-generated content without report and block (Apple 1.2)
            - under native/: URLs other than the production domain in Config.swift
              or Config.java, new permissions, version and build numbers

            Post exactly one comment with gh pr comment: a verdict line, then a table
            with severity (blocker, risk, polish), rule, file:line and fix. If nothing
            in the diff is store-relevant, post one line saying so. Skip general code
            review feedback; another check handles that.
          claude_args: |
            --max-turns 25
            --allowedTools "Read,Grep,Glob,Bash(gh pr diff *),Bash(gh pr view *),Bash(gh pr comment *)"

WebViewGold hat uns die kürzeste und effizienteste Time-to-Market ermöglicht, die jemals möglich war, verglichen mit allen anderen App-Plattformen, die wir in den letzten 5 Jahren ausprobiert haben. Ich weiß nicht, warum ich euch nicht schon früher entdeckt habe, aber ich bin wirklich, wirklich froh, dass ich es getan habe. Wir nähern uns derzeit fast 6000 App-Downloads im iOS App Store & Google Play Store ohne Probleme!

Antonio Davila · CodeCanyon

Workflow 2: ein Gate, das bei Blockern fehlschlägt

Füge diesen Job in derselben Datei unter jobs: ein. Er installiert Claude Code, leitet das Diff des Pull Requests in den Headless-Modus und verlangt JSON, das einem Schema entspricht. --permission-mode dontAsk verweigert alles, was eine Freigabe bräuchte, der Lauf kann also Dateien lesen, aber nicht ändern. Mit dem Label store-review-ok kann ein Mensch einen Fehlalarm überstimmen: Label setzen, dann den Job erneut ausführen.

yaml
  # Second job in the same workflow file
  gate:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest
    timeout-minutes: 15
    permissions:
      contents: read
      pull-requests: read
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 0

      - name: Install Claude Code
        run: |
          curl -fsSL https://claude.ai/install.sh | bash
          echo "$HOME/.local/bin" >> "$GITHUB_PATH"

      - name: Store-readiness gate
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GH_TOKEN: ${{ github.token }}
          PR: ${{ github.event.pull_request.number }}
          BASE_REF: ${{ github.base_ref }}
        run: |
          # Human override: add the label, then re-run this job
          if gh pr view "$PR" --json labels --jq '.labels[].name' | grep -qx 'store-review-ok'; then
            echo "Label store-review-ok is set, skipping the gate."
            exit 0
          fi

          git diff "origin/$BASE_REF...HEAD" | claude -p \
            "The input is the diff of a pull request. This web app is also published as iOS and Android apps with WebViewGold, which load the production URL. Using the store rules in CLAUDE.md, report every change in this diff that would likely get the iOS or Android app rejected or removed. Only report findings you can tie to a file and line of the diff. Use severity blocker only for a likely rejection." \
            --permission-mode dontAsk \
            --allowedTools "Read,Grep,Glob" \
            --max-turns 15 \
            --output-format json \
            --json-schema "$(cat .github/store-gate-schema.json)" > result.json

          if ! jq -e '.structured_output' result.json > /dev/null; then
            echo "::warning::The store gate returned no structured result; see the log."
            exit 0
          fi
          jq '.structured_output' result.json
          blockers=$(jq '[.structured_output.findings[] | select(.severity == "blocker")] | length' result.json)
          if [ "$blockers" -gt 0 ]; then
            echo "::error::$blockers store-review blocker(s). Fix them or add the store-review-ok label."
            exit 1
          fi

Das JSON-Schema für das Gate

Speichere es als .github/store-gate-schema.json. Der Headless-Modus legt das zum Schema passende Ergebnis im Feld structured_output seiner JSON-Ausgabe ab, das der Workflow mit jq ausliest.

json
{
  "type": "object",
  "properties": {
    "verdict": { "type": "string", "enum": ["pass", "risks", "blockers"] },
    "findings": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "severity": { "type": "string", "enum": ["blocker", "risk", "polish"] },
          "rule": { "type": "string" },
          "file": { "type": "string" },
          "line": { "type": "integer" },
          "fix": { "type": "string" }
        },
        "required": ["severity", "rule", "file", "fix"]
      }
    }
  },
  "required": ["verdict", "findings"]
}

Kommentar oder Gate?

Kommentar (claude-code-action)Gate (claude -p)
AusgabeEin lesbarer Kommentar mit Fazit und TabelleStatus bestanden oder fehlgeschlagen, JSON im Job-Log
Blockiert den MergeNeinJa, sobald es ein verpflichtender Status-Check ist
AuthentifizierungClaude GitHub App plus API-Key oder Abo-TokenAPI-Key als Umgebungsvariable
Am besten fürRisiken für die Person erklären, die den Pull Request geschrieben hatSicherstellen, dass an einem hektischen Tag niemand einen bekannten Blocker mergt
FehlalarmeDen Kommentar ignorierenDen Code fixen oder das Label store-review-ok setzen und neu ausführen

Lass Claude Code die Workflows für dein Repository schreiben

Claude passt den paths-Filter an deine Ordnerstruktur an und überlässt die Secrets dir.

In Claude Code im Root des Repositorys einfügen
Erstelle GitHub-Actions-Workflows für einen Store-Readiness-Check bei Pull Requests. Kontext: Diese Web-App wird auch als iOS- und Android-App mit WebViewGold veröffentlicht, die unsere Produktions-URL laden; jede gemergte Änderung ist also nach dem nächsten Deploy in den Store-Apps live. CLAUDE.md enthält unseren nativen Kontext und unsere Store-Regeln.

1. .github/workflows/store-readiness.yml, ausgelöst bei pull_request (opened, synchronize, ready_for_review, reopened), Entwürfe überspringen, mit einer concurrency-Gruppe pro Pull Request und einem paths-Filter, der unsere echten Ordner für Web-App und native Projekte abdeckt (sieh dir zuerst die Struktur des Repositorys an).
2. Job review: anthropics/claude-code-action@v1 mit einem Prompt, der im Diff nur Store-Risiken prüft (Apple 1.2, 2.1, 2.3, 3.1.1, 4.0, 4.2, 4.8, 5.1.1, 5.1.2; Google Play Billing, Data safety, Kontolöschung, Berechtigungen; Produktions-URLs in Config.swift und Config.java) und einen Kommentar mit gh pr comment schreibt. Erlaubte Tools: Read, Grep, Glob und die Befehle gh pr diff, view und comment. Höchstens 25 Turns.
3. Job gate: Claude Code installieren, das Diff des Pull Requests in claude -p leiten, mit --permission-mode dontAsk, --allowedTools "Read,Grep,Glob", --output-format json und --json-schema aus .github/store-gate-schema.json. Fehlschlagen, wenn ein Befund den Schweregrad blocker hat; überspringen, wenn der Pull Request das Label store-review-ok trägt.
4. Die Schema-Datei mit verdict und findings (severity, rule, file, line, fix).

Schreib kein Secret in eine Datei. Sag mir, welches Repository-Secret ich anlegen muss und wie ich das Gate zum verpflichtenden Status-Check mache.

Fallstricke

  • Bei allem laufen lassen. Ohne paths-Filter, das Überspringen von Entwürfen und die concurrency-Gruppe bezahlt ein aktives Repository für Reviews, die niemand liest.
  • Ein Prompt, der ins Code-Review abdriftet. Ein Store-Check, der auch Benennungen und Tests kommentiert, wird ignoriert. Beschränke ihn auf Store-Regeln und überlass den Rest einem separaten Review.
  • Erwarten, dass er den Bildschirm sieht. Er liest Code und Diffs. Layout-Probleme auf einem echten Handy, langsame erste Ladezeiten und kaputte Abläufe brauchen weiterhin einen Gerätetest und den Readiness-Check auf deiner Preview- oder Produktions-URL.
  • Das Gate vom ersten Tag an verpflichtend machen. Die Ausgabe des Modells schwankt zwischen Läufen. Lass das Gate erst parallel zum Kommentar laufen, schärfe den Prompt nach und mach es dann verpflichtend.
  • Vergessen, was --bare überspringt. --bare macht CI-Läufe reproduzierbar, überspringt aber CLAUDE.md, Hooks und Skills. Wenn du es nutzt, übergib deine Regeln mit --append-system-prompt-file.
  • Veraltete Regeln. Der Check ist nur so aktuell wie deine CLAUDE.md. Aktualisiere sie, wenn Apple oder Google eine Regel ändern, die dich betrifft; die Datei des Review-Subagents braucht dieselbe Pflege.

Häufig gestellte Fragen

Sollte ich einen API-Key oder mein Claude-Abo nutzen?

Beides funktioniert mit der Action. ANTHROPIC_API_KEY rechnet die API-Nutzung über dein Konto in der Claude Console ab; CLAUDE_CODE_OAUTH_TOKEN, erstellt mit claude setup-token, nutzt einen bezahlten Claude-Plan. Für ein Repository, das mehrere Leute teilen, ist ein API-Key die sauberere Wahl, weil das Token an eine Person gebunden ist.

Liest die Action die CLAUDE.md und den Rest von .claude/?

Sie führt Claude Code im ausgecheckten Repository aus, also gilt die CLAUDE.md für jeden Lauf, und ein Projekt-Skill lässt sich starten, indem du /skill-name als Prompt übergibst. Dieselben Regeln gelten für deine lokalen Sessions und für die CI.

Gibt es eine Option ganz ohne YAML?

Anthropic bietet auch Code Review an, das Pull Requests ohne Workflow-Datei automatisch prüft. Das ist ein allgemeiner Reviewer; damit er die Store-spezifischen Regeln anwendet, müssen sie trotzdem in der CLAUDE.md stehen.

Was kostet ein Lauf?

Das hängt von der Größe des Diffs ab und davon, wie viele Dateien der Reviewer öffnet. Das Turn-Limit, der paths-Filter und das Timeout begrenzen den schlimmsten Fall, und die JSON-Ausgabe des Headless-Modus enthält pro Lauf geschätzte Kosten, die du loggen kannst.

Läuft das auch auf GitLab?

Claude Code hat auch eine Integration für GitLab CI/CD, und das Headless-Gate funktioniert in jedem CI-System, das einen Shell-Befehl mit gesetztem API-Key ausführen kann. Die Action selbst gibt es nur für GitHub.

Findet er jeden Ablehnungsgrund?

Nein. Er findet, was in einem Diff sichtbar ist. Review-Notizen, Screenshots, Datenschutz-Fragebögen und das Verhalten auf Geräten brauchen weiterhin dich, und für ein vollständiges Audit vor der Einreichung ist der Review-Subagent das bessere Werkzeug.

Drei Wege, deine App in die Stores zu bringen

Gleiches Ergebnis, unterschiedlich viel Arbeit auf deiner Seite. Alle drei kommen mit Genehmigungsgarantie und 24/7 Support von echten Menschen.

Selbst machen

$109 pro Plattform, einmalig

Die WebViewGold-Lizenz: ein fertiges Xcode- oder Android-Studio-Projekt. URL einfügen, Name und Icon setzen, Features einschalten, bauen und einreichen. Kostenlose Updates für immer.

Pakete auf der Hauptseite ansehen

Full Service

$698 pro Plattform $798

Schick uns deine URL und dein Icon. Unser Team konfiguriert, baut und liefert deine App innerhalb von 72 Stunden, White-Label, inklusive Quellprojekten. Beide Plattformen für $1,158.

Full-Service-Details Powered by WeSetupYourWebViewApp

Winter-Sale-Preise gültig bis 31. Dezember 2026.

Bereit, deine App zu veröffentlichen?

App Store & Google Play Genehmigungsgarantie – oder Geld zurück innerhalb von 14 Tagen

Lieber abgeben? Full Service: Wir konfigurieren, bauen und liefern innerhalb von 72 Stunden, ab $698 pro Plattform. Fragen? Chatte mit uns – 24/7.

Erstattungen erfolgen zu den in unseren FAQ genannten Bedingungen: eine nicht inhaltsbedingte Ablehnung durch Apple und/oder Google, geltend gemacht innerhalb von 14 Tagen nach dem Kauf.