A step-by-step guide to connecting Google Jules to a Swift or iOS GitHub repository, scoping access safely, and dispatching your first task the right way.
By the end of this guide, Google Jules will have access to a Swift GitHub repository and you will have dispatched your first task. You will also understand how to scope access so Jules only sees what it needs.
This is the foundational setup every other Jules workflow builds on. Getting the permissions right once saves a lot of confusion later.
The process is intentionally lightweight because Jules relies on GitHub for authentication and code access. You are essentially granting a cloud agent controlled entry to a repo.
Work through the steps in order. Rushing the permission scoping is the most common cause of trouble on the very next task.
Because the exact onboarding screens can change as the product evolves, treat the sequence below as the shape of the process rather than a pixel-perfect script. The concepts, sign in, authorize GitHub, pick a repository, and verify locally, stay constant even when the buttons move.
You need a GitHub account with a repository that contains your Swift or iOS project. If your code is not in GitHub yet, push it there first, because Jules works through GitHub rather than local files.
You also need a Google account to sign in to Jules. Access tiers evolve, so confirm current availability on the official Jules site.
Have a clear idea of one small, well-defined task you want to try first. A tiny job is the best way to learn the loop without risking anything important.
Finally, make sure you have admin or appropriate permission on the GitHub repository or organization. Connecting an app usually requires the ability to approve installations.
It also helps to have a Mac with Xcode ready before you begin. The final and non-negotiable step of any Jules loop is building the result locally, so you want that environment available from the start rather than scrambling for it later.
Go to the official Jules website and sign in with your Google account. Follow the on-screen prompts, since the exact onboarding screens may change as the product evolves.
During first sign-in you will typically be guided toward connecting a source-code host. For our purposes that host is GitHub.
If you are offered a choice of plans or a free allowance, pick whatever suits a trial. You are only testing the connection at this stage.
Once you are signed in, look for an option to add or connect a repository. That is where the GitHub authorization begins.
Take a moment to confirm you signed in with the Google account you intend to use long term. Switching accounts later can mean redoing the GitHub authorization, so it is worth getting right the first time.
When you connect GitHub, you will be sent to a GitHub authorization screen. Read it carefully rather than clicking through on autopilot.
GitHub lets you grant access to all repositories or to selected repositories only. For a first setup, choose selected repositories and pick just your Swift project.
Scoping to a single repo is the safest posture. It means the agent cannot see unrelated code, which is good hygiene for any third-party integration.
Approve the installation. If you are working inside an organization, an owner may need to approve the app before it can be used, so plan for that extra step in team settings.
Pay attention to the specific permissions the installation requests, such as read and write access to code and pull requests. Understanding what you are granting now makes it far easier to reason about, and later audit, exactly what the agent can touch.
Back in Jules, your authorized repository should now appear in the list of available repos. Select it as the target for your work.
If you granted access to a branch-heavy repository, confirm which branch Jules will start from. Typically you want it to base work on your main development branch.
Take a moment to confirm the repo shown is the correct one, especially if you maintain several similarly named projects. Dispatching a task against the wrong repo wastes time.
At this point the connection is established. Jules can now read the repository and, when you assign a task, create a branch and pull request against it.
If the repository does not appear at all, the cause is almost always a scoping or organization-approval gap rather than a bug. Return to the GitHub app settings, confirm the repo is on the access list, and refresh before assuming anything is broken.
Write a small, unambiguous task. A good first request might be "add doc comments to the functions in NetworkClient.swift" or "write unit tests for the DateFormatter helper."
Be specific about scope. Naming files or a module helps Jules stay focused and produces a diff that is easy to review.
Submit the task and let Jules work asynchronously. Because it runs in a cloud sandbox, you can switch back to Xcode and keep coding while it thinks.
When it finishes, it will open a pull request. Do not merge on faith; the next step is verification on your Mac.
Resist the urge to make your first task ambitious. The goal of this run is to learn the loop end to end, from dispatch to a locally verified build, so a trivial change that you can confidently review teaches you more than an impressive one you cannot fully check.
Open the pull request and read the diff in GitHub first. Confirm the change matches what you asked for and does not touch unrelated files.
Then pull the branch locally and open it in Xcode. Build the project against the iOS SDK to confirm it actually compiles.
This step is non-negotiable. Jules cannot build or sign an iOS app, so a clean-looking diff is not proof the app still builds, links, and runs.
Run your tests and, if relevant, launch the app in the simulator. Only once it compiles and behaves should you consider merging.
If the build fails, that is normal and expected rather than a sign the tool is broken, because the agent never had the real compiler in its loop. Read the first error, fix it or feed it back to Jules, and rebuild until the branch is genuinely green on your machine.
Prefer selected-repository access over granting the agent your entire GitHub account. Least privilege is the same principle you apply to any integration.
Keep secrets out of the repository. API keys and signing material should live in your local environment or a secrets manager, never in code an agent can read and reproduce.
Protect your main branch with required reviews and CI checks. That way a Jules pull request cannot merge without passing your gates.
Start with disposable tasks until you trust the loop. As confidence grows, you can hand it larger jobs, but always keep the human review step in place.
Revisit the granted permissions periodically and revoke access to repos you no longer route through Jules. Integrations tend to accumulate quietly, and a short recurring audit keeps the agent scoped to exactly the projects that still need it.
No. During GitHub authorization you can choose selected repositories only. For a first setup, grant access to just the Swift project you want to work on, which keeps the agent scoped to what it needs.
Jules works through GitHub, so your Swift or iOS project needs to live in a GitHub repository. If it is only on your Mac, push it to GitHub first before connecting.
Yes. Jules typically bases its work on a branch you designate and opens a new branch with a pull request for its changes. Confirm the base branch when you select the repository.
Organization-owned repositories often require an owner or admin to approve the app installation before it can be used. Coordinate with whoever manages your organization's GitHub settings.