I've got the exact same issue ! Same configuration exactly. Globally I've witnessed some weird lags with this laptop even when playing videos on VLC. I hope they fix it in a future update. Have you found any possible reason for these lags on your end ?

I was tempted to use os_log in future developments but it's still a pain to retrieve logs remotely. We actually have this framework on MacOS but it requires admin permission : https://docs.developer.st.apple.com/documentation/oslogFetching logs limited to our app process should be possible both on MacOS (without admin rights) and iOS. Is there any enhancement scheduled on the topic ? There's also https://github.com/apple/swift-log but it seems to be in its development phase and intended to provide a simple API facade.Thanks in advance !

A quick update on these Combine investigations 😉I replaced the flatMap by the combination of map & switchToLatest (the equivalent of flatMapLatest in RxSwift)It solved the problem at first but this revealed what seems to be an issue with switchToLatest as soon as the publisher built in the map method does not produce synchronously. In this case, nothing arrives in the sink : no values & no completion.C.cancellables.append( Just([String]()) .print("Just 1") .map { _ in Just("value that never arrives").delay(for: .seconds(3), scheduler: DispatchQueue.main) } .print("map") .switchToLatest() .print("switchToLatest") .sink(receiveCompletion: { _ in print("completed") }, receiveValue: { print("received \($0) !!!") }) )Console output shows :map: receive subscription: (Just) switchToLatest: receive subscription: (SwitchToLatest) switchToLatest: request unlimited map: request unlimited map: receive value: (Delay<just, os_dispatch_queue="">(upstream: Combine.Just(output: "value that never arrives"), interval: (extension in Dispatch):__C.OS_dispatch_queue.SchedulerTimeType.Stride(magnitude: 3000000000), tolerance: (extension in Dispatch):__C.OS_dispatch_queue.SchedulerTimeType.Stride(magnitude: 0), scheduler: <os_dispatch_queue_main: com.apple.main-thread[0x7fff9c1d4680]="{" xref="-2147483648," ref="-2147483648," sref="1," target="com.apple.root.default-qos.overcommit[0x7fff9c1d4b00]," width="0x1," state="0x001ffe9000000304," dirty,="" in-flight="0," thread="0x307" }="">, options: nil)) map: receive finishedDo you think this should be reported as a Combine bug ?Thanks againEDIT :The last version of iOS (13.4.1) and MacOS (10.15.4) fixed this last issue. However a crash was introduced in Combine as this code crashes :Just(()) .map { _ in Publishers.Zip(Empty<string, never="">(completeImmediately: true), Just(())) } .switchToLatest() .sink(receiveCompletion: { _ in }, receiveValue: { _ in })I filed a feedback : FB7668667

Most annoying bug of XCode 12 so far. Please fix this in XCode 12.5 😅

Hello ! I know this question is getting old, but we're bumping into this issue as well. After migrating to XCode 13, it became mandatory to set APPLICATION_EXTENSION_API_ONLY to true in build settings of our widget extension. However, as stated above, this renders the isProtectedDataAvailable property unavailable through UIApplication.shared So I have 2 questions : Is there any new way of accessing it cleanly with iOS 14 or 15 ? In the meantime, is it acceptable to use this ugly hack or can this be seen as accessing private API & subject to app rejection 🥶 ? func isProtectedDataAvailable() -> Bool {   let application = UIApplication.value(forKeyPath: #keyPath(UIApplication.shared)) as! UIApplication   return application.isProtectedDataAvailable } Thanks in advance Bioche

Thank you for your answer ! Can you explain more about why your widget extension needs this? It's not a WidgetKit extension but an old Today widget that's presenting a remote control of an IoT vacuum cleaner (start / stop etc...). These commands can only be sent if the phone is unlocked because we need to access protected tokens in keychain. That's where isProtectedDataAvailable comes in. By "modern widget", I assume you're talking about WidgetKit. Unfortunately, we can't switch to this for now because of its limitations, mainly the fact that you can't interact with it without opening the app :/ Thanks again Bioche

If you try to send a command and the device is locked, data protection will prevent you from accessing the keychain items and you’ll get a reasonable error. What do you need the notification for? I think the reason the code was done this way is because IoT framework we're using may not be giving a descriptive error but I agree it would be the cleanest solution. Anyway I fear this little extension might be short-lived given the warnings telling us to move towards WidgetKit which sadly can't be used for this kind of widget for now ;) Thanks for the quick & helpful answers ! Happy holidays Bioche

Thank you for your quick response ! In general any additional steps or friction implementation before a purchase that doesn't add value or functionality may impact the customer buy experience. I think we can manage to avoid user login when buying packs but we will have more trouble for the meal planification feature as it needs to be linked to the user profile. I understand it adds friction and will potentially deter users from buying but is it a reason for rejection on Apple's side ? Thanks Again

I have kind of a similar issue on XCode 14.2 with warnings. When I clean & build from scratch, I get all the warnings as it should. But after one or 2 rebuild, all warnings in my local packages disappear. I hope it gets fixed in next version of xcode as this renders cleaning warnings especially difficult on large projects ....

Two years later, sadly still doesn't work on XCode 14.2 / iOS 16.2 ...

Any news on this from Apple ? You can apparently fix by bumping minimum version in the framework info.plist but it doesn't make much sense ...