WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Review code and collaborate in Xcode

Review code and collaborate in Xcode

EssentialsDeveloper Tools
Watch original video

Highlight

Xcode 13 integrates code review, historical comparison, branch switching, Pull Request, review discussion and Xcode Cloud status into the same development environment. Developers can discover regressions, submit fixes and complete team collaboration in the source code context.

Core Content

One user said in an App Store review that Fruta’s interface looks wrong lately. Developers know where the problem is, but before they can actually fix it, they need to answer two questions: when did the change start and which files were affected.

Previously, this would typically involve switching back and forth between the editor, the Git client, the web Pull Request, and the CI page. You look at the code in Xcode, look at the differences in other tools, and then go back to the web page to respond to review comments. Every time you switch, part of the context is lost.

What Xcode 13 does is to bring these actions back to the source code. Code Review mode displays local changes and historical version differences directly in the editor. The Source Control Navigator’s Changes tab lists project-level file changes. The toolbar displays the current branch and allows access to related Pull Requests.

This speech is strung together with a complete process: first use code review mode to track down UI regressions, then create repair branches and Pull Requests, then view team comments and CI status in Xcode, and finally merge your own changes and review colleagues’ Pull Requests.

Start with a UI regression

The problem first appeared in the Ingredients interface. When developers modify code in the source file, the editor gutter (sidebar) will mark the location of the change. After clicking the Code Review button in the editor bar, Xcode will compare the local edits with the most recent commit.

This solves the first pain point: you don’t have to wait until commit to check the differences when writing code. Every edit can see the old and new values ​​immediately.

Expand from single file diff to project diff

A fix will usually span multiple files. Looking only at the current file, it is easy to miss changes in another place. Xcode 13 adds a Changes tab to the Source Control Navigator to list all files that have been changed since the last commit.

Click on a file in the list, and Xcode will automatically enter code review mode and display the differences for the file. Developers can quickly jump between files to reconfirm what is included in this fix.

Pull Request back to Xcode

After the fix is ​​written, the developer needs to ask team members to confirm that this unfamiliar code will not introduce new problems. Xcode 13 integrates GitHub and Bitbucket Server to create Pull Requests from the source control popover.

Pull Request will appear in the Changes Navigator, including changes that have been pushed to the branch, local changes that have not yet been submitted for push, review discussions, approval status, and CI status. Comments can jump directly to the corresponding source code location.

Detailed Content

1. Code Review mode: View local changes in the editor

(01:26) Xcode 13’s Code Review mode can compare local edits with the most recent commit. The entrance is the Code Review button on the editor bar. When enabled, the editor will continue to highlight changes in the current file.

Editor Bar → Code Review
Source Editor → Gutter change markers
Bottom Bar → Stepper arrows
Editor Menu → In-line / Side-by-side

Key points:

  • Editor Bar → Code Review: Click the Code Review button in the editor bar to enter code review mode. -Source Editor → Gutter change markers: The editor sidebar will mark the location of changes in the current file. -Bottom Bar → Stepper arrows: The stepper in the bottom bar displays the number of changes and uses arrows to jump between changes. -Editor Menu → In-line / Side-by-side: The Editor menu in the upper right corner can switch between in-line display and left-right contrast display.

This function is suitable for use when writing repairs. You don’t need to commit first, and you don’t need to open an external diff tool. Every time you write a piece of code, you can confirm what changes it made compared to the last commit.

2. Commit selectors: Compare any two historical points

(02:33) Local changes can only explain “what did I just change”. To locate the source of the regression, two historical versions must be compared. Xcode 13 adds commit controls to the bottom bar that allow you to select commits from branches, tags, and recent locations.

Bottom Bar → Commit controls
Select left revision → Release branch or tag
Select right revision → Another branch, tag, or recent location
Review highlights → Purple / Orange
Bottom Bar → Reset

Key points:

  • Bottom Bar → Commit controls: Set the comparison range using the submission control in the bottom bar. -Select left revision: Select a historical version, such as the release branch corresponding to a TestFlight or App Store release. -Select right revision: Select another historical version to view code changes between two points in time. -Review highlights → Purple / Orange: Xcode uses purple and orange to distinguish the two commits currently being compared. -Bottom Bar → Reset: After viewing the historical differences, click Reset to return to the latest local changes.

The scenario in the talk is a release branch. The team cuts a release branch every time it commits to TestFlight or the App Store. After a UI issue occurs, you can directly compare two release-related versions to find out what changes have occurred when ingredients are displayed.

3. Changes Navigator: View the change list of the entire project

(03:47) Xcode 13’s Source Control Navigator adds a Changes tab when repairs span multiple files. It lists all modified files in the project since the last commit.

Source Control Navigator → Changes
Changed file → Open in Code Review mode
File list → Move between changed files
Pull Request section → Preview included changes
Local Changes section → See changes not yet pushed

Key points:

  • Source Control Navigator → Changes: Open the Changes tab in the source control navigator to view the project-level change list. -Changed file → Open in Code Review mode: After clicking on a file, Xcode automatically enters code review mode and displays the file differences. -File list → Move between changed files: Switch in the file list to quickly review all files involved in this repair. -Pull Request section → Preview included changes: After creating a Pull Request, the content that has been submitted and pushed to the branch is displayed here. -Local Changes section → See changes not yet pushed: This displays local changes that have not yet entered the Pull Request.

This list addresses the problem of omissions. Before submitting, developers can confirm file by file which modifications will enter the Pull Request and which modifications will remain local.

4. Branch popover: Create and switch branches from the toolbar

