Hi, I need your opinion about an issue we faced while trying to implement an iOS widget in our Flutter app. Here is what we did and the problems we encountered: We created a Widget Extension (SwiftUI + WidgetKit) inside the existing Flutter iOS project. The widget files were generated correctly (Widget.swift, WidgetBundle.swift, Info.plist, etc.). However, during the integration, we faced multiple issues: Build Cycle Error We repeatedly got: “Cycle inside Runner; building could produce unreliable results” This was related to embedding the widget extension into the Runner target. Embed Problems Sometimes Xcode did not automatically create the “Embed App Extensions” phase. When we added it manually → build cycle errors appeared. When we removed it → the widget was not embedded at all (no PlugIns folder in Runner.app). Duplicate / Conflicting Embed The extension appeared both in: “Embed Foundation Extensions” “Frameworks, Libraries, and Embedded Content” Removing one often broke the build or removed the other as well. Widget Not Appearing Even when build succeeded: Widget did not appear on device PlugIns/Widget.appex was missing from build output Flutter Linking Errors In another test project, we got: Undefined symbol: _FlutterMethodChannel Undefined symbol: _FlutterBasicMessageChannel etc. This happened because the widget extension tried to link Flutter dependencies, which should not happen. App Group Confusion We also tried adding App Group (group.com.xxx), but behavior didn’t change. Conclusion: We suspect the root issue is: The Flutter template we are using was not designed for WidgetKit integration Xcode embedding phases and Flutter build scripts conflict with extension targets Question: In your opinion: Is this a known limitation with Flutter-based iOS projects? Is there a clean way to integrate WidgetKit without breaking the Runner target? Or is it better to create a separate native iOS module for the widget? Any guidance would be really appreciated. Thanks!

Hi everyone, I’m currently implementing Live Activities in my music app to display real-time lyrics on the Lock Screen. The app works fully offline, so I’m not using push updates or push tokens. Instead, I’m updating the Live Activity locally as each new line of lyrics is played (essentially near real-time updates synced with the song). However, I’m running into an issue where the Live Activity UI is not updating reliably or frequently enough. Even though I’m calling the update method for each lyric line, the changes are either delayed or not reflected at all. Here’s some additional context: • The app runs fine in the background (verified via battery usage and playback behavior) • Live Activity is successfully created and initially displayed • Updates are triggered locally (no push notifications involved) • Updates are happening quite frequently (per lyric line) • No crashes or errors are observed My questions: 1. Is there a system-imposed throttling limit on how frequently Live Activities can be updated locally? 2. Are there recommended update intervals for smooth UI updates (e.g., for use cases like lyrics or timers)? 3. Does Live Activity deprioritize updates for offline apps or background execution? 4. Are there any additional configurations or capabilities required to ensure consistent updates? 5. Is using something like AsyncStream or other concurrency patterns helpful in this case? 6. Are there any undocumented limitations or best practices for high-frequency updates? 7. Is there any private or internal API used by Apple apps (like Music) that allows smoother real-time updates? My goal is to achieve smooth, near real-time lyric updates similar to Apple Music’s Now Playing experience. Any guidance, best practices, or clarification would be greatly appreciated. Thanks in advance!

I'm working on an app, and currently, 2 things dont work: account creation and notifications. I want to find the root of why these errors are occurring, and I want to know if these errors are coming from Firebase, certain settings in Xcode not being checked, or my actual written code not being typed correctly. I've tried to run my issue through ChatGPT many times to pretty much no success, so any help on what to do so I can clear certain areas and make sure the bugs aren't from certain spots, and help me narrow down the issue would be great. Otherwise, if there are other guides or threads I can be linked to, and help me fully break down the issue, that would be great. Thank you for your time reading, and I hope I can get some advice.

There appears to be a data loss bug in NSFileWrapper on macOS 26.4. It may have been around longer but I just never noticed ... So I write a RTFD file wrapper: NSFileWrapper *rtfd = [attributedString RTFDFileWrapperFromRange:NSMakeRange(0, attributedString.length) documentAttributes:@{NSDocumentTypeDocumentAttribute:NSRTFDTextDocumentType}]; Now IF I use -writeToURL:options:originalContentsURL:error: without using the NSFileWrapperWritingAtomic option and I pass in an existing URL, the followings happens: -The method returns NO and populates the NSError with NSFileWriteFileExistsError, as expected. This is what I want. -BUT the existing file is nuked. It just disappears. Foundation kills it. Poof. Another thing I gotta workaround. Getting pretty ridiculous, I must say. Just my lucky day I guess. It would be wonderful if I could work on my own features and fixing my own bugs.

