If you're not writing command line programs (99% of what I do) I suggest adopting SwiftUI for your interface.
It's Apple's future for cross platform (ios/macos/watch) applications. Hardcore longtime mac devs find it frustratingly unable to do some complex things they want to do (and yay that they do!) to take advantage of the mac OS. But you don't want that; you just want to interact with your own code. And SwiftUI will let you do the basic stuff easily...and likely just (well, almost just) recompile your program for your iphone or ipad.
Yeah, macOS development is in a tricky spot at the moment: Apple has signaled that SwiftUI is the future, and so starting out with ObjC/Cocoa is making yourself obsolete right from the get-go, but SwiftUI is not production-ready yet and doing anything serious with it is difficult if not impossible.
Presumably in a few more years the wrinkles will be ironed out of SwiftUI, but right this instant is unfortunately a crummy time to start out with Mac development. I would also agree that you should start with SwiftUI, but just with the awareness that it sucks ass and that you'll have to throw out most of what you write over the next few years.
I wouldn't worry too much about AppKit going anywhere any time soon. It's probably in a similar position to where Objective-C is, where it's not receiving a whole lot of additions/iterations, but it'll stick around for years to come because of how much of the OS and how many third party apps still rely on it. It's a good idea to become familiar with SwiftUI but I think Cocoa is in a much better position than say Carbon was several years ago.
It's possible to wrap UIKit in SwiftUI (using UIViewRepresentable and UIViewControllerRepresentable), to do the things that SwiftUI can't yet do by itself. Those deficiencies will slowly be filled out, of course - there's no reason to stay exclusively with UIKit any more.
More significantly, SwiftUI introduces a new declarative paradigm - very different from what was before. It makes a lot of previously laborious things, easy.
So, yes - SwiftUI is the way to go, and it's ready to use now.
What sort of complex things are they unable to do? Is there any recourse? Can you use SwiftUI for the majority and dip into something lower level when needed?
SwiftUI's weakness on macOS and to a lesser degree iOS is that it's difficult to fine-tune things to the extent that many longtime Apple platform devs traditionally have. It can usually meet the base case but it makes honing in on the fine details and achieving a high level of polish cumbersome.
There's also some things, particularly on macOS, that you're going to need to drop down into AppKit to do, which is possible thanks to NSViewRepresentable/UIViewRepresentable, but a bit frustrating is necessary.
Personally speaking I'm still limiting usage of SwiftUI to views that are either simple or don't have much in the way of user interaction. It's decent at that, but for most other things I'm using plain old AppKit/UIKit. SwiftUI is still green compared to AppKit/UIKit's multi-decade legacy, so hopefully it will improve in the coming years.
Was looking at making something that would interact with SystemConfiguration.framework and registers itself on the DynamicStore's callback (something akin to dns-heaven[1]). From the introductory tutorials included with xcode I have no idea what is the equivalent to applicationDidFinishLaunching() where this kind of things would be put.
It looked like maybe BackgroundTask is what I'm looking for, but it seems arbitrarily limited on macOS to an urlsession, whatever that is ?
It's Apple's future for cross platform (ios/macos/watch) applications. Hardcore longtime mac devs find it frustratingly unable to do some complex things they want to do (and yay that they do!) to take advantage of the mac OS. But you don't want that; you just want to interact with your own code. And SwiftUI will let you do the basic stuff easily...and likely just (well, almost just) recompile your program for your iphone or ipad.