(04:16) Xcode 13’s toolbar displays the current branch. Click on the branch name to switch between recently used branches, or create a new branch through the secondary menu.

Toolbar → Current branch name
Branch popover → Recent branches
Secondary menu → Create branch
Switch branch → Xcode discovers associated pull requests

Key points:

  • Toolbar → Current branch name: The toolbar directly displays the current branch, reducing the risk of continuing to work on the wrong branch. -Branch popover → Recent branches: After clicking on the branch name, you can quickly switch to the recently processed branch. -Secondary menu → Create branch:Create a new branch for the fix via the sub-menu. -Switch branch → Xcode discovers associated pull requests: After switching branches, Xcode will automatically discover related Pull Requests based on the source branch and the current branch.

This is important for daily repairs. The developer first locates the problem locally, then creates a repair branch, and then connects the branch to the Pull Request.

5. Pull Request workflow: create, review, view CI, merge

(05:12) Xcode 13 provides integrated Pull Request support for GitHub and Bitbucket Server. Developers can create Pull Requests from source control popovers. Xcode will first create a draft pull request and merge the current branch into the default upstream branch. The target branch in the speech ismain。

Source Control Popover → Create Pull Request
Draft Pull Request → Target default upstream branch
Title + Description → Explain the fix
Participants → Add reviewers
Changes Navigator → Pull Request overview
Pull Request actions → Merge

Key points:

  • Source Control Popover → Create Pull Request:Create a Pull Request from the source control popup. -Draft Pull Request → Target default upstream branch: Xcode first creates a draft Pull Request and merges it into the upstream default branch by default. -Title + Description → Explain the fix: Fill in the title and description before publishing to let reviewers understand the repair content. -Participants → Add reviewers: Click the Participants button to mark specified colleagues as reviewers. -Changes Navigator → Pull Request overview: After a Pull Request is published, you can view the overview, status, and discussion in the Changes Navigator. -Pull Request actions → Merge: After the review and CI are passed, select Merge through Pull Request actions.

(07:48) If the project uses Xcode Cloud, the Pull Request’s CI popover displays the continuous integration workflow status. Developers can see a summary of test results and click on an entry to jump to a detailed Xcode Cloud report.

Pull Request → CI popover
Workflow status → Test result summary
CI entry → Xcode Cloud report
Merge strategy → Merge Commit
Optional commit message → Keep or edit

Key points:

  • Pull Request → CI popover: View Xcode Cloud continuous integration status in a Pull Request. -Workflow status → Test result summary: Quickly confirm whether the test passes. -CI entry → Xcode Cloud report: Click a CI entry to enter a more detailed Xcode Cloud report. -Merge strategy → Merge Commit: Select the merge strategy when merging, and use the default Merge Commit in the speech. -Optional commit message → Keep or edit: You can fill in optional commit information before merging, or keep the default content.

6. Review teammate pull requests: Leave comments on source code lines

(08:58) The source control popover will display Pull Requests related to you. It contains Pull Requests that you create, as well as Pull Requests that team members ask you to review.

Source Control Popover → Relevant pull requests
Pull Request node → Overview / Review status / Discussions
Changes Navigator → Files under pull request
Editor → Secondary click → Insert comment on line
Actions → Approve

Key points:

  • Source Control Popover → Relevant pull requests: View Pull Requests related to you. -Pull Request node → Overview / Review status / Discussions: View an overview, review status, and discussion of your colleagues’ Pull Requests. -Changes Navigator → Files under pull request: View file differences one by one under the Pull Request node. -Editor → Secondary click → Insert comment on line: Right-click on a specific source code line in the editor and insert a comment. -Actions → Approve: After confirming the changes, approve the Pull Request through actions in the upper right corner.

This process ties review comments to lines of source code. Discussions will appear next to the actual changes and no longer remain in the page’s comments list.

Core Takeaways

  1. What to do: Establish a “local review before commit” habit for your team.

    • Why it’s worth doing: Code Review mode will continuously display the differences between local edits and recent submissions, which is suitable for discovering unnecessary changes before submission.
    • How ​​to start: After writing a small fix, openEditor Bar → Code Review, use stepper to check the changes one by one, and then submit.

  2. What to do: Map each release to a branch or tag to facilitate tracking of regressions.

    • Why it’s worth doing: Xcode 13 allows you to use commit controls to compare branches, tags, and recent locations, which is suitable for locating changes between two releases.
    • How ​​to start: Cut the release branch or tag each time before publishing in TestFlight or App Store; after a problem occurs, select two release points in Code Review mode to compare.

  3. What to do: Complete the Pull Request initial review within Xcode.

    • Why it’s worth doing: Pull Request changes, discussions, and local unpushed modifications are all displayed in the Changes Navigator, and developers don’t have to leave the source environment.
    • How ​​to start: FromSource Control Popover → Create Pull RequestCreate a draft, fill in a title and description, and add reviewers via Participants.

  4. What to do: Use CI status as a pre-merge check.

    • Why it’s worth doing: Xcode Cloud status can be displayed in the CI popover of the Pull Request, and you can jump directly to the detailed report when it fails.
    • How ​​to start: Configure the Xcode Cloud workflow for the project; after passing the review, check the CI popover in the Pull Request, and then select the merge strategy.

  5. What to do: Write code review comments on specific lines of source code.

    • Why it’s worth it: Xcode supports secondary clicks in the editor and inserting row-level comments, feedback and changing positions directly.
    • How ​​to start: Open the Pull Request that your colleague has requested for your review, enter the file diff in the Changes Navigator, insert comments on the lines that need improvement, and finally use actions to approve or continue the discussion.

Comments

GitHub Issues · utterances