Bug Report Environment 4× HomePod mini, audioOS 26.4 (23L243) iPhone, iPad, Mac – all running latest OS versions (iOS/iPadOS/macOS 26) iCloud account active, Shortcuts sync enabled on all devices Summary Siri no longer executes custom Shortcuts on any HomePod mini. Instead, the HomePod responds with built-in Siri answers or refers to the internet, as if no custom Shortcuts were registered. The same Shortcuts work correctly via Siri on iPhone, iPad, and Mac. Reproducible Test Case Created a new Shortcut named "Lemon Blue Seven" from scratch – no resemblance to any built-in Siri command, single action: spoken text output. Result: Mac: recognized and executed correctly via Siri iPhone / iPad: recognized and executed correctly via Siri (after re-registration, see below) All 4 HomePod mini: not recognized – Siri responds as if the Shortcut does not exist Steps to Reproduce Create a new Shortcut with a unique name and a single spoken output action Ensure iCloud Shortcuts sync is active on all devices Invoke via Siri on HomePod mini: „Run [Shortcut name]" HomePod responds with a built-in Siri answer instead of executing the Shortcut Additional Observations The issue appeared without any user-initiated changes to the setup Deleting all Shortcuts and re-importing them manually caused Siri registration to also break on iPhone and iPad; this was resolved by disabling iCloud Shortcuts sync, restarting the devices, and re-enabling sync The HomePod issue persisted through this fix – suggesting the HomePod's Intent delegation is broken independently of the hub device's registration state When a Shortcut name resembles a built-in command (e.g. „What time is it?"), the HomePod executes the built-in command instead – confirming it does not consult the user's Shortcut registry at all Troubleshooting Already Performed Multiple HomePod restarts Full factory reset and re-setup of HomePod (multiple times, also tested with only one HomePod active) Voice recognition re-trained Personal Requests disabled and re-enabled iCloud Shortcuts sync disabled on all devices, devices restarted, sync re-enabled sequentially All Shortcuts deleted and manually re-imported Home Hub verified: Bathroom HomePod registered as Home Hub, status „Connected" Tested with a separate Home setup Contacted Apple Support – no resolution provided Expected Behavior Siri on HomePod mini recognizes and executes user-defined Shortcuts by name, as it did prior to this issue and as it continues to do on iPhone, iPad, and Mac. Actual Behavior Siri on HomePod mini ignores user-defined Shortcuts entirely and falls back to built-in responses.

Based on https://developer.apple.com/help/app-store-connect/configure-in-app-purchase-settings/enter-server-urls-for-app-store-server-notifications It seems like we can choose between version 1 or version 2 notification Choose either Version 1 (deprecated) or Version 2 notifications. Learn about versions of App Store Server Notifications. However, I do not find a way to make such a choice. Does anyone know, how I can choose between v1 or v2 notification? We currently provide a self-hosted server endpoint built on the v1 specification. While the existing server is perfectly stable, we are evaluating a migration to v2. Thanks.

Summary On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops. Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time. Root Cause The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool. The deadlock cycle: cloudd requests an upload to the GCS storage endpoint nsurlsessiond provides the cached (broken) HTTP/3 session The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0) cloudd retries with a new connectionUUID — but nsurlsessiond still routes through the same poisoned QUIC session This repeats indefinitely Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation. The Smoking Gun After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly: Before Kill After Kill Protocol h3 (QUIC) http/1.1 (TCP) Largest upload Failed at partial offsets 26 MB in 1.6 seconds Server response 0 bytes 596 bytes (normal) Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond. Reproduction Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern: Small files (<100 KB) squeeze through before the QUIC session stalls Larger files trigger the deadlock every time 5–6 retries with fresh connectionUUIDs, all failing over protocol=h3 After kill cloudd + nsurlsessiond: immediate flush via protocol=http/1.1 An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report. Symptom Check (for others hitting this) /usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \ | grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l Output > 0 = this deadlock. Output = 0 = different issue. Recovery (one-liner) kill $(ps -axo user,pid,command | awk -v u="$USER" \ '($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \ || ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \ {print $2}') Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance. What was ruled out Network connectivity (Photos uploaded 8 MB through the same pool simultaneously) iCloud account (metadata operations succeeding, only body uploads failing) File type/content (random data, correlation is with size, not type) Storage quota (1.65 TB free) CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1) Suggested fixes (from the Feedback report) CFNetwork: Invalidate the QUIC session after N consecutive requestDuration=-1.000 failures CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:] cloudd: Self-healing retry — create a fresh NSURLSession after M consecutive deadlock-signature failures Finder: At minimum, surface the stuck state to the user instead of failing silently Filed as FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables. If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count. System MacBook Air, macOS 26.4.1 (25E253) iCloud Drive with Desktop & Documents sync en0 (WLAN) + en5 (USB-LAN via Studio Display)

