It's really easy to write higher level abstractions that are specifically tailored for how you want to use them. For example at my previous workplace, I created a wrapper for having a table of elements with different sections because AppKit and UIKit indexes the data differently, one uses an array of arrays with separate section headers, the other uses a flat array that also includes the section headers.
Phone and Desktop layouts are usually different. For example a table of data on phone is most often displayed as a single column vertical stack while on desktop, it's a grid where the user can reorder/hide the columns. So if you are creating an application with non-minimal effort then you would have to write the same components multiple times anyways. If you set up your higher level abstractions properly then the UI part of the code shouldn't take much effort. This is also true for SwiftUI, if you pretend that every new screen can only use Apple's building blocks and none of your own, then you are going to have a bad time either way.
There is Catalyst, although I haven't tried it and since mobile and desktop need different layout and the UI code is not the bottleneck, I wouldn't want to try it either. (Edit: also, cant arm macs install iOS apps, if the developer enabled it, and use them kind of like using the simulator?)
Also I have used SwiftUI apps on iPad that felt like a bad cross-platform app that the developer never tried on iPad. (Don't want to name and shame, since they were all free apps)
something something, talk the talk, walk the walk