Filing this as a public thread to try to get DTS attention, similar to how thread 821372 (skmem_slab_free_locked double-free) got resolved - accumulated cross-referenced reports there are what got that one fixed in 26.5/26.6. Panic signature (identical every time): panic(cpu N caller 0x...): m_copym_with_hdrs n 0x... copy overflow @uipc_mbuf.c:3268 My own occurrences: 5 panics over 2 days on a MacBook Pro (Mac16,7 / M4 Pro), macOS 26.5.2 build 25F84, kernel Darwin 25.5.0 (xnu-12377.121.10~1/RELEASE_ARM64_T6041). Filed as Feedback Assistant report FB24343421 (5 panic logs + a full sysdiagnose attached). Why this looks like a generic kernel bug, not app-specific: I initially suspected a third-party VPN NetworkExtension (Tailscale) since it appeared in the full stackshot of every one of my panics. Ruled that out: That NE is a userspace-only component - cannot execute kernel code. Two other reporters have hit the identical panic string via completely different, unrelated paths: One reproduced it with no VPN/tunnel software running at all (engine stopped, sysext idle) - see FB24333740, cross-referenced at https://github.com/tailscale/tailscale/issues/20864 Another hit the same panic string on an Intel Mac via a third-party Ethernet kext, no VPN/utun involved at all - https://github.com/SongXiaoXi/AppleIGC/issues/34 So this reproduces through at least 3 independent producer paths (a NetworkExtension, no tunnel software at all, and a third-party Ethernet driver), which points to something generic in the TCP send path (tcp_output -> m_copym_with_hdrs) rather than anything specific to one app or extension. Known non-workarounds: net.inet.tcp.tso=0 does not avoid the code path (checked against the last public xnu source drop). No sysctl or config change has stopped recurrence for anyone who's tried. Related public reports: https://github.com/tailscale/tailscale/issues/20864 https://github.com/tailscale/tailscale/issues/20612 https://github.com/SongXiaoXi/AppleIGC/issues/34 FB24333740 (independent Feedback Assistant report, same signature) FB24343421 (mine, this thread) Still reproducing on the latest public release (26.6.1 / 25G76) per the other reporters. Happy to provide more diagnostics - this is easy to reproduce on my end, roughly every few hours to once a day under normal use.

I’m working on an open-source React Native library for Wi-Fi Aware / NAN: https://github.com/dcavalcante/react-native-wifi-aware The Android implementation has already been physically validated for capability detection, discovery, follow-up messaging, and data paths. The Apple implementation is in place and passes the current simulator/static compilation gates, but I don’t currently have the Apple hardware and Developer Program setup needed to validate it on physical devices. I’m looking for someone with an Apple Developer account and preferably two iOS/iPadOS 26 devices who can help test: Wi-Fi Aware entitlement/signing declared WiFiAwareServices publish / subscribe discovery system pairing Apple-to-Apple connectivity Android ↔ Apple discovery and interoperability The biggest unknown I want to validate is the cross-platform path between Android Wi-Fi Aware and Apple’s iOS 26 implementation. Testing results, fixes, documentation, and implementation contributions are all welcome.