The product ID entered has already been used by other in-app purchases associated with this team. I previously used fortune_pay_1, but not apple_pay_1 or apple_pays_1 How can this be solved

I'm developing a spatial tracking app using a Qorvo DWM3001CDK (MFi-certified UWB accessory) with NINearbyAccessoryConfiguration. On iPhone 15 (iOS 26.3.1, second-generation UWB chip): supportsDirectionMeasurement = false NINearbyObject.direction is always nil NINearbyObject.distance works correctly (~63Hz) Camera Assistance (isCameraAssistanceEnabled=true) provides horizontalAngle only after ARKit convergence (~10s), and only while the phone is moving On iPhone 12/13 (first-generation UWB chip), direction works correctly with the same accessory. My questions: Is the removal of instantaneous direction measurement for third-party accessories on second-generation UWB devices intentional? Or is this a regression that will be fixed in a future iOS update? If intentional, what is the recommended approach for apps that need real-time direction to a UWB accessory on iPhone 15/16? Camera Assistance requires phone movement and only works with stationary targets, which doesn't work for our use case (tracking a moving object with the phone mounted on a gimbal). Are there any plans to provide instantaneous direction measurement for NINearbyAccessoryConfiguration on second-generation UWB devices? Environment: iPhone 15, iOS 26.3.1 Qorvo DWM3001CDK (FiRa + MFi certified) NINearbyAccessoryConfiguration with isCameraAssistanceEnabled=true Shared ARSession Thank you.

I am currently developing an app for MacOS that needs to control HomeKit devices like lights. However, it seems like MacOS is supported on the official documentation, but not when I try to create an app ID on developer.apple.com. On the link https://developer.apple.com/apple-home/, MacOS is clearly showed as supported for MacOS. But when I try to create an app ID, it shows that it is only compatible for iOS, VisionOS and WatchOS. Could this be clarified? Best regards, orangeidle25

Hello, I've run into an issue where AssetPacks being served locally are downloading but unable to complete. try await AssetPackManager .shared .ensureLocalAvailability(of: assetPack) This method is called but never appears to complete. Even 10 minutes after the download is finished. <NSProgress: 0x10fb4fc80> : Parent: 0x0 (portion: 0) / Fraction completed: 1.0000 / Completed: 2462633379 of 2462633379 This however does not appear to be an issue in production, as the method completes 30-60 seconds after the download has finished. Issue happens across multiple devices running 26.4.1

Hi everyone, I'm looking for clarity on the NFC HCE entitlement process for third-party apps in the EEA. I've built an alternative client for Milan's public transport app (ATM Milano) on Android by reverse engineering the original app. It offers the same core functionality(users still need a valid transit subscription) just with a different UI and better UX. I'd now like to port it to iOS. According to Apple's documentation, NFC HCE was opened to third parties in the EEA starting with iOS 17.4. However, the API requires an entitlement from Apple. I have a few questions: Is the entitlement required regardless of distribution method? Even if I distribute through a third-party marketplace like AltStore PAL rather than the App Store, do I still need Apple to grant the HCE entitlement? Are third-party/alternative clients eligible for the entitlement? My app isn't a competing transit provider, it's an alternative frontend for an existing service. Users must hold a valid subscription with the official provider. Is there anything in the entitlement criteria that would disqualify this kind of app? What's the correct process to apply?Developer Support directed me here, so I'm hoping someone from Apple engineering or someone who has gone through the process can share the steps. Thanks!

