xcode 13 что нового
What’s new in Xcode 13?
Vim keybindings, integrated collaboration, faster version comparison, and more.
Xcode 13 arrived at WWDC21 and includes a huge range of new features, improvements, and performance enhancements. In this article I’m going to walk you through all the key changes, so you can get up to speed quickly, but before I start I need to make two things clear:
First, no, I don’t have beta access to Xcode Cloud or the new Swift Playgrounds. Trust me, I wish I did! Both of these things look likely to be significant upgrades for the Swift community, and I’m really keen to try them out at the earliest opportunity.
And second, you might immediately note that Xcode hides your file extensions by default in the project navigator. This seems to mimic your Finder configuration, so if you’re suddenly confused where your file extensions have gone then you can bring them back With This One Weird Tip: go to Xcode’s preferences, select General, then change File Extensions to Show All. I’m going to try sticking with hidden extensions to see how I get on with it.
Anyway, in this article I’ll be talking about the new workflow tools for teams, the new source control features, the new improvements to how we write code, and more – it’s a packed release, so let’s get straight to it.
SAVE 50% This Black Friday all our books and bundles are half price, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
Source editor improvements
First let’s talk about the source editor, which is where we spend most of our time – this is just the way we type code into Xcode, as opposed to all the main IDE features around it.
When I posted about some of these on Twitter, a bunch of folks replied back saying how Xcode sucks because their personal favorite IDE had these features years ago, and honestly just please pass me by with those kinds of comments – if I wanted to use your IDE I would already be doing so.
So, let’s talk about some major changes to the way we write code in Xcode.
First, if you use a type that isn’t currently available, Xcode can automatically import it for you. So, if you write code like this:
Tip: This will only work with protocols that are already imported somewhere else in your project – it won’t read all types in unrelated protocols.
Second, Xcode now detects when you’re trying to unwrap an optional, and completes it for you. Try it with code like this:
Third, Xcode is now able to offer deeper autocomplete options by including properties inside properties. Try it with code like this:
As you’re typing view.corn Xcode will offer view.layer.cornerRadius as a completion – it has looked inside the layer property and hoisted its completion options up one level.
Fifth, when you loop over an array, Xcode will automatically complete using a singular version of the array name. Try it out with code like this:
If I had to guess, I’d say this feature was powered by machine learning of some sort because it’s able to understand all sorts of plurals – including irregular ones. Try these out, for example:
Sixth is the ability to have Xcode tone back its source editor issue reports. These are obviously very important and I rely on them dozens of times every day, but sometimes you know exactly what the problem is and the just kind of get in the way – sometimes they actually interfere with what you’re trying to do.
Well, in Xcode 13 there’s a new way to show issues in your source editor called minimized mode. This still shows your code issues right next to your source code, but now collapses them down to a single icon on the right edge. Clicking that will bring up the same information and options you had before. If you’d like to try this new feature, go to Xcode’s preferences, choose the General tab, then change the Issues option from Show Inline to Show Minimized.
And seventh is the ability to place column breakpoints, which are – as you might imagine – breakpoints that happen at a precise part of a line of code, rather than breaking for the whole line.
As an example, we might have several functions being called together to produce a single value, like this:
To try this out in the code above, select second() then press Shift+Cmd+A to bring up the code actions – or right-click then select Show Code Actions. In that menu you’ll see Set Column Breakpoint, which will insert a small, vertical breakpoint exactly there.
These column breakpoints work exactly like regular line breakpoints, so you can click and drag them away to remove, or right-click and select Edit Breakpoint to add customization.
And then there’s Vim mode
The last major change to Xcode’s source editor deserves some special focus because it’s going to make a lot of people happy – and also make a lot of other people unable to quit!
That feature is Vim key bindings, and you can enable it under Xcode’s preferences – go to the Text Editing tab and check the Enable Vim Key Bindings box.
If you haven’t use Vim before, it’s a command-line text editor that started out back in 1976 as Vi, and become “Vi Improved” (just Vim for short) in 1991. Vim has a very particular way of working that requires careful knowledge of the keyboard, and at last you can now use much of that knowledge in Xcode too.
I say “much” because only a subset of Vim’s keybindings are supported: navigation, insertion, yanking, searching, and so on are all there, but relative line numbers, repeating operations, saving a file with :w doesn’t work, and more. However, it’s a great start, and I’m sure more will come.
Fun fact: The first person to file feedback asking for Vim support in Xcode did so back in 2004, back in the Xcode 1 days!
Let’s talk about version control
Xcode has had integrated version control for a very long time, but this year it’s getting its biggest upgrade ever – it’s now much easier to compare changes between any two versions, you can open pull requests in Xcode and invite reviewers, and even handle code review right inside the IDE.
Tip: You need to have Xcode’s source control features turned on this to work. If you previously disabled them, go to Preferences > Source Control and check the Enable Source Control box before continuing.
To demonstrate the new features, start by opening up any project that has some interesting version control history. For example, I might use Unwrap, my free app for learning Swift.
With this open, you’ll notice Xcode immediately shows you current branch right in its title bar, next to the Play button – I see “Unwrap” and “main”, for example. If you want to change to a new branch, click that and select something else, or press the detail dots next to your current branch and make a new branch from there.
Now just go ahead and make changes like you normally would, and if you Xcode’s “Show Source Control Changes” option selected you’ll see your new lines get marked with a blue edge. When you’re ready, go to View > Show Code Review to see exactly what changed, but this is where things get more interesting:
These version buttons have a color scheme that you’ll get used to: if it’s black it means it’s your last commit, if it’s purple it means it’s a newer commit, and if it’s orange it’s an older commit. These same colors are also used in the source editor to highlight the changes.
Tip: If you’re busy exploring older changes this way, press Reset to get back to the default view.
Once you’ve checked your work, commit the change as you normally would by going to Source Control > Commit and adding a meaningful commit message, optionally also pushing it to the remote repository.
And now you can make a pull request: click your branch name in the title bar and select Create Pull Request. Give it a title and a description, and even add any reviewers you want by clicking the person icon next to Publish.
Comments are shown in Xcode, and you can view changes there too. Right-click on a review you’re doing and insert a comment.
Checking performance and crashes
Xcode’s organizer is a great way to identify problems in your code – it’s not new, but you can go there to see your crashes, slow disk writes, extensive memory usage, and more. This year they added support for spotting termination – when your code goes bang – and for regressions, in case you ship an update with significantly worse metrics than before.
But the most impressive feature is that Apple has said now crash reports from TestFlight users will appear the Organizer window within just a few minutes of happening, along with whatever feedback your user submitted. This is going to be huge for when someone tells you directly about a problem on Twitter or Slack, because you can immediately see the crash, see what code caused the crash, and ask them what they were up to.
Custom documentation with DocC
Xcode 13 now has the ability to create documentation sets straight from our code. It reads all the Markdown comments you add, and builds them right into Xcode’s default help system using exactly the same layout and formatting as Apple’s own frameworks.
This is such a big feature that I think it deserves it’s own dedicated article – watch this space.
And there’s more…
There are still more new features introduced in Xcode 13, including support for Swift package collections, cloud signing, and new accessibility controls and overrides, and this is still only beta 1 – it’s going to be a few more months until the final version is ready, and I’m excited to see how it continues to be refined.
SAVE 50% This Black Friday all our books and bundles are half price, so you can take your Swift knowledge further without spending big! Get the Swift Power Pack to build your iOS career faster, get the Swift Platform Pack to builds apps for macOS, watchOS, and beyond, or get the Swift Plus Pack to learn advanced design patterns, testing skills, and more.
About the author
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He’s also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and a speaker at Swift events around the world. If you’re curious you can learn more here.
Xcode 13
Xcode 13 adds powerful new team development features, perfect for working with Xcode Cloud as well as with GitHub, Bitbucket, and GitLab collaboration features. Initiate, review, comment, and merge pull requests directly within Xcode. See your teammates’ comments right inside your code. And quickly compare any two versions of your code files.
Easy setup
Take advantage of a complete workflow to manage pull requests directly within Xcode. Create new requests, see a queue of pull requests ready for your review, and quickly view, build, and test results generated locally or by Xcode Cloud.
Team comments inline
Comments that your teammates make on code during review display inline within the code editor, along with the name and avatar of the reviewer.
Quick compare
Jump into a comparison view of any two versions of your source code, in any editor, while retaining your current editing context.
Cloud signing
Apps are code-signed using an Apple-hosted service that manages all of your certificates, making App Store submission easier and more reliable. Just sign in to Xcode using your Apple ID, and your Mac is configured for development and deployment based on your membership roles and permissions.
Bottom bar
The always-visible bottom bar shows useful information, such as line and column, and offers direct access to quickly compare different versions of code.
Vim mode
Many common key combinations and editing modes familiar to Vim users are supported directly within the code editor, using the new bottom bar to show mode indicators.
CarPlay simulator
This new simulator for Mac offers complete control over screen size, resolution, and variable input methods, so you can test your CarPlay experience across many different car platforms.
Instant crash reports and feedback
Crash reports from your TestFlight users appear in Xcode Organizer within just a few minutes, complete with user feedback so your testers can tell you exactly what was happening when they experienced the crash. The crash log displays inline and you can jump to the related code with just a click.
Custom documentation
Build documentation for your Swift framework or package directly from your source code’s documentation comments, then view it in Xcode’s Quick Help and dedicated documentation viewer. Extend those comments by adding extension files, articles, and tutorials — all written in Markdown — and choose to share the compiled DocC Archive with other developers or host it on your website.
Xcode Cloud beta
Xcode Cloud is a continuous integration and delivery service built into Xcode and designed expressly for Apple developers. Submit your request to access the beta and we’ll email you when your account can be enabled.
Get started
Download Xcode and use these resources to build apps for all Apple platforms.
Xcode Documentation
Find details and step-by-step instructions on how to use Xcode.
Documentation
Browse the latest documentation, including tutorials, sample code, articles, and API reference.
Session videos
See the latest in Apple technologies presented at WWDC and other events.
Forums
Ask questions and discuss development topics with Apple engineers and other developers.
Xcode Cloud beta
Xcode Cloud is a new continuous integration and delivery service built into Xcode 13, and designed expressly for Apple developers.
Join the waitlist.
To help ensure the best possible experience, access to the beta is initially limited and availability will expand over time. Submit your request to access the beta and we’ll email you when your account can be enabled. Access to the Xcode Cloud beta is free to Apple Developer Program members. More details on pricing and availability of Xcode Cloud will be announced this fall.
Eligibility
To request access to Xcode Cloud beta, you’ll need to be an Account Holder in the Apple Developer Program as of June 7, 2021. You’ll also need to review and accept the latest Apple Developer Program License Agreement posted on June 7, 2021.
Team access
Requests for an organization’s team to access Xcode Cloud beta need to be submitted by the membership Account Holder on the organization’s behalf. Once their account is enabled to access the beta, other members of the team will automatically have access, depending on their role permissions.
Technical requirements
You’ll need a Mac running the latest beta version of Xcode 13 and an Apple ID with two-factor authentication enabled.
Xcode
Find details and step-by-step instructions on how to use Xcode Cloud.
App Store Connect
Find details using the App Store Connect dashboard for Xcode Cloud.
Session Videos
See the latest in Apple technologies presented at WWDC and other events.
Forums
Ask questions and discuss development topics with Apple engineers and fellow developers.
Review code and collaborate in Xcode
Explore the latest enhancements to code review and pull requests in Xcode. Learn more about diff display preferences, commit selectors, changes navigator, and pull request workflows. We’ll show you how you can collaborate with your team and find regressions by connecting your code review and PR workflows directly to your source code.
Resources
Related Videos
WWDC21
Hi, everyone. My name is Kieran, and I’m an Xcode engineer working on source control technologies. Xcode 13 completely reimagines code review mode and introduces brand new collaboration workflows to help you improve the quality of your app. In this session, I’ll walk you through a typical workflow with our app Fruta. We’ll use the new code review and pull request features in Xcode 13 to find a bug, get feedback, integrate those changes, and provide feedback to my colleagues. Let’s get started. A big part of my work is looking into issues that our users reported. In order to fix a bug, I first have to understand when and why it started happening. By stepping back in time through my code changes, I can often figure out the cause using code review mode. One of the App Store reviews we had mentioned that some UI changes recently made to our app don’t look quite right. I have a pretty good idea what the issues are, so I’ll go ahead and start making some changes. As I start typing, the changes appear in the source editor’s gutter. I find it really useful to know what the previous values were so I can have a good idea of everything that’s changed. For this, I can jump into code review mode. Simply click on the Code Review button in the editor bar to see the comparison of local edits against the most recent revision.
As I’m working on my document, code review mode continuously highlights the edits I’m making so I always know what’s changed since my last commit.
When I’ve made multiple edits to a file, the stepper control in the bottom bar shows me how many changes I’ve made. Clicking the arrow icons will jump between my code changes. That way, I don’t have to scroll through the file looking for the edits myself. Sometimes it can be easier to see what’s changed side-by-side, but I prefer to see my changes in-line. Xcode can show me my changes in either style, and I can flip between the two using the Editor menu at the top right. I want to ensure that I’ve caught every issue with the UI bug. To really dig in and understand where a bug came from, I need to see what’s changed between releases of my app. I can use the commit controls in the bottom bar to set up those comparisons. Xcode 13 allows me to choose commits across my branches, tags, and most recent locations so I can easily see the changes in my app between any two points in time. I usually cut a release branch every time I submit to TestFlights or the App Store, so I’ll take a look at two versions of my code related to that release.
With my commit selected, Xcode shows me a comparison of the two historical versions of my document. The highlight colors change to purple and orange, corresponding with the commits displayed in the bottom bar. As before, I can jump between changes using the stepper control.
I can see the comparison either in-line or side-by-side. When I’m done exploring this comparison, I can quickly snap back to my most recent changes using the Reset button in the bottom bar. Usually, the changes that I make to my apps span across multiple files. While it’s really useful to explore changes within one file, I often want an overview for all of the files that I’ve changed across my whole project. Thanks to the new Changes tab in the Source Control Navigator, I can see a list of all the files I’ve changed since my last commit. Clicking on any of them will automatically enter code review mode and show me all the changes that I’ve made in that file. I like to flip between the files to quickly remind myself of the other edits I’ve made. Now that I know why our app has this issue when displaying ingredients, I’ll go ahead and create a new branch with my changes to fix it. Creating and switching branches is something I do a lot, and Xcode 13 has a great new way to do that. Xcode’s toolbar now shows my current branch, which is a helpful reminder of what I was last working on. By clicking on it, I can quickly switch between any of the branches that I worked on recently. In this case, I’ll use the secondary menu to create a branch for my fix.
After exploring history in code review mode, I was able to come up with a fix for the bug. Now that I have a proposed solution, I want to get feedback on my code change. Since I’m not totally familiar with this part of the code base, I’d like my teammates to confirm that my changes won’t introduce other issues. To collaborate with my peers on a code change, I’ll create a pull request. I can do that right from Xcode 13 using its new integrated support for GitHub and Bitbucket Server. I can create my pull requests right from the source control popover. Xcode will create a draft pull request to merge with my branch into the default upstream branch, which in this case is main. I can prepare my pull request with information about the fix before publishing it. The changes that I’ve committed and pushed to my branch will show up in the Pull Request section in the Changes Navigator, giving me a preview of the changes that will be included once published. The Local Changes section lets me see files that won’t be included in my pull request until I commit and push them. When I’m happy with the contents of my pull request, I’ll give it a title and a description.
I’d like to ask a few teammates in particular to review this change, so I’ll click the Participants button and tag them as Reviewers.
As I wait for feedback and switch to other branches, Xcode figures out which pull request to display. Xcode will determine the associated pull request based on its source branch and your current branch. When you switch branches, Xcode will automatically discover existing pull requests. I published my pull request a little while ago, and my team has since left me some feedback. Let’s take a look at that now. With the pull request selected in the Changes Navigator, I can see an overview of my pull request and everything that’s happened since I published it. My team has left me some feedback on my code. I can reply to these discussions if I like or click «View Changes» to jump straight into the file in code review mode.
There are some great suggestions in here from Matt, and now we have the opportunity to have this conversation about my pull request in Xcode and connect it directly to source code. I went ahead and updated my pull request in response to the feedback. Now, looking at the comments that my teammates have left here it looks like they’re on board with my latest change. I see that my colleague has approved this pull request. Now I just need to check my status of our continuous integration workflow. Since I’m using Xcode Cloud, I can also see the status of my continuous integration workflows within the pull request’s CI popover. I’m able to quickly see a summary of my test results, and clicking on an entry will jump me straight into a detailed Xcode Cloud report. For more information about Xcode Cloud and running your code in CI, check out the session «Meet Xcode Cloud.» OK, since my teammates have all approved my changes and all of my Xcode Cloud jobs have succeeded, I’m ready to merge my pull request. I’ll use the Pull Request actions and select «Merge.» Xcode allows me to select a merge strategy which determines how changes are integrated into the target branch. I’ll choose the default, which will include a Merge Commit. You can also enter an optional commit message, but I’ll leave it as it is. Everything looks good, so I’ll merge it now.
Now that I’ve merged my pull request, it’s time to switch back to other work. Just like I find it helpful to ask my peers for their feedback, they often ask me to review their changes, too.
In addition to branches I’ve worked on recently, the source control popover also shows me the pull requests that are relevant to me. I’ll see the pull requests that I’ve created, but Xcode also shows me any pull requests that my teammates have requested I review. Looking in the source control popover, it looks like one of my teammates has asked me to do just that. Let’s check out their branch and review it. Just like with my own pull requests, I can see his overview, review status, and discussions on my teammates’ pull requests since I’ve been tagged in. Let’s take a look at their changes. I’ll step through the files in the Changes Navigator under the pull request node.
Clicking on any of these will snap me into code review mode, showing me the changes that will be applied if the pull request is merged. I can leave a comment for him inside the editor by secondary clicking and inserting a new comment on the line. I think I see a potential improvement in his code, so let’s leave a note for my teammate.
My feedback was pretty minor, and this pull request looks good to go. I’ll approve it using the actions in the top right.
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.