Learn how to use Sourcegraph Cody's codebase-aware chat to explore, explain, and navigate an unfamiliar Swift iOS project faster, with practical prompts and a verification workflow.
Large iOS projects are hard to hold in your head. Views, view models, coordinators, networking, and persistence spread across dozens of Swift files.
Cody's chat is designed for exactly this. It uses Sourcegraph's search to retrieve relevant files and answer questions grounded in your actual code, not generic Swift.
That makes it a strong tool for onboarding onto a new team, reviewing an area you rarely touch, or reconstructing how a feature works before you change it.
This guide shows how to ask productive questions, refine context, and verify answers so you trust what you learn.
Open your project at its root folder in VS Code or a supported JetBrains IDE so Cody can see the whole codebase.
Open the Swift file most relevant to your question before you ask. Open files strongly shape the context Cody pulls in.
If your project has many modules, keep the module you are exploring in focus. Too many unrelated files open can dilute context.
Confirm sign-in and that context features are active on your Sourcegraph instance. Without codebase context, chat degrades to a generic assistant.
Begin broad. Ask 'Give me a high-level overview of how this app is structured' or 'What are the main layers and where does each live?'
A strong answer names real folders, targets, and types. Use it as a map before diving deeper.
Follow up on a specific area: 'How does the app handle networking?' or 'Where is user authentication implemented?'
These questions orient you quickly, which is especially valuable when you inherit a codebase with little documentation.
Pick a user-facing feature and trace it. Ask 'When the user taps the login button, what happens end to end?'
Cody can follow the flow from the SwiftUI view or UIKit controller through the view model into services and back. Ask it to list the files involved.
When it references a type, drill in: 'Show me where LoginViewModel is defined and what it depends on.'
This is how you build an accurate mental model fast, and it beats manually jumping through files with search alone.
Select a confusing block, such as a Combine pipeline, an async/await sequence, or a generic function, and ask Cody to explain it line by line.
Ask targeted questions: 'Is this code doing work on the main thread?' or 'What happens if this optional is nil here?'
For concurrency, ask specifically about actors, tasks, and thread hops. These are common sources of bugs where a clear explanation saves time.
Remember that explanations are interpretations. If something sounds off, verify against the actual behavior rather than accepting it outright.
You get sharper answers when you point Cody at specific context. Name the file or symbol in your prompt, for example 'In ProfileService, why does fetchProfile retry?'
Many Cody interfaces let you attach or mention files directly in chat. Use that to force the right context into the prompt.
When comparing two implementations, mention both types so Cody reasons about the pair rather than guessing.
Explicit references reduce hallucination because you are constraining what Cody talks about to real, named parts of your code.
Cody's prompts and commands package common actions like 'explain this,' 'find usages of this pattern,' or 'summarize this file.'
For navigation, a summarize-file prompt on each unfamiliar Swift file gives you quick per-file notes as you read.
If your team maintains custom prompts, use them to standardize how everyone explores the codebase.
Repeatable prompts turn ad hoc questions into a consistent onboarding routine that new engineers can follow.
Treat every Cody answer as a lead, not a fact. Cross-check by opening the files it cites and reading the relevant lines yourself.
For behavior claims, confirm by building and running in Xcode, or by writing a small test that exercises the path.
Watch for confidently wrong statements about concurrency, memory, or edge cases. These are areas where AI explanations most often slip.
The payoff of verification is durable understanding: you leave the session knowing the code, not just having read a summary.
Once you understand an area, ask Cody to help plan a change: 'I want to add caching to ProfileService. What files would I touch and what are the risks?'
Use its plan as a checklist, then implement with autocomplete and edits, reviewing each suggestion.
Build and test in Xcode after each meaningful step. Cody does not compile or run your app, so Xcode remains where you confirm correctness.
This progression, from explore to plan to implement to verify, is where codebase chat delivers the most value for iOS work.
Refactoring often means understanding two versions of the same idea at once. Ask Cody to contrast them: 'How does the old NetworkClient differ from the new one, and what changed in behavior?'
Name both types so the right files land in context. Comparison prompts are weakest when Cody has to guess which implementations you mean.
Use the answer to spot subtle differences, such as a changed retry policy or a dropped error case, before you delete the old path.
This is especially useful during migrations, where two parallel implementations coexist for a while and the real risk is quietly losing behavior.
As you explore, capture what you learn outside the chat window. A short notes file or a simple diagram keeps the mental model you build with Cody from evaporating between sessions.
Ask Cody to produce a concise summary you can paste into your notes, such as a bullet list of the main modules and their responsibilities.
Revisit and correct that map as you verify claims against the real code. Your notes should reflect what you confirmed, not just what Cody proposed.
Over a few sessions this compounds into durable documentation that helps the next engineer, whether or not they use Cody themselves.
Retrieval is not unlimited. Very broad questions across a huge repo can pull in more than the model uses well, which dilutes the answer.
Prefer focused questions scoped to one feature or layer. Narrow prompts tend to retrieve the most relevant Swift files and produce sharper answers.
If an answer feels shallow, split the question into smaller parts and ask them in sequence rather than all at once.
Thinking in terms of a context budget helps you get consistent quality instead of the occasional generic reply.
Cody uses Sourcegraph's search to retrieve relevant files as context. Open the project root and keep related files open so it can pull the right Swift code into each answer.
Yes. Ask it to follow a user action end to end and list the files involved. It can move from a view through view models into services, though you should verify the files it cites.
No. Explanations are interpretations and can be wrong, especially around concurrency and edge cases. Verify by reading the cited code and running or testing the behavior in Xcode.
Chat itself is read-focused, but edit and apply features can modify files. Review any change before accepting it, then build and test in Xcode.