tip on filtering the Issue Navigator inspired me to share a technique for navigating Xcode that saves me time.
There’s a wealth of genuinely helpful functionality in navigator-pane filter bars, and one I use all the time is in the Project Navigator filter field’s “Show only files with source-control status” feature.
I don’t use Xcode for source control tasks, but that button is still useful. It filters the Project Navigator tree to contain only modified and uncommitted files, which, by definition, are often the files you’re working with. I find that filtered view combined with “Open Quickly…” to open new tabs with unmodified files to be a powerful combination of always having the file you need within reach. I find having lots of open editor tabs confusing, so I close them reasonably often, and the filtered Project Navigator is an excellent summary of contextually important files.
Then, once I make a commit, I commonly modify the same files I have open in tabs as I continue on my branch, returning them to a modified state and bringing them back to the filtered Project Navigator.
This works exceptionally well if you like committing smaller changesets, but even if you prefer working with larger commits, you’ll still be looking at a much smaller set of files than an unfiltered tree!
Anyway, that’s my practical tip for today! I hope it’s helpful. Next, I need to learn to summarise this in two pictures, like Dominik does!
Dave Verwer
AppSweep by Guardsquare helps developers automate the mobile app security testing process with fast, free scans. By using AppSweep’s actionable recommendations, developers can improve the security posture of their apps in accordance with security standards like OWASP. Get started now.
A new version of Dash is always a happy occasion, and this one is no different, with a major focus on better search in the app. It’s an essential part of my everyday toolkit.
This article from Manu Herrera has some great tips for speeding up your project’s compile times. It covers everything from using the “Recent Build Timeline” assistant view in Xcode to identifying slow-to-compile code using SwiftLint.
Of course, it means you’ll no longer have this excuse, so… you know… pros and cons. 😂
Apple has a well-written guide and some sample code for Migrating from the Observable Object protocol to the new Observable macro, but what if you didn’t want to do that work manually? Brian Capps has a new SwiftPM command plugin that you can install, run once to convert your code, then remove from your project!
What’s the easiest way to find out if you are using one of the new required reason APIs? It might be the technique that Marco Eidinger outlines in his most recent article. His script might be helpful in CI, too.
Have you tried adding Codable to a SwiftData model yet? Donny Wals did and has written up why it doesn’t immediately work and how to get it to a place where it does. He even covers how to deal with codable SwiftData relationships.
Software Engineer, macOS @ Raycast – Build something you actually use. Ship every two weeks. No bureaucracy bs. Hack on ideas every Friday. Location-independent salary. Remote, UTC ± 3 hours. – Remote (within European timezones)
Is your company hiring? List your open Swift and Apple platform positions for free with iOS Dev Jobs.
How UITableView
really works, and how it really, really works! 🚂