Deployment scope: macOS 26 and macOS 27, Apple silicon / arm64 only. Intel / x86_64 and Rosetta behavior are outside this inquiry. Please distinguish applicability and limitations for each named macOS version; support for one version must not be assumed to establish support for the other. We are evaluating a directly created child's lifecycle in a continuously living original parent, using documented posix_spawn, kill and wait interfaces. This is a support-contract clarification, not a report of a reproduced OS defect. We have not conducted a process experiment. The proposed parent would serialize every action against every potentially consuming wait, exclude competing waiters, retain SIGCHLD status (no SA_NOCLDWAIT or explicit SIG_IGN), and permanently revoke further actions before permitting final reap. Parent loss or uncertain ownership causes refusal, with no adoption or respawn. We are not asking for private interfaces or implementation internals. POSIX.1-2024 XBD 4.17 prohibits PID reuse before process lifetime ends. Its _exit description connects normal zombie lifetime to collection of status, with explicit automatic-disposal exceptions. We recognize that UNIX 03 certification is a different edition/profile and do not assume POSIX.1-2024 applicability to macOS. For the specified deployment range, please identify the applicable supported documentation/standard profile and clarify: Under the stated exclusions, is a directly created child's positive PID reserved against reassignment through exit/zombie state until a defined consuming wait boundary? Which documented exceptions or ownership transitions defeat that premise? What is the supported consuming boundary for wait/waitpid, including WNOHANG, EINTR, stopped status and concurrent waiters? Does excluding all consuming waits during an action close the numeric-replacement risk, or is another supported condition required? Please identify the documented effects of explicit SIG_IGN versus SIG_DFL, SA_NOCLDWAIT, exec and parent death that are relevant to that exact reservation claim. We do not infer unchanged executable identity, permissions or successful termination from unchanged PID. We are asking for version-applicable supported semantics, including any limits on the conclusion, rather than empirical plausibility or absence of a known counterexample. If this guarantee is not supported, please say so. We are not asking you to certify our implementation, cleanup of descendants, or full supervisor correctness. Primary references: https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap04.html https://pubs.opengroup.org/onlinepubs/9799919799/functions/_exit.html https://www.opengroup.org/openbrand/register/apple.htm

We can reproduce an AlarmKit audio failure on iPhone 16 Plus / iOS 26.6.2 (23G90) with a reduced SwiftUI app using fixed-date alarms and .default sound: Schedule three alarms at +60, +180 and +300 seconds. Leave the app visible and the phone untouched. The first alarm sounds. When the +180 alarm triggers, the +60 alarm is silenced (but still active). When the +300 alarm triggers, all three alarms will remain silent, however alarmUpdates reports one, then two, then three .alerting IDs. A single alarm in the same binary sounded continuously for at least 3 minutes 30 seconds. The reduced app has no custom intents, widget, countdown/snooze, audio session, background modes, notifications, packages or automatic cancellation. This exact reduced binary has one recorded comparison; earlier harness configurations also exhibited the failure. Sound was observed by the tester, separately from API logs. When +180 mutes +60, stopping the +60 alarm causes the +180 alarm banner to present itself and become audible. +300 triggering will then mute the +180 alarm. Likewise, stopping the +180 alarm will cause the +300 alarm to present itself and become audible. If you allow +60, +180, and +300 alarms to trigger without touching the screen, all three alarms will be silent at this point. Pressing "Stop" on +60 will cause the +180 banner to present itself and become audible, "Stop" on +180 will cause +300 alarm to then present and become audible. It is for these reasons that I believe there is a bug that occurs when an additional queued alarm transitions from "scheduled" to "active" status that causes the present active alarm to silence. In a foreground harness run, programmatically cancelling the +60 alarm's alerting ID caused the +180 alarm to sound. However that requires app execution and does not establish a background solution. The snooze/coincident-time report looks like it could be related. The FAQ's same-time scheduling answer also seems to describe a different case. What is the supported audio behavior when a later alarm becomes due while an earlier one remains alerting? Is there a scheduling or handoff pattern that preserves audible delivery without requiring the app to execute at each arrival? If overlap is unsupported, which documented constraints should applications follow? If anyone else has experienced this issue and has found a technical workaround I would appreciate hearing about it. For any Apple staff reading this, there is more information on this issue in Feedback Assistant ID FB24757864.

