calendar

Same issue. The same problem. Sometimes at work, but more often while sleeping. panic(cpu 1 caller 0xfffffe001a88ac50): skr.txausd.upipe:533:IDSClientChannelNexusOS: skr 0x0xfffffe24eead1c00 sg 0x0xfffffe24e43edea8 (idx 0) unable to satisfy mandatory allocation Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 23B81 Kernel version: Darwin Kernel Version 23.1.0: Mon Oct 9 21:28:12 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 7BF1E8441DE38056EC1FDED67A9F101B Kernel UUID: 24DA617C-1A30-3D13-A4BB-7BF37E60644E Boot session UUID: E59838AD-1CA8-488B-8E0A-392D8116B1BC iBoot version: iBoot-10151.41.12 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x0000000011d58000 KernelCache base: 0xfffffe0018d5c000 Kernel slide: 0x0000000011d60000 Kernel text base: 0xfffffe0018d64000 Kernel text exec slide: 0x0000000013264000 Kernel text exec base: 0xfffffe001a268000 mach_absolute_time: 0x16ca94ed494 Epoch Time: sec usec Boot : 0x655864aa 0x000ee

∙View can conform to Equatable... True, .equatable() is no longer required, not sure what version that changed in. . ∙When view contains @ObservedObject... False, regardless of the outcome of ==, body is always called when any @Published property of the object changes or objectWillChange is published. . ∙Does view, that is Equatable, need to care about equality of its subviews.. No, a subview will just follow the same algorithm. Best to only init a View with the data it actually needs and uses in its body to keep invalidation tight. . ∙When view returns true on equality check... True, if you returned true from == but had @Environment(.calendar) var calendar and the calendar changed the body would still be called. This is the same behaviour as @ObservedObject in the 2nd question. . ∙When the observed object conforms to Equatable... In my testing the if an ObservedObject conformed to Equatable the == func was never called. My test code: import SwiftUI import Combine struct ViewTest {

I experience the same. I think it is a bug because it used to be working fine prior to watchOS10. I have also tested a few of third party widgets and they have the same problem - not redacted when not worn. Only Apple's own widgets like calendar seems to be working just fine though.

From Protect user privacy with information property list keys: To access a person’s calendar events or reminders through EventKit or EventKit UI, your app needs to include descriptions for the following if your app links to iOS 10 or later, and runs on iOS 10 through iOS 16: NSContactsUsageDescription, as EventKit UI may need to access Contacts data to choose the correct display name or avatar for a contact in a calendar. Warning If your app that’s linked on iOS 10 through iOS 16 doesn’t include these keys, your app crashes.

See TN3152: Migrating to the latest Calendar access levels and TN3153: Adopting API changes for EventKit in iOS 17, macOS 14, and watchOS 10 for details.

Be sure to read TN3152: Migrating to the latest Calendar access levels.

I found the apparent cause, by creating a new project containing the simplest possible code to try to replicate this issue, and gradually making changes to replicate specifics of the code usage in my app. It seems that creating and using a second instance of EKEventStore was the cause of the issue. In previous macOS versions this did not cause any problem, and appeared to be valid usage. However, I have apparently been able to resolve the current problem by ensuring that I create and use only a single instance of EKEventStore in my app. Although the second instance I was creating on the fly does contain all the same EKSource entities, and used to return the same calendars in a call to calendarsForEntityType, it now it does not return any calendars at all in a call to calendarsForEntityType. I would suggest that this is a bug. Perhaps EKEventStore should in future be given a shared singleton property in the API.

You are not alone about this : Hello, Upon further review of the activity associated with your Apple Developer Program membership, we have determined that your membership, or a membership associated with your account, has been used for dishonest or fraudulent activity. Therefore, your Apple Developer Program account has been flagged for removal. Specifically, we found that your account is associated with terminated developer accounts, or accounts pending termination, in direct violation of section 3.2(f) of the Apple Developer Program License Agreement, which states: “You will not, directly or indirectly, commit any act intended to interfere with any of the Apple Software or Services, the intent of this Agreement, or Apple’s business practices including, but not limited to, taking actions that may hinder the performance or intended use of the App Store, Custom App Distribution, TestFlight, Xcode Cloud, Ad Hoc distribution, or the Program (e.g., submitting fraudulent reviews of Your own Application or any thir