Learn a disciplined review process for Google Jules pull requests on an iOS project: reading the diff, running CI, building in Xcode, and merging safely.
Google Jules delivers its work as pull requests, which puts you in the reviewer's seat by design. The quality of your iOS project depends far more on how you review than on how the agent writes.
An AI agent can produce code that looks plausible and reads cleanly yet still misunderstands your intent. Review is where that gap gets caught.
Because Jules works asynchronously and across many files, its diffs can be larger and less familiar than a teammate's. That is exactly why a repeatable review checklist pays off.
Think of yourself as the accountable engineer. The agent proposes; you decide what ships.
The stakes are higher on an Apple-platform project because the agent never built or ran what it wrote. A human reviewing another human's pull request can usually assume it at least compiled on the author's machine, but with Jules you cannot make that assumption at all.
Start by re-reading the task you gave Jules. A good review begins by confirming you still agree with what was requested.
Then read the agent's explanation of its approach. Jules typically describes what it changed and why, and that narrative is your first checkpoint.
Ask whether the stated plan actually solves the problem. If the reasoning is off, the code will be too, no matter how tidy it looks.
This five-minute read frames everything that follows. Skipping it means reviewing a diff without knowing what it was supposed to achieve.
It is also your chance to catch a misunderstood task before you spend time on the code. If the plan reveals the agent solved a different problem than the one you meant, the fastest fix is to re-specify the task rather than review a diff that was never going to be right.
Open the file-by-file diff in GitHub. Read every changed line, not just the summary.
Watch the blast radius. If a small task produced sweeping changes across unrelated files, treat that as a warning sign and dig in.
Check that the change respects your architecture. Swift projects with clear layering can be quietly violated by a fix that puts logic in the wrong place.
Look for accidental deletions, weakened error handling, or removed guard clauses. These are subtle regressions that a superficial skim will miss.
Pay attention to force-unwraps, silenced warnings, and broadened access levels too. An agent optimizing for a compiling diff can reach for shortcuts that a careful Swift engineer would reject on sight, and those are exactly the lines review exists to catch.
Scan for anything touching secrets, entitlements, signing configuration, or Info.plist. Changes there deserve extra scrutiny because they affect how your app is built and shipped.
Make sure no API keys or credentials were introduced into the codebase. Secrets belong in your environment, not in a committed file.
Verify that project settings you rely on were not altered unexpectedly. An agent focused on a Swift bug should rarely need to touch build configuration.
If anything security-relevant changed, slow down and understand exactly why before proceeding.
Entitlements and capability changes deserve special caution because they can silently affect provisioning and App Store review. A modified entitlement that looks harmless in a diff can cause a signing or submission failure that only surfaces much later in your pipeline.
If you have CI configured, let it run on the pull request before you do anything else. Automated checks catch a whole class of problems for free.
A good iOS CI pipeline builds the project, runs the test suite, and may run a linter or formatter. Green checks are necessary but not sufficient.
Remember that CI on a hosted runner still is not the same as your signed, device-tested build. It confirms the code compiles and tests pass, not that the app is ready for the store.
If CI fails, read the logs and either request changes from Jules or fix it locally. Never override failing checks to merge faster.
If you do not yet have CI for your iOS project, adding even a simple build-and-test workflow is one of the highest-leverage guardrails you can put around agent-authored pull requests. It turns a class of silent failures into automatic, visible ones before a human ever opens the diff.
Even with green CI, pull the branch and open it in Xcode. Building locally against the iOS SDK is the ground truth for an Apple-platform project.
Run the app in the simulator and exercise the changed behavior. Watching it work is worth more than any diff summary.
Run your tests locally as well, particularly UI-affecting changes that automated runners may not fully cover. Trust what you can observe.
This step is where you catch the difference between code that compiles and an app that behaves. It is not optional for anything user-facing.
For changes that affect the user interface, take an extra minute to check states that are easy to forget, such as dark mode, dynamic type sizes, and empty or error states. Those are precisely the conditions an agent working without a running app cannot have observed.
If everything checks out, merge through your standard process. Prefer squash or merge conventions your team already uses so history stays clean.
If something is wrong, comment specifically on the lines in question. Jules can revise the same pull request in response to precise feedback.
When you request changes, describe the desired end state, not just the flaw. Clear direction converges faster than a list of complaints.
After merging, keep an eye on the next build. Confidence in an agent is earned one clean, verified merge at a time.
Resist the temptation to fix small issues yourself and merge silently, at least early on. Sending the correction back as feedback teaches you how well the agent responds and gradually calibrates how much you can safely delegate.
Protect your main branch so no pull request merges without review and passing checks. This applies the same standard to Jules as to any contributor.
Require at least one human approval on agent-authored pull requests. The accountability should always rest with a person.
Consider labeling Jules pull requests so reviewers know an agent authored them and apply appropriate scrutiny. Transparency helps the whole team calibrate.
Document the expectation that no iOS change merges without a local Xcode build. Making that rule explicit prevents a green diff from being mistaken for a shippable app, especially as Jules and its capabilities keep evolving.
Write these expectations down somewhere durable, such as a contributing guide, rather than relying on habit. A rule that lives only in one senior engineer's head does not survive a busy release week, whereas a documented gate protects the whole team consistently.
Yes. CI confirms the code compiles and tests pass, but it does not confirm intent, architecture fit, or that the app behaves correctly on device. A human should always approve agent-authored pull requests.
You should not, for any user-facing iOS change. Only a local Xcode build against the iOS SDK confirms the app actually compiles and runs. A clean diff is not the same as a working app.
Leave specific review comments describing the desired end state, then let Jules revise the same pull request. Precise, outcome-focused feedback converges much faster than vague complaints.
It helps. Labeling agent-authored pull requests tells reviewers to apply appropriate scrutiny and keeps your team's accountability transparent.