On Apple silicon with macOS 26.6.2 (25G83), I am preparing a small synthetic VM using Swift and public Virtualization.framework APIs. Before invoking VZMacOSInstaller, I need to establish a hard aggregate allocation bound covering its temporary extraction data and relevant helper caches, not just the supplied restore image, guest disk and auxiliary-storage URLs. The application-owned artifacts would be placed inside a fixed-size, capped filesystem. Unknown installer scratch remains part of the byte budget. Sampling free space or cancelling after a threshold is crossed is not a substitute for filesystem enforcement in this design. No installer has been started for this trial; this is an API-design question, not a reproduced installation failure. Is there a supported mechanism to select or constrain the filesystem for all VZMacOSInstaller and relevant helper temporary writes? In particular, is there a documented binding between a caller's temporary directory and independently managed installer-service storage, or another supported aggregate quota design? If the public API cannot provide this guarantee, an explicit statement of that limitation would help. I am not seeking private parameters, managed-container relocation, disabled system protections, or undocumented sandbox overrides.

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

I'v been using a shortcut from the iOS/ipadOS share sheet in safari for several months now successfully and tried to use/port it to macOS: The "Run Javascript on Active Safari Tab" (RJOACST) action fails on MacOS if logic based on native shortcut actions is executed before / in front of it. The same shortcut does work on iOS and iPadOS. Here's the shortcut: https://www.icloud.com/shortcuts/613fe9b4464c401380159eb8160eb485 The Error on macOS reads: ''' DEV Safari Recipee 2 JS Reminders N... Unable to Run JavaScript on Web Page Make sure Allow JavaScript from Apple Events is enabled in the Develop menu in Safari. The Develop menu can be enabled in the Advanced section of Safari's Preferences. ''' BUT: simpler shortcuts with just the RJOASF Javascscript (e.g. the default script) DO work on the same machine. All settings are correct. When refactoring the initial logic from shortcuts action into Javascript code and calling the RJOACST silently lets the shortcut die. Any lead/hint appreciated. I did try to retrieve the shortcuts input shortly before the RJOACST is executed. PS: The file Recipes.json contains a list of sites to scrape recipe ingredients from - find the example here: ''' { "deli-berlin.com": { "selectorType": "xpath", "selectorExpression": "//div[contains(@class,'wprm-recipe-ingredient-group')]/ul/li", "extractionType": "text", "joinArrayString": "\n", "cleanupRules": [], "sampleUrl": "https://deli-berlin.com/rezept-vegane-lasagne/", "cachedHtml": "", "baselineIngredientsText": "", "activeVariationId": "row", "variations": [], "snapshotNote": "", "lastTestStatus": "untested", "lastTestedDate": "", "lastTestError": "", "htmlUpdatedAt": "", "baselineUpdatedAt": "", "ruleConfigUpdatedAt": "", "history": [] }, "www.allrecipes.com": { "selectorType": "xpath", "selectorExpression": "//ul[contains(@class,'mntl-structured-ingredients__list')]/li", "extractionType": "text", "joinArrayString": "\n", "cleanupRules": [ { "find": "\n{2,}", "replace": "\n", "active": true, "phase": "beforeJoin" } ], "sampleUrl": "https://www.allrecipes.com/recipe/221361/traditional-sauerbraten/", "cachedHtml": "", "baselineIngredientsText": "", "activeVariationId": "row", "variations": [], "snapshotNote": "", "lastTestStatus": "untested", "lastTestedDate": "", "lastTestError": "", "htmlUpdatedAt": "", "baselineUpdatedAt": "", "ruleConfigUpdatedAt": "", "history": [] } } '''

Live App Store app; approved non-consumable in-app purchase is not returned by production StoreKit, so customers cannot buy it. Product.products(for:) returns nothing; the paywall shows "purchases aren't available." ~15 days since first release (2026-07-06). Reproduced on two devices with two different Apple IDs. A redeemed promo code also did not deliver it. Important: my IAP status is APPROVED (not "Waiting for Review"), so this differs from some recent threads — yet the product still isn't served in production. Verified per TN3188 (all pass): product ID matches App Store Connect exactly; status Approved; Availability = all 175 regions; priced (base USD); listed on the public App Store product page; Paid Apps Agreement, banking, and tax forms all Active; no local .storekit config in the build; the product returns correctly from our provider's (RevenueCat) servers, so the empty result is specifically the on-device production StoreKit fetch. This coincides with the recent App Store Connect incident affecting in-app-purchase submission, and there's a cluster of similar reports this week (threads 838171, 838435, 835770, and "In-App Subscriptions stuck in 'Waiting for Review' after App Store Connect maintenance"). It looks like a server-side issue where the product never propagated to production StoreKit despite showing Approved. Environment: Expo/EAS, React Native 0.81, StoreKit 2 via react-native-purchases 10.3.0. Devices: iPhone 15 Pro Max (iOS 27.0), iPhone 16 Pro Max (iOS 26.5). Open Developer Support case: 102936978821. Is there any developer-side step remaining, or does this require Apple to re-process / re-propagate the product server-side? Any guidance appreciated.

