Hi, everyone. I'm trying my first TimelineView with an explicit schedule, but my attempt – and even the simple example from the documentation – doesn't seem to work as documented. Here's what the documentation says an explicit schedule does: The timeline view updates its content on exactly the dates that you specify, until it runs out of dates, after which it stops changing. And it gives this example: let dates = [ Date(timeIntervalSinceNow: 10), // Update ten seconds from now, Date(timeIntervalSinceNow: 12), // and a few seconds later. ] struct MyView: View { var body: some View { TimelineView(.explicit(dates)) { context in Text(context.date.description) } } } There are stipulations about what the view – which always displays some version of its content body – will do given only past or future dates, but it seems clear we should expect the view in this example to redraw at least once after it appears. Here's the rest of the discussion from the documentation with my comments after testing what's stated: If the dates you provide are in the past, the timeline view updates exactly once with the last entry. That seems true, considering the "update" to be the initial draw. If you only provide dates in the future, the timeline view renders with the current date until the first date arrives. Not exactly: it looks the "date" property of the initial render is the (future) date of the first schedule entry, even though it's drawn early. When the first date does arrive, the body closure doesn't seem to be called. Only on the next date, if there is one, is it called again. If you provide one or more dates in the past and one or more in the future, the view renders the most recent past date, refreshing normally on all subsequent dates. That also seems correct, except… … that in every scenario, the final date entry seems to be ignored completely! In other words, unless all date entries are in the past, the Timeline View stops before it runs out of dates. That documented example from the start, which we expect to redraw at least once after it appears? When I test it in a Playground, it appears, but doesn't redraw at all! So, that's my main point of confusion after experimenting with TimelineView for the first time. I can achieve my own goal by appending an extra entry to my explicit schedule – even appending an entry identical to the previous "final" entry seems to work – but naturally that leaves me unclear about why I need to. If anyone can tell me what I'm not understanding, I'd be grateful.

Hi, colleagues: I've spent days trying to understand this little SwiftUI layout problem, and I've made a minimal test app to explain it. It's based on a Content View of a fixed size. import SwiftUI @main struct TestApp: App { var body: some Scene { WindowGroup { ContentView() } .windowResizability(.contentSize) .windowToolbarStyle(.unified(showsTitle: false)) } } struct ContentView: View { let complaint = """ What's with the vertical space \ around me when I'm \ in a detail column? """ var body: some View { Text(complaint) .font(.title) .frame(width: 300, height: 300) .background(.blue) } } And here's the result. As expected, the Content View is hugged nicely by the window: My goal is to place a fixed-size view like this in the detail column of a Navigation Split View. So I update the scene's root view: import SwiftUI @main struct TestApp: App { var body: some Scene { WindowGroup { NavigationSplitView( sidebar: { }, detail: { ContentView() } ) } .windowResizability(.contentSize) .windowToolbarStyle(.unified(showsTitle: false)) } } struct ContentView: View { let complaint = """ What's with the vertical space \ around me when I'm \ in a detail column? """ var body: some View { Text(complaint) .font(.title) .frame(width: 300, height: 300) .background(.blue) } } And we get the following. This is the window at its minimum size: I expected the Content View to fit perfectly within the detail column, but as you can see, we have mysterious vertical spaces above and below it. My first guess was that these spaces were some kind of context-dependent default padding. Eventually, I noticed the combined heights of the mysterious spaces equalled the height of the toolbar. I even checked this by using other toolbar styles with different heights – the spaces always adjusted to equal the toolbar's height. At this point, I was guessing this had something to do with the "safe area" – macOS sometimes treats the toolbar as an area underneath which content can lie, so it might be well-meaningly but redundantly adding the toolbar's height to the detail area or something, and there might be some modifier that will opt out of that behaviour; perhaps ignoresSafeArea(). But nothing I've tried has helped. I've tried a number of other solutions, but none is ideal, and none help me understand why SwiftUI is adding this vertical space to begin with. Any insight would be very much appreciated.

This question is mainly just a point of curiosity and education. I'm working on one of my first macOS apps, and I see I can check NSApplication.shared.windows to get a list of all the application's windows. Most of the time, this list contains the windows I've programmed which are in memory. Sometimes, though, it also contains two instances of NSMenuWindowManagerWindow. This doesn't appear to be a documented type, and I'm inferring I'm seeing evidence of something NSApplication or the system is doing to help deliver or render some kind of standard application behaviour. I'm wondering whether any macOS gurus (or engineers) can shine some light on it.

Erratic behaviour developing a game on the Mac. I'm using and building for the current (non-beta) version of everything as of this date: macOS Catalina 10.15.6, Xcode 11.6. I can build and run and test the game normally, until for whatever unknown reason, the game begins freezing every time at the point I try to authenticate. I've narrowed it down to this by using the following bare-bones invocation just after app launch completes: print("A") GKLocalPlayer.local.authenticateHandler = { vc, error in print(vc) print(error) } print("B") Sure enough, "A" is printed, and then execution stops. Activity Monitor lists the app as "not responding," and I have to force quit and restart the Mac before I can successfully run and test the app again. (Or if I'm not interested in testing Game Center features, I can comment out this authentication block and everything works fine.) No problems with any of this when testing the same project built for iOS. Has anyone got any notion of what could be happening here?