Hello community, I am implementing a Live Activity for my existing App Store app. The Live Activity works perfectly on the iOS Simulator, but it completely fails to appear on the physical device's lock screen. When I call Activity.request, it succeeds and returns a valid Activity ID, but the physical device's console immediately outputs the following errors from liveactivitiesd: liveactivitiesd is not entitled to specify a scene target. Defaulting containingProcess target to liveactivitiesd No asset provider bundle ID provided I have spent days debugging this and have tried every known workaround. Here is the comprehensive list of what I have already verified and attempted: Environment: Xcode: 16.4 iOS Device: iPhone 13 mini, iOS 26.3.1 macOS: Sequoia 15.6 What I have verified/tried (to avoid duplicate suggestions): NSSupportsLiveActivities: It is set to YES in the main app's Info.plist. I also tried adding it to the Widget Extension's Info.plist just in case. App Icons: The main app has a valid AppIcon set in Assets.xcassets. The Primary App Icon Set Name in Build Settings is correctly set to AppIcon. Bundle IDs: They match perfectly (com.mycompany.app and com.mycompany.app.MyWidget). Version & Build Numbers: The main app and the Widget Extension have exactly the same Version and Build numbers. App Groups & Entitlements: Checked and perfectly synced between the main app and the extension. Dummy Widget: Since it's a Live-Activity-only extension, I added a standard static DummyWidget to the WidgetBundle to prevent the known iOS 17 bug where the system ignores extensions without home screen widgets. Memory/Sanitizers: Ensured Address Sanitizer and Zombie Objects are completely disabled in the Scheme to prevent the 30MB memory limit crash on the device. Nuclear Option: Completely deleted the Widget Extension target, wiped DerivedData, restarted the Mac and iPhone, and recreated the extension from scratch. Minimal UI Test: Replaced the widget's UI with a simple Text("Test") to rule out any SwiftUI rendering crashes. Device Settings: Verified that "Live Activities" is enabled under "Face ID & Passcode" settings on the physical iPhone. Despite all of this, the Simulator works flawlessy, while the device throws No asset provider bundle ID provided and shows nothing. Does anyone know what specific condition causes liveactivitiesd to fail to find the asset provider (the parent app) on a physical device for an existing app? Are there any undocumented provisioning profile quirks or obscure Build Settings I might be missing? Any insights would be deeply appreciated. Thank you!

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

Hello! I have an accessory, which is paired already with an iPhone, and am attempting to upgrade its SSID permission to Wi-Fi Aware. In ideal conditions, it works perfectly. However, if I dismiss the picker at the time of pin-code entry, I am unable to re-initialize an upgrade authorization picker. Even though the authorization is not completed a WAPairedDeviceID is assigned to the object of 18446744073709551615. Any subsequent attempts to start the picker up again spits out when treated as a failure serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "No new updates detected from existing accessory descriptor." Attempting with a mutated descriptor serves: [ERROR] updateAuthorization error=Error Domain=ASErrorDomain Code=450 "Accessory cannot be upgraded with given descriptor." If I try using failAuthorization i get a 550 "Invalid State" error and furthermore if I try finishAuthorization to attempt to clear the descriptor/paired device ID it fails to clear it. If I could be pointed to the intended behavior on how to handle this, or this can be acknowledged as a bug, that would be incredibly appreciated. Thank you!

I'm working with an Espressif ESP32-C5 device. The firmware on the device is based on Espressif's base software, which provides Wifi provisioning services via Bluetooth. My firmware also provides its own Bluetooth services too. When the Espressif part of the firmware connects to Wifi, it re-initializes the entire Bluetooth stack, eliminating all of its own services. Mine get added back, but my app starts failing and doing weird things at this point. I believe it is due to iOS caching the GATT configuration and not recognizing that it has changed. If I restart my phone, the problem is cleared. But this is not a good solution to the problem. I need a way to let iOS know that it should clear any cached information related to this device. How can I do that?

Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/Command-Shift-Z, the app reliably crashes with the following error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<DocumentTest.ChildItem> And before the app crashes, what always happens is that UndoManager stops removing/restoring instances of ChildItem (but continues to remove/restore instances of ParentItem). The issue goes away when I enclose the relevant code in ModelContext.transaction(block:). However, this shouldn't be necessary, as ModelContext.autosaveEnabled is true by default. The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The sample project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/13bCB1qRZ6273BI81zW2zUUBraSvv6p5w?usp=share_link Is this expected behavior or should I file a bug report in Feedback Assistant? Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to add another ChildItem to it. Repeat steps 5–6 until you have 5 ParentItems with an additional ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until UndoManager stops removing/restoring the additional ChildItem, and continue repeating them until the app eventually crashes (you may have to repeat them 5–10 times before the issue occurs). If you uncomment the ModelContext.transaction(block:) at line 13 of ContentView.swift and repeat the same steps above, no ChildItems will go missing and the app will not crash. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ for newChildItem in newChildItems { newParentItem.childItems.append( newChildItem ) newChildItem.parentItem = newParentItem } Adding an Additional ChildItem to ParentItem // Uncommenting this block fixes the crash // try! modelContext.transaction { // Create and insert the new ChildItem let newChildItem = ChildItem( index: parentItem.childItems.count ) modelContext.insert(newChildItem) // Establish relationship to parentItem parentItem.childItems.append(newChildItem) newChildItem.parentItem = parentItem // }