【Environment】 macOS Sonoma 14.4 or later / Sequoia. Using a third-party File Provider extension (Google Drive desktop app). 【Situation】 The evict subcommand has been removed from fileproviderctl, and I cannot find a way to manually clear the File Provider local cache (files that have been materialized but are not pinned) via the Terminal. Even in the GUI (Finder), there are cases where the "Make available offline" (or "Remove Download") option—specifically "Make available online only"— does not appear when selecting a target folder in bulk (it may only appear when selecting an individual file). 【Questions】 Is there any officially supported API, CLI, or GUI operation in macOS Sonoma 14.4 or later that allows a user to explicitly evict unpinned cache items managed by the File Provider? 2. Was the removal of fileproviderctl evict an intentional design change? Is there an alternative method? 3. What are the conditions under which the Finder's "Make available online only" menu item does not appear during multiple selection (specifically when selecting an entire folder or using Command+A to select all)? 【環境】 macOS Sonoma 14.4以降 / Sequoia。サードパーティのFile Provider拡張 (Google Drive デスクトップアプリ)を使用。 【状況】 fileproviderctl から evict サブコマンドが廃止されており、ターミナルから File Providerのローカルキャッシュ(実体化済みだが非ピン留めのファイル)を 手動で解放する手段が見当たりません。GUI(Finder)側でも、対象フォルダを 一括選択した場合に「オンラインのみで使用可能にする」という選択肢が 表示されないケースがあります(個別の1ファイル選択時にのみ表示される ことがある)。 【質問】 macOS Sonoma 14.4以降で、File Provider配下の非ピン留めキャッシュを ユーザーが明示的にevictする、公式にサポートされたAPI・CLI・GUI操作は 存在しますか? fileproviderctl evict が廃止されたのは意図的な仕様変更ですか? 代替手段はありますか? Finderの「オンラインのみで使用可能にする」メニュー項目が、複数選択 (特にフォルダ全体やCommand+A全選択)の際に表示されない条件を教えて ください。

IOUSBHostDevice(ioService:options:queue:interestHandler:) with .deviceCapture succeeds — the device is mine, its mass-storage driver terminated. setConfiguration(1, matchInterfaces:) succeeds. The failure is the very next call: IOUSBHostInterface(ioService:options:queue:interestHandler:) on interface 0 returns IOUSBHostErrorDomain -536870199 (kIOReturnInternalError, 0xe00002c9). Exactly one interface node is published under the device, IOServiceGetBusyState reports it idle, and it is refused identically on every retry over several seconds and across repeated re-captures — so this is not a publication race or a stale node. With Full Disk Access granted to the app, the same call claims it on the first attempt, every time. So I'm stuck. I have no choice but to use FDA which I absolutely do NOT want to do. To anyone from DTS reading this, is this a valid reason for granting me com.apple.vm.device-access? It looks like using DriverKit might not work either because the Driverkit entitlements are also restricted. What is the solution here?

