Using AI for CI & Automation in iOS Projects

In this demonstration we will add an agentic code-review step that runs automatically whenever a pull request is opened or updated. You may begin from the sample iOS repository that has been used throughout the program, or from module materials https://github.com/kodecocodes/m3-aici-materials. This repository already contains a basic CI workflow that builds and tests the app; we will extend it with a dedicated review job. I will be using files from 01-integrating-agentic-review-into-ci/Starter. If you are using your own repo, copy the .github folder to start — it already contains workflows/ci.yml and the shared helpers under .github/scripts/. We will add two markdown files at the repository root, CODE_REVIEW.md and CI_GUIDANCE.md, plus the new review workflow.

A brief setup note before we write YAML. Earlier in the program you used Claude inside Xcode and Cursor. The review in this lesson uses GitHub Copilot’s pull-request review, which is a different product from those tools and from the Copilot Xcode extension.

Enable Copilot for this repository, add the required credential as a repository secret, and follow GitHub’s current Copilot code-review documentation if you have not already. We will not walk through account sign-up here; the demonstration starts from a repository that already has that secret.

I am using VS Code to edit the workflow files. You can use any editor you prefer, but the workflow files must be committed to the default branch of the repository for GitHub Actions to run.

Create an empty workflow file named ai-code-review.yml. I will now add the workflow triggers on the pull_request event and the job.

name: AI Code Review
on:
  pull_request:
env:
  CI_GUIDANCE: CI_GUIDANCE.md
jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Checkout repository
        uses: actions/checkout@v7
        with:
          fetch-depth: 0

The job requests only the minimal permissions needed: read access to the repository contents and write access to pull requests so that comments can be posted. The checkout step fetches the full history so that the diff against the base branch can be computed accurately. I also declare a workflow-level parameter, CI_GUIDANCE, that points at CI_GUIDANCE.md at the repository root. The shared scripts will receive that path so the review policy lives in markdown, not inside the YAML or the shell helpers.

Next I add the steps that invoke GitHub Copilot. The materials project already has the helpers under resources/.github/scripts/. Copy them into .github folder of the repository. The workflow does not inline a prompt. ai-code-review.sh installs nothing itself; the job first sets up Node 24, installs the Copilot CLI, then calls that script with the pull-request base ref, a review file, an OpenTelemetry log path, and --guidance set to the CI_GUIDANCE parameter. The script builds the prompt from CODE_REVIEW.md plus CI_GUIDANCE.md, runs Copilot against the whole base-to-head diff, and prints a token-usage summary. A later step posts review.md as a pull-request comment.

name: AI Code Review
on:
  pull_request:
env:
  CI_GUIDANCE: CI_GUIDANCE.md
jobs:
  review:
    runs-on: ubuntu-latest
    timeout-minutes: 15
    steps:
      - name: Checkout repository
        uses: actions/checkout@v7
        with:
          fetch-depth: 0
      - name: Set up Node.js
        uses: actions/setup-node@v7
        with:
          node-version: '24'
      - name: Install GitHub Copilot CLI
        run: npm install -g @github/copilot
      - name: Run Copilot review
        env:
          COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          COPILOT_OTEL_ENABLED: true
          COPILOT_OTEL_EXPORTER_TYPE: file
        run: |
          ./.github/scripts/ai-code-review.sh "${{ github.base_ref }}" \
            --review-file review.md \
            --otel-file "${{ runner.temp }}/copilot-otel.jsonl" \
            --guidance "${{ env.CI_GUIDANCE }}"
      - name: Upload token log
        uses: actions/upload-artifact@v7
        if: always()
        with:
          name: copilot-token-log
          path: ${{ runner.temp }}/copilot-otel.jsonl
          if-no-files-found: ignore
      - name: Post review comment
        if: success()
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR_NUMBER: ${{ github.event.pull_request.number }}

I then add the two markdown files the script expects. CODE_REVIEW.md holds the team criteria: Swift concurrency correctness, memory-management patterns, SwiftUI state handling, and the project’s existing conventions. CI_GUIDANCE.md is a one-line instruction that tells the agent how to treat that file. The workflow passes the latter as the CI_GUIDANCE parameter so later lessons can tighten the policy without editing the scripts.

I would like to remind you that the expected token range for a typical review of this code base is roughly 50,000 to 100,000 tokens, depending on the size of the diff. This figure will be refined once we observe a real run.

As I mentioned previously, to run GitHub Actions workflows you must push the workflow file to the default branch of the repository. I push ai-code-review.yml together with CODE_REVIEW.md and CI_GUIDANCE.md, and then return to the repository’s Actions tab to confirm that the new workflow is listed. The Actions tab immediately shows the new “AI Code Review”.

Now is the time to test the new workflow. With real example.

In the new branch you’ll make a realistic but modest change: it updates a SwiftUI view and adjusts the corresponding view model. You open a pull request that will kick off the AI Review workflow. I will use changes from the resources/code-changes-for-PR and create a PR.

After a short interval the job finishes. Returning to the pull-request conversation we see a new review from the AI agent. The review contains both a short summary and several inline comments attached to specific lines.

Opening the workflow run log we can see the token-usage summary reported by the action. In this particular run the total was approximately 83 000 tokens. That figure is consistent with the estimate we recorded earlier and gives a concrete data point for how large a typical review is.

Finally, a quick look at the two repository guidance files confirms that the agent received the same conventions we have been reinforcing throughout the program. CODE_REVIEW.md lists the priorities; CI_GUIDANCE.md tells the script to treat that file as the review criteria. Because those conventions were already written down, the review comments stayed aligned with team expectations rather than inventing new style rules on the fly. The shared scripts under .github/scripts/ were not edited.

This completes the first end-to-end integration. In the next lesson we will place the same pull request in front of two additional agentic tools and compare the quality, latency, and token count of the resulting reviews. For now, the essential point is that agentic code review can be treated as an ordinary CI step whose behaviour is governed by the same principles of authentication, context control, and token-usage awareness that we apply to any other automated check.