What’s the difference between presentedWindowStyle(_:) and windowStyle(_:)?

Well, one does something, the other doesn’t, basically.

I tried using the former, and observed that it never has any effect. I filed FB14892608 about it, a month ago. While the long delay isn’t great, the response I got today was actually pretty helpful:

We’re sorry you ran into trouble with that API.

To adjust the style of a window group’s windows, you have a couple of options. If all of the windows in the group should have the same style, then using the windowStyle() scene modifier is what you want:

struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .windowStyle(.hiddenTitleBar)
    }
}

If you need to adjust the style on an individual basis using state for that window, there are also some related view modifiers:
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .toolbar(removing: .title)
                .toolbarBackgroundVisibility(.hidden, for: .windowToolbar)
        }
    }
}

A simple apology followed by clear and specific instructions on how to actually achieve what I wanted. I genuinely applaud Apple – or perhaps I should more specifically thank the individual(s) within DTS that actually provided this response. Either way, it was a very pleasant surprise.

Now, it still leaves unanswered the question of what presentedWindowStyle(_:) is supposed to be for, and in what situations it actually does anything. So not a perfect reply, per se, but really the proper solution for that is either:

1. Fix the API to not have such confusingly similar modifiers.
2. Improve the documentation to:
   • Explicitly point out the other, similarly-named modifier.
   • Distinguish them.

Currently the documentation is just:

Versus:

The latter might technically convey something important here, in the created by interacting with this view part, but so much in SwiftUI is modifiers stuck haphazardly in weird and arbitrary places, that I’m been conditioned to ignore the fact that I’m often applying modifiers to views that don’t actually affect those views. And for all I know in SwiftUI parlance views do “create” and/or “interact” with their parent windows (a lot about SwiftUI is backwards, part of its nature as a declarative API).

Especially if that’s the first candidate API you stumble across, when searching for a way to style a window, it’s very easy to presume it’s the right API. Why would there be multiple APIs for styling the window; why would you continue searching after finding one?

Similarly, the presentedWindowStyle(_:) variant is the only one that appears in Xcode’s auto-complete if you try to add the modifier to your main view, which is both where you sometimes have to add window-level modifiers and also just a really easy mistake to make (instead of adding the modifier to the WindowGroup, one indentation level up).

Lastly, it doesn’t help that I can’t find any situation in which presentedWindowStyle(_:) has any effect, even knowing it’s not intended to style the parent window. One might assume it’s somehow related to sheets or somesuch, but apparently not? Presumably I’m overlooking some use-case – or maybe it doesn’t actually do anything on macOS, only iDevices? I welcome clues or tips.

I’m very glad Apple’s Messages team somehow snuck this one little button past the corporate bureaucracy (Apple infamously likes to pretend their software is infallible and therefore doesn’t need things like useful error messages or rectification tools).

It’s of course not great that iMessages don’t reliably sync between Apple devices to begin with, but at least there’s a simple way to fix that when it occurs.

In case you’re unfamiliar with it, this button is in the “iMessage” tab of the Messages Settings – although placed dangerously close to the “Sign Out” button. 🤨

…after I’d filled out a form PDF that was emailed to me. It had exactly the option I wanted first and foremost, to send the completed PDF back to the sender.

Sure, manually digging up the completed PDF from disk and dragging it into a Mail Compose [Reply] window isn’t hard, but it just feels so thoughtful when the system saves me the effort. Knowing that someone, somewhere, actually thought through how Mail & Preview might be used, and thought enough of their users to go to the trouble of implementing this.

Kudos to whomever was behind this sweet little feature.

Universal Clipboard basically just means you can copy something on one device and paste it on another, as long as they’re physically near each other and signed into the same Apple ID. There is no step 3.

It’s such a beautiful feature, in concept and execution. Admittedly most of the time I use it merely to shuffle authentication codes from my iPhone to my Mac, but still – I love not having to temporarily memorise arbitrary numbers and then type them in manually.

I think what really elevates it to perfection is that it works. It sounds like such a vapid point, but it really makes all the difference. Nominally Universal Clipboard is just one of a family of similar features, under the Continuity moniker, but it’s the only one that actually works reliably and predictably. The only one!

Many of the other Continuity features are similarly great in concept, but just don’t work reliably. SMSes sometimes don’t sync to my Macs. AirPlay sometimes just won’t connect, or the video quality is comically bad. Unlocking my Macs with my Watch is a guessing game as to whether it feels like working today. AirDrop is so fussy and unreliable that it actually gives me anxiety if I even think of using it.

I wish Apple’s products had more features like Universal Clipboard.