Hello, We would appreciate some guidance regarding an unexpected StoreKit currency result in a TestFlight build. Our iPhone language and region are both set to France. The Sandbox tester is also configured for France, and our subscription products have French availability and pricing configured in App Store Connect. In the TestFlight build we diagnosed, StoreKit reports the current storefront as France with EUR: storefront=FRA/143442/EUR However, all 10 subscription products are returned with USD product metadata: products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE Example: formatCurrency=USD locale=fr_US_currency_USD localeCurrency=USD display=1,99 $US price=1.99 We first observed this through Flutter's in_app_purchase integration. To determine whether the Flutter plugin was involved, we added a native StoreKit 2 diagnostic to the same TestFlight build. The native result was identical: receipt=sandboxReceipt storefront before=FRA/143442/EUR storefront after=FRA/143442/EUR products=10/10 formatCurrencies=USD localeCurrencies=USD error=NONE The issue appears specific to the TestFlight distribution. When the application is installed directly from the development computer, prices are returned in euros on the same device. We also tested with the regular Media & Purchases account signed out and a French Sandbox tester connected. Once the products loaded successfully, StoreKit still returned USD metadata. In another configuration, the application displayed the USD price while Apple's purchase sheet displayed the price in euros. We are using the price and formatting information returned directly by StoreKit. We do not want to infer the currency from the device region or perform a client-side currency conversion, because StoreKit should remain the authoritative source. Could you please help us understand: Is it expected for Storefront.current to report FRA/EUR while Product.priceFormatStyle.currencyCode, its locale currency, and Product.displayPrice use USD? Could a TestFlight or App Store Connect configuration cause product metadata to use a different currency from the current storefront? Is there another account, availability, pricing or distribution setting that we should verify? Is there a recommended way to refresh or invalidate the product metadata used by a TestFlight installation? We have already filed Feedback Assistant report FB24723329, which is currently under investigation. Thank you very much for any clarification or additional diagnostic steps you can suggest.

We have a published, approved App Clip that works correctly via QR code and the Safari Smart App Banner, but URL-based invocation does not trigger the App Clip card in any context. Most notably, Apple's own default App Clip URL does not work either: https://appclip.apple.com/id?p=hazel-torus.Clip **Tapping this link in Messages or Notes does nothing. ** Long-pressing it shows a generic website link preview rather than the App Clip card, even though appclip.apple.com is Apple's domain and requires no configuration on our end. Setup details: App Clip bundle ID: hazel-torus.Clip Team ID: 2UNR2APH47 App Clip experience URL: https://passportreader.app/open AASA includes a correctly formatted appclips key with 2UNR2APH47.hazel-torus.Clip (confirmed via https://app-site-association.cdn-apple.com/a/v1/passportreader.app that AASA is correctly cached) Associated Domains entitlements (appclips:passportreader.app) are present on the App Clip target App and App Clip experience are both Approved / Ready for Sale Tested on two physical devices, neither with the full app installed Since QR and Safari banner invocation work, the App Clip itself and its entitlements appear correctly configured. The fact that even Apple's own appclip.apple.com URL fails, and is treated as an arbitrary website link, suggests this may be a backend indexing issue specific to this App Clip rather than a client-side configuration problem. Has anyone else encountered this, or know what could cause appclip.apple.com to not be recognized as an App Clip URL?

