PDFViewScaleChanged is fired when scaling manually at the end of the zoom process. . It is not invoked when changing the zoom i.e. by using a double tap. Seems like a bug to me.

To the best of my knowledge this will not work, at least I have never managed to pull this off ;-)The layers are composited within the view in the given mode, but the views are then composited just based on the resulting alpha.So, what can you do to achieve what you are trying to do? Basically, you have to work with multple Layers within the same view. CALayers are generally worth diving into, especially CAShapeLayer provides a high performance GPU driven way to draw with shapes.Hope it helpsKlaus

Note that for iPad OS 14, using key paths will lead to a crash, because the changed control does not have that key path "highlightsToday" anymore: datePicker.setValue(true, forKeyPath: "highlightsToday")

Why should the ColorDetail pop the view, when you are just resetting the selectedView state? To pop you have to dismiss the presented View like so: struct ColorDetail : View { //get the presentation mode from the environment:     @Environment(\.presentationMode) var presentation     @Binding var selectedView : Int?     var color : String     var body : some View {         VStack {             Text (color)             Text ("SelectedView: \(selectedView ?? 99)")             Button ("set SelectedView to nil and go back")             {                 self.selectedView = nil //Pop the detail view:                 self.presentation.wrappedValue.dismiss()             }         }     } } Hope it helps Klaus

On Mac OX the code works fine, but if you run it on the iPad Playgrounds, and increase duration (i.e. to 4) and set autoreverse to true in line 18, then you realize that there is a secondary animation which overlays the rotation. Looks like a bug to me, or at least an inconsistency.

First you need to refactor your data interface to use either @Binding, @Environment, @EnvironmentObject or @ObservedObject, because this line: let posts = Data.posts() just statically instantiates your posts once. In the block/closure that handles .pullToRefresh, which right now just toggles the state of isShowing, you invoke call the func to load further data. The response to this method needs to update the data model you referenced in the first step. The UI is then refreshed automatically. Hope it helps

This seems to be an issue of the underlying PDF document. I find the same error message in specific documents that also seem to abort the rendering process. Nonetheless, I would be happy to learn more about that error message, and especially how to avoid it in PDF creation.

This is a complete mess. It can not be controlled, and documentation of this use case is pretty nonexistent. I'm tying to use an SwiftUI framework on Mac that has many dependencies to UIColor, so Mac Catalayst is the only way to go. Trying to get that running with the Document based App template is a total mess, and the focus issue complete destroys the interactivity of the interface randomly. Drag operations seem to be particularly vulnerable.

Re A: It seems that this is the rather buggy focus system on Catalyst. Basically that log entry means that your app technically has lost the focus – though there should no reason for it. However, certain drag and drop functions or SwiftUI buttons cease to function then, which makes part of your UI unresponsive.

Same problem here. I would really appreciate any efforts of Apple to document what these kind of error messages mean.

I had that issue in a legacy project when macOS was added as a run destination, I think as a side effect of an Xcode update . Removing macOs from the supported destinations in the General tab of my target fixed it for me.

Same issue here, and beside the issues mentioned already, this is quite a pain of you have a number of potential devices to run on. While previously devices were automatically switched when connected via cable, now I always have to select them in the menu. Which can be quite bothersome, if you have multiple similar devices. Cable debugging was always way faster than remote debugging, and I really do not understand why Apple is fixing something that was not broken.

Xcode won't display README for Swift Packages on PRIVATE repos. It's really as simple and dumb as that. While the package manager finds and loads your package just fine from private repos, the element displaying the repo operates under the assumption that the README can be read without authentication.

Disabling Live Issues obviously prevents just the display w/o addressing the root cause. There seem to be some kind of error cache, which is not properly reset. This is an Xcode bug.

This is a classic XCode bug, still happening with XCode 15.1. The only way I have found to fix it is to delete derived data