Overview I'm developing a document-based app for macOS using SwiftData. When I undo/redo changes using Command-Z/Command-Shift-Z, the app reliably crashes with the following error: SwiftData/ModelSnapshot.swift:46: Fatal error: Unexpected backing data for snapshot creation: SwiftData._FullFutureBackingData<DocumentTest.ChildItem> And before the app crashes, what always happens is that UndoManager stops removing/restoring instances of ChildItem (but continues to remove/restore instances of ParentItem). The issue goes away when I enclose the relevant code in ModelContext.transaction(block:). However, this shouldn't be necessary, as ModelContext.autosaveEnabled is true by default. The issues are occurring with Xcode 26.4 (17E192) and macOS Tahoe 26.4 (25E246). I have modified the macOS Document App project template to showcase the issue. The sample project, along with a screen recording of the crash, can be downloaded from here: https://drive.google.com/drive/folders/13bCB1qRZ6273BI81zW2zUUBraSvv6p5w?usp=share_link Is this expected behavior or should I file a bug report in Feedback Assistant? Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file linked above. Open the extracted "DocumentTest" project in Xcode. Build and run the "DocumentTest" app. In the document selection window, click "New Document" at the bottom-left. In the app, click the "+" button at the top-right to add a ParentItem with ChildItems. Click on the added ParentItem's button to add another ChildItem to it. Repeat steps 5–6 until you have 5 ParentItems with an additional ChildItem. Press Command-Z 10 times to undo all the changes. Press Command-Shift-Z 10 times to redo all the changes. Repeat steps 8–9 until UndoManager stops removing/restoring the additional ChildItem, and continue repeating them until the app eventually crashes (you may have to repeat them 5–10 times before the issue occurs). If you uncomment the ModelContext.transaction(block:) at line 13 of ContentView.swift and repeat the same steps above, no ChildItems will go missing and the app will not crash. Code ParentItem Model @Model final class ParentItem { var timestamp: Date @Relationship( deleteRule: .cascade, inverse: \ChildItem.parentItem ) var childItems: [ChildItem] = [] init(timestamp: Date) { self.timestamp = timestamp } } ChildItem Model @Model final class ChildItem { var index: Int var parentItem: ParentItem? init(index: Int) { self.index = index } } Creating, Inserting, and Linking ParentItem and ChildItem // Create and insert ParentItem let newParentItem = ParentItem( timestamp: Date() ) modelContext.insert(newParentItem) // Create and insert ChildItems var newChildItems: [ChildItem] = [] for index in 0..<Int.random(in: 2...8) { let newChildItem = ChildItem(index: index) newChildItems.append(newChildItem) modelContext.insert(newChildItem) } /* Establish relationship between ParentItem and ChildItems */ for newChildItem in newChildItems { newParentItem.childItems.append( newChildItem ) newChildItem.parentItem = newParentItem } Adding an Additional ChildItem to ParentItem // Uncommenting this block fixes the crash // try! modelContext.transaction { // Create and insert the new ChildItem let newChildItem = ChildItem( index: parentItem.childItems.count ) modelContext.insert(newChildItem) // Establish relationship to parentItem parentItem.childItems.append(newChildItem) newChildItem.parentItem = parentItem // }

According to this comment in the sample project on GitHub and this answer by Apple Staff, CKSyncEngine should be re-initialized after signing out or switching accounts so that "CKSyncEngine schedules a new fetch on init." But according to my tests, CKSyncEngine will schedule a fetch after having a signed out and signed in again, without me ever having to reset the serialized sync state. The documentation doesn't mentioned anywhere that CKSyncEngine should be re-initialized after an account change. In fact, it states that CKSyncEngine will reset its state internally on account changes. So if that's the case, then I'm very confused as to why the "official" recommendation is to re-initialize CKSyncEngine after receiving .signOut or .accountSwitch. Can someone please clarify the correct approach here?

我是开发者，日常工作会同时打开大量终端（tmux、多项目、自动化脚本、node‑pty 等）。在这种现代开发场景下，511 的 PTY 上限明显过低，而且这个默认值对顶配机器（128GB RAM）和低配机器是一样的，没有随硬件规格调整，这不合理。 我尝试过使用 tmux control mode 来减少 PTY 占用，但它会导致终端输出对齐错乱，影响可用性，所以必须继续使用 PTY 模式。这意味着只要终端数量稍多，就很容易触及 511 上限，导致系统层面无法创建新终端，影响全局稳定性。 总结： 511 作为默认值在过去或许合理，但对现代开发者明显不足； 顶配机器和低配机器同一上限不合理； control mode 有输出对齐问题，无法作为现实替代方案。 谢谢！ Apple 支持社区工作人员