Dear Apple Team, I am writing to propose an update to the audio management algorithms in iOS, specifically the automatic Audio Ducking feature during incoming notifications. The inability to disable this function not only creates daily discomfort for users but also directly harms the marketing effectiveness of both third-party services and the Apple ecosystem itself. Currently, the iOS architecture forces the user to choose between two scenarios, both of which are destructive to business: Damage to apps' marketing systems (if device sound is on) Music is a source of emotional pleasure and focus. When the system forcibly ducks the track's volume for a notification sound, users perceive it as an aggressive and annoying intrusion. Instead of engaging with the offer or message, the user feels negativity toward the sending app. The marketing tool (push notification) backfires: to protect their comfort, the user either dismisses the notification without looking or permanently revokes the app's notification permissions, destroying the communication channel and lowering engagement rates. 2. Damage to the reliability and reputation of the Apple ecosystem (if sound is off) Trying to avoid the annoyance described in the first point, the user resorts to the only available workaround — switching the iPhone to silent mode using the physical switch. However, after listening to music, this switch is often left in the silent position. Result: missed important calls, derailed work arrangements, or ignored emergency messages. In this scenario, Apple's reputation suffers. Because of the company's reluctance to add one simple audio focus setting, the device stops performing its core function as a reliable communication tool. The system literally forces the user to "cut" themselves off from the world for the sake of comfortable music listening, leading to negative real-world consequences. Proposed Solution: Introduce a toggle in the "Sounds & Haptics" (or "Accessibility") settings: "Do not duck media for notifications." Alternatively, allow notification sounds to play over the music without altering the main audio stream's volume. Apple has always been known for putting human comfort first. Adding this feature will solve a serious behavioral issue. It will preserve audience loyalty to third-party push campaigns and ensure that iPhone owners stop missing important life events due to the forced use of silent mode. Thank you for your time and attention to user experience. I hope this improvement finds its way into upcoming iOS updates. Sincerely, An Apple Ecosystem User

My MacBook Pro M5 running MacOS Tahoe 26.3 beta fails to detect two identical ASUS ROG Swift OLED PG32UCDM monitors simultaneously. Only one display is recognized at a time. One potential root cause might be that both monitors report identical binary EDID serial numbers (0x01010101), and the MacBook Pro M5 appears to use this value exclusively for display identity rather than combining it with other more detailed information (e.g., port, or alphanumeric serial number). I've verified that the monitor EDID binary serial numbers are in fact identical -- however the alphanumerical serial numbers are not identical. NOTE: This behavior is specific to the MacBook Pro M5 — when connecting both monitors via usb-c to a Mac Mini M4 Pro running the same MacOS Tahoe 26.3 beta, the monitors work fine. The OS detects both and assigns different names to them (PG32UCDM (1) and PG32UCDM (2)). NOTE: I could be wrong about this root cause, I don't have a way to disprove it, though the fact the monitors work fine on a Mac Mini is suspicious. What I have tried: Connecting the two monitors using different monitor ports (one on DisplayPort, another on HDMI, etc.), and different MacBook ports (one on HDMI, another on USB-C, etc.) Bumping down the resolution on the monitors to "1920x1080 (low resolution)" and 30Hz to rule out bandwidth issues. Connecting one, or both, monitors to CalDigit TS5 Plus dock. Neither alternate configuration yields the device recognizing both screens. Using BetterDisplay to import a manually-edited EDID for the screen, with a different binary EDID value, manufacturer name, etc. I've also verified that if I plug in my Apple Studio Display as one of the monitors, then the MacBook recognizes both one of the PG32UCDM monitors and the Studio Display at the same time. The issue seems to occur only when both monitors plugged into it are the same PG32UCDM model. When I have both monitors plugged into my MacBook, each time I disconnect the cable to whichever monitor is currently recognized, it immediately recognizes the other monitor. Plugging the cable for the disconnected monitor back in has no effect. I'm at a loss. Has anyone run into this issue and found a successful workaround that is not one of the approaches I've described above?

Can all the AI stuff be turned off on the new iPhone 18 pro running iOS 27?

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

Hi everyone, I set up an auto-renewable subscription introductory offer in App Store Connect with a scheduled start date of September 7 for the Philippines storefront. According to the documentation App Store pricing and availability start times by country or region, scheduled pricing and offer updates are expected to go live based on local regional times. However, the offer did not show up in the Current Introductory Offers in app store connect portal at the documented start time (14:00 Sep 6th UTC). Instead, it stayed in the Upcoming Offers until 7:00 Sep 7th UTC which is 17 hours after the time in the doc. We met a similar situation a few days later when we launch another introductory offer in Thailand. I would appreciate clarification on the following points: What is the underlying reason for the discrepancy between the documented start time behavior and the actual start time observed in production? Can Apple update the App Store pricing and availability start times by country or region reference documentation so that it accurately reflects the practical start time and propagation window for each region? Any insights or shared experiences with offer scheduling in the APAC region would be greatly appreciated.

