.png){kind=logo}
I'll start with this because I feel it makes a difference in testing the build condition codes. Now, with Xcode 15, the code that doesn't satisfy the build conditions will be grayed out. This will definitely boost productivity.
Xcode 15 brings us a preview with the keyword #Preview; just add it and it’s done. Xcode gets rid of the old PreviewProvider syntax and more. Now, not only Swift UI, but UIKit views also have the advantage of seeing the live Preview. Let me provide an example from a UIKit View:
UIKit previews can only be seen for code written; they can't be seen for the Storyboard or Xib. Another surprise is that we can change the device for the Preview as well.
And for SwiftUI, the only change is the code syntax. Here is the snippet:
#Preview {
PagingView() // Where PagingView is the SwiftUI View.
}
A beautiful update; from now on, there's no need to use strings for your assets separately. This eliminates the potential for typing errors and removes the need for a custom script. Xcode 15 will handle this for you. It's a really great add-on. When you add any asset, Xcode will create an enum for you. And it’s not limited to images alone; it also works for color assets.
In the example, I’ve added assets shown in the screenshot above with different naming styles, and Xcode shows me their filenames as autocomplete options. The good thing is that it has backward compatibility as well.
It also works for standard UIKit projects. Here's the code snippet:
view.backgroundColor = UIColor(resource: .customPrimary)
view.backgroundColor = .customPrimary
// Either way would work.
It is always a good practice to add documentation for protocol methods, custom classes/structs, properties, etc. Here too, Xcode brings a gift: we can preview the documentation as well. Yes, not only the code, but documentation can also be previewed for each change. To enable it, go to Editor -> Assistant and choose "Documentation Preview" from the menu.
We can also attach videos and images along with our documentation file. No worries, the image media file would be only for documentation purposes. It is not built with the .ipa archive.
Along with this, Xcode has also improved the documentation style in the IDE itself:
Xcode 15 has come up with an update in the source control as well. Since earlier versions already supported GitHub actions, this time it adds a visual update of all changed files in one place. Along with that, it shows staged and unstaged changes previewed in the same section with visual identifications. The next level is that it allows the developer to make changes there itself if needed. You don’t need to go to the parent file to make the update. Commit and other git activities can be performed from the Xcode source control itself.
Here is the big change that makes the developer’s life much easier. Now, there's no need to check and compare different files; all are in one single file. Xcode 15 introduces a String catalog file. It also helps to check what percentage of localization has been done. The amazing thing is that Xcode selects and writes all localized strings for you; you don't need to worry about writing them manually.
Another great update is that it allows the developer to migrate the existing string file to the string catalog. Just right-click the localized file and select Migrate to String Catalog from the menu.
On the right side, you can see a “State” column indicating if the string needs to be localized, if it's new, or even unused in your project.
For UIKit, you have to use the localized string as `String(localized: _)`, and for SwiftUI, it's like a normal string; there's no need to mention the "localized" keyword.
But wait, there's more! Xcode now provides more information about localizations. It shows 4 different states for each string — NEW NEEDS REVIEW DONE, and STALE. It's very evident what each state means, so I won't go into explanations. I just want to add that another amazing update is that developers can choose to select device-based control for each string. Right-click the string and choose Vary by Device and select your device.
Not only the features, but we also have more filtered logs and context that can help us in debugging too. We already have the OSLog framework, which is quite useful, but this time it has been extended to another level. Xcode 15 allows us to set new log values with filters, which make the debug area beautiful as well as useful. We can set different logs with different tags and types, and the same way from the debugger, we can filter them. The screenshot below will explain more
logger is simply an instance of Logger, and it allows us to set different types of logs. Along with that, in the debug area itself, we can filter the response based on those tags. Let’s say we have a type filter as follows:
Debug covers—Debug and Trace
Error covers — Error and Warnings, etc.
Xcode allows us to filter the logs from a huge log range to a filtered one only. Also, the logs can have highlighted colors as well, based on the info type. As you can see, the error and warning types are highlighted in yellow.
var logger = Logger(subsystem: <#T##String#>, category:
<#T##String#>)
This is something that should have come first, but I was lacking more discovery in this section. So, I'm keeping it here since we have very few use cases for now.
It seems Apple has started introducing AI in the Xcode tool. Let's say a developer creates a Swift file named XYZViewModel, and initially, the file has nothing inside other than the `import Foundation framework. So, as soon as the developer starts to write the file name, Xcode populates auto-complete suggestions following the file name.
Along with that, any renaming of a file, let's say assets, will cause the old name to start showing issues since the file was renamed to the new name.
While designing UI components, Xcode starts suggesting appropriate values auto-filled in dimension modifiers, such as cornerRadius, width, etc. Xcode auto-populates the next modifier based on the earlier used ones, and with the help of the tab key on the keyboard, it's done.
Xcode 15 brings bookmarks. The bookmarks are not the same as TODOs or other pragmas that we are already using. It's more like remembering something for later, and I feel this invention is better. Marking a bookmark is very easy; just right-click the line and add it to the bookmark. Also, the behavior is not different from web bookmarks.
Xcode will allow you to segregate the bookmarks and add them under a group/folder. Clicking them will take you to the exact line of code. On completion, you can mark them as done, remove them from the list, and reorder them, etc.
Now, it's easy to segregate all the TODOs, warnings, and pragmas under a bookmark and track them. In the following screenshot, I added a bookmark just to showcase it.
Furthermore, you can also change the description (double-click the subtitle) of each bookmark. In the screenshot, if you notice the TODO bookmark, I changed the description to Add documentation to make my bookmark more precise and descriptive.
Testing also has a noticeable update in Xcode 15. Now, we have more visual data on test functions, reports, performance parameters, etc. Xcode 15 also allows disabling or enabling only specific tests to run. The same goes for modules (Unit tests, UITest, TargetBasedTests, etc.). And for all of this, developers have one single window to review and control. To jump to a function, it's just a click away. These changes are very useful in bigger and more complex projects. The update also allows the developer to see the impact of big tests, performance level tests, etc., all from a single window.
I won’t say I have covered everything here. This is a high-level update that I have explored. I am closing it here with my concluding comments.
Feedback is appreciated; anything under the Milky Way.
Happy Coding!
