Since you are using Xcode13, the problem may not be because of the code signature of our apps(You can check your code signature if you want: https://developer.apple.com/documentation/xcode/using-the-latest-code-signature-format), but due to the code signature of one of the dependencies, and removing the dependency solves the problem. In my case, I remove the dependencies one by one, and eventually found that the culprit is FirebaseAnalyticsOnDeviceConversion.

I think you should use .jpegData(compressionQuality: 1) instead of .jpegData(compressionQuality: 0) if you don't want to compress the image.

This problem still persists in 2022. For an incomplete solution, we can set the document after viewDidAppear. private var isFirstAppear = true if isFirstAppear { isFirstAppear = false if let documentURL = Bundle.main.url(forResource: "Acupuncture Intake", withExtension: "pdf"), let document = PDFDocument(url: documentURL), let pg = document.page(at: 0) { pdfView?.document = pg.document pdfView?.autoScales = true pdfView?.backgroundColor = UIColor.lightGray pdfView?.displaysPageBreaks = true; pdfView?.displayMode = .singlePage } } The downside is that there will be a brief moment when the pdf view is empty until the document is set.

After some digging, I noticed that it's due to the pdf.scaleFactorForSizeToFit changes after viewDidAppear. That gives us two incomplete workarounds. Solution1. Save the pdf.scaleFactor after viewDidAppear and apply it from then on. So the display can be normal for the second time and so forth. Solution2. Disable autoScale and set pdf.scaleFactor = pdf.scaleFactorForSizeToFit manually. The downside is that the scale won't be perfect.

I've encountered the same issue twice. The first time is the same as others, the iOS versions of targets don't match. The second time happens after I merged my intent handler targets into one. I accidentally typed SelectTimerIntent() instead of SelectTimerIntentHandler() when redirecting which handler to use, and the compiler still compiles so it took like an hour to find out after using the breakpoint 😓

Hi! The same issue happened to me before. The issue happens when we return an emtpy array for the function entities(for identifiers: [String]). In my case, I forgot to add one missing entity which was additionally added in the suggestedEntities. This may not be the cause of your issue, but I hope it can help you find some clues. 🙂

Here's a workaround I use. Give the Text a fixed width according to the end date. Use minimumScaleFactor to prevent the given width truncating the text. The downside of this approach is that the width won't update as the timer counts down to less digits. Example code and ref: https://stackoverflow.com/a/76861806/11153088

You can use Text("Only \(Text(endDate, style: .timer)) mins left to add") .monospacedDigit()

Perhaps try to check your deployment version. This could happen if your iPhone iOS version is below iOS17.0, while your app targets iOS16.0 and the app extension targets the latest default version, which is iOS17.0. The extension wouldn't run because the deployment version not matched. Happens to me all the time 🙄

I'm not sure why issue1 and issue3 are caused. But as for issue2: You mentioned: "In addition, I should mention that, with each iteration through the eventDidReachThreshold callback, I increment the threshold by 2 minutes and restart the monitoring. " Note that the activity duration is calculated using the given time interval. (00:00 to 23:59 in your case) So if the the the duration has exceeds the given threshold when you call 'startMonitoring', the eventDidReachThreshold callback will be called immediately. This may be why you see the eventDidReachThreshold callback got triggered multiple times since you're monitoring recursively.

By any chance you're recursively setting another threshold monitoring upon threshold reached?

It's now possible to use transformable(by:). @Model final class Profile { @Attribute(.unique) let id: UUID var name: String @Attribute(.transformable(by: UIColorValueTransformer.self)) var uiColor: UIColor var color: Color { get { .init(uiColor: uiColor) } set { uiColor = .init(newValue) } } init(id: UUID = UUID(), name: String, color: Color) { self.id = id self.name = name self.uiColor = .init(color) } } @main struct MyApp: App { init() { UIColorValueTransformer.register() } } The transformer code can be found here: https://www.avanderlee.com/swift/valuetransformer-core-data/

I've had this similar issue and made a bug report with a sample project replicating the same issue. FB13492170

I can confirm that the issue exists for iOS17.0.1 and macOS14.0. However it is fixed for iOS17.1.2. (I didn't update my mac to test.) So if we are targeting iOS17, we must make our relationship instances optional and set the values after the instance is initialized as Diethus showed in code. Additionally, we can combine implicit unwrapping, so the callers won't notice it's an optional. class MyItem { var name: String private(set) var item: Item! init(name: String, item: Item) { self.name = name // relationship attributes must be set after the instance is initialized. self.item = item } }

Hi! Thank you so much for confirming it's a blocked main thread! It turns out I was silly enough not to realize I need to toggle the Thread track button to see the Thread graph. So it IS a blocked main thread. However, the Narrative view only shows one of my function causing the issue but doesn't specify which line is the cause. I've scratched my head for hours, but couldn't understand why. The function is basically reusing the WKWebView for using it in SwiftUI UIViewRepresentative, which should only use the main thread, isn't that it...? Is there a way to let the instrument tell us which line is causing the blocking?