On watchOS 27 my app's round complication on the Infograph face disappears for about a second every time I raise or lower my wrist, then comes back. It only happens in the small round dials of that face, only when the face is set to a single color instead of Multicolor, and only when Always On Display is turned on. Everything else on the same watch is fine. my complication placed in a corner of the same face, the same face set to Multicolor, and an Apple complication sitting right next to mine. Other faces set to a single color are fine too, including in their round slots - I tested Modular and Meridian among others. With Always On Display off there is no problem either. What I already checked is: It still happens when my complication is the only one on the face. It still happens when the complication shows just a single line of plain text. The data is not being reloaded. I displayed the timestamp of the entry inside the complication and it does not change across the gap, so the same content is simply being redrawn. Removing the complication and adding it back does not help. Rebuilding with the newest Xcode changes nothing, and an older build behaves exactly the same. The same app, unchanged, worked correctly on watchOS 26. This started right after updating the watch to watchOS 27. Has anyone else run into this on watchOS 27? And has anyone found anything on the app side that makes a difference? I have not found a single thing.

Hi there! My claim is that ManagedSettingsStore.TokenExpiryMessage API family doesn't work properly. I'm curious if that's only me, or others have also found it confusing, or non-working? I haven't found much public discussion about it, so this is the start of it. There are multiple confusing scenarios from my playing with it, but the simplest example is that ~30% of my apps NEW users get the ".tokensDidExpire" as soon as they approve Screen Time Permissions. Note that they haven't even seen the FamilyActivityPicker! FB23391495 is the feedback. Apple dev responded, but it didn't give confidence that my bug report was deemed correct (which can be fair!). However, it's current status is "Potential fix identified - For a future OS update," so maybe there is something to it. The API is likely quite difficult to get right, so I am happy to provide feedback on potential implementation so it's 100% solid.

Title: Background location deliveries stop after 2-5 minutes on iOS 27 despite guidance-compliant configuration iOS 27.0, iPhone 17 Pro Max. Always authorization, Precise on, Low Power off. React Native / expo-location 19.0.8. While recording a GPS trail with the app backgrounded and the screen locked, deliveries stop after roughly 2-5 minutes. The JS runtime stops executing entirely — no logging of any kind during the gap. Deliveries resume only on a significant-location-change event or when the user foregrounds the app. Gaps of 6-7 minutes are typical on a 15-minute drive. Walking does not reproduce it. A stationary phone does not reproduce it. Only driving. Configuration (expo-location calls both startUpdatingLocation and startMonitoringSignificantLocationChanges on the same manager): desiredAccuracy = kCLLocationAccuracyBestForNavigation distanceFilter = kCLDistanceFilterNone pausesLocationUpdatesAutomatically = NO showsBackgroundLocationIndicator = YES allowsBackgroundLocationUpdates = YES activityType = CLActivityTypeOtherNavigation UIBackgroundModes includes "location" (verified at runtime) This matches the settings described as compliant in threads 726945 and 776698 regarding the iOS 16.4 change. Ruled out with logs: the app never stops the session; no app-side filter runs during the gaps; no crash or memory kill (same process before and after); queue length under 20 and handler time ~3 ms. Tested BestForNavigation + 5 m filter, Best + no filter, and BestForNavigation no filter — all three show gaps, the last is best but not cured. Two observations that may matter: immediately after each gap the first fixes have horizontal accuracy of 170-1950 m, consistent with a cold session start rather than a resume. And on one occasion a foreground watcher callback delivered a fix 264 seconds old on resume. Questions: Under what conditions does iOS 27 suspend an app with an active standard location session configured this way? Does calling startMonitoringSignificantLocationChanges alongside startUpdatingLocation affect suspension behaviour? Is CLBackgroundActivitySession or CLLocationUpdate.liveUpdates the supported path for sustained background recording on iOS 17+? Can an app detect that its session has been suspended, so it can report honestly to the user?