Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

On Apple silicon macOS 27.2 build 26B123, consider a launchd-managed supervisor making one posix_spawn call to start a dedicated worker. The supervisor may exit before receiving the PID or before it can wait for the child. Is there a supported API or OS-issued record that lets a surviving observer verify what happened to that one attempt? Can the observer distinguish an attempt that created no child from one that created a child before the caller received the PID? What stable identifier ties creation and any exec transition to that attempt? If the supervisor exits, which component actually performs the reap? Can the observer verify the same child's exit status, completed reap, and absence of surviving descendants after restarting? Please identify the supported macOS versions, privileges, record source, correlation fields, and any loss or retention limits. If no supported record covers a step, please identify that boundary.

Step: Create and persist a model. Encode its persistentModelID using JSONEncoder. Decode the encoded data back into a PersistentIdentifier. Use the decoded identifier in a FetchDescriptor predicate to fetch the model. Modify a property of the model without saving the context. Execute the exact same fetch again, using the same decoded PersistentIdentifier and the same predicate. Example: do { let item = Item() modelContext.insert(item) try modelContext.save() // Encode and decode the persistent identifier. // The decoded identifier is essential to reproduce the issue. let data = try JSONEncoder().encode(item.persistentModelID) let decodedPID = try JSONDecoder().decode( PersistentIdentifier.self, from: data ) func find(_ pid: PersistentIdentifier) throws -> Item? { let descriptor = FetchDescriptor<Item>( predicate: #Predicate { $0.persistentModelID == pid } ) return try modelContext.fetch(descriptor).first } // First fetch succeeds. var result = try find(decodedPID) print("0. Found: \(result != nil)") // true // Modify the persisted model without saving the context. item.timestamp = .now.addingTimeInterval(-3600) // Second fetch uses exactly the same PID and predicate, // but unexpectedly fails. result = try find(decodedPID) print("1. Found: \(result != nil)") // false } catch { print(error) }Actual Behavior: The first fetch successfully finds the model. After modifying one of its properties without saving the context, the second fetch returns an empty result, even though: The same ModelContext is used. The same decoded PersistentIdentifier is used. The same predicate is used. The model has not been deleted. No save operation has occurred between the two fetches. Expected Behavior: The second fetch should return the same model. Changing an ordinary property of a model without saving should not invalidate its persistent identity or cause a predicate matching that identity to stop finding the model. Additional Observations: If the original item.persistentModelID is used directly instead of the decoded identifier, the issue does not occur. If the model is not modified between the two fetches, both fetches succeed. Questions: Is it expected that a PersistentIdentifier restored through Codable can be used in a SwiftData predicate? Why does a predicate using a decoded PersistentIdentifier stop matching a model after an unsaved property or relationship change? Is this a known issue or a limitation of using persistentModelID inside a #Predicate? What is the recommended way to persist a PersistentIdentifier and subsequently use it to fetch the corresponding model across different operations or app launches?

Hello, We are developing an iOS app that helps people review their device use through daily carbon estimates, a garden, local history and Home Screen widgets. All processing stays on the device. We want users to grant permission without choosing each app or entering daily figures. The app has Family Controls distribution approval and the Family Controls App and Website Usage capability. However, the documentation for approvedWithDataAccess describes customer access for a device in the EU with an Apple Account set to an EU country or region. The Apple-provided development profile allows testing in other regions, so we do not treat a successful development test in Switzerland as approval for Swiss customers. Could an Apple engineer clarify the supported design for users located in Switzerland with a Swiss Apple Account? Is there a documented API, entitlement or approval route for direct app-duration access in this situation? If direct access is unavailable, can ordinary individual authorization and DeviceActivityReport show all available activity without an app-by-app picker? Under the report extension's privacy rules, can a daily result be made available to the main app's history and widgets through any supported mechanism, or must it stay inside the report? Do TestFlight installations follow the same regional conditions as App Store installations? We are looking for a design that follows the published access and privacy rules. We do not want to infer missing activity, work around regional restrictions, or treat development access as customer approval. Documentation: https://developer.apple.com/documentation/familycontrols/authorizationstatus/approvedwithdataaccess Thank you for any guidance.

I am developing a macOS window-management utility for a new Mac App Store submission, targeting macOS 13+ on Apple silicon and supported Intel Macs. Its core function is to move and resize windows belonging to other, unmodified applications, in response to explicit menu commands, registered keyboard shortcuts, or optional edge-drag snapping. The current unsandboxed engineering implementation uses public Accessibility APIs: AXUIElementCreateApplication, AXUIElementCopyAttributeValue / AXUIElementCopyMultipleAttributeValues for window geometry, AXUIElementCopyElementAtPosition for drag targeting, and AXUIElementSetAttributeValue for AXPosition and AXSize. It requires explicit Accessibility consent. Window information is processed locally; the app does not transmit it. I understand that App Review Guideline 2.4.5(i) requires App Sandbox and that “Protecting user data with App Sandbox” lists assistive Accessibility API use as incompatible. The DTS answer in thread 789663 also explains that sandboxed apps cannot use Accessibility APIs, while noting that some use cases have alternatives. For this specific cross-application positioning/resizing use case: Is there a currently supported public API or documented, requestable entitlement that permits it in a newly submitted sandboxed Mac App Store app? If a supported alternative exists, what API/architecture and minimum OS requirements apply, including any approval process? If there is no supported route, can you confirm that this functionality cannot currently be delivered within the described sandboxed Mac App Store constraints? I am seeking a supported architecture for controlling other apps’ windows. The unsandboxed tests establish functionality only; they do not establish sandbox compatibility or App Review eligibility. References: https://developer.apple.com/app-store/review/guidelines/#hardware-compatibility https://developer.apple.com/documentation/security/protecting-user-data-with-app-sandbox https://developer.apple.com/forums/thread/789663

Since November 5, in-app subscriptions have suddenly stopped working in all three of my apps on the App Store. Everything worked perfectly before, and no changes were made to the apps. The subscription purchase buttons no longer display prices, only a dash ("–"). Existing apps can still be downloaded normally. I reproduced the problem in Xcode on my own device. StoreKit reports: STOREKIT: Received 0 products STOREKIT: Invalid IDs = ( "TEE_year", "TEE_month", "TEE_week" ) All subscription products are still configured in App Store Connect, and the agreements appear to be active. Interestingly, the problem started around the time I accepted updated Apple agreements and changed my address in my developer account. I don't know whether this is related. Several customers have already independently reported the same problem, so this is not limited to my own device or Apple ID. I strongly suspect an App Store Connect or StoreKit backend issue rather than an app-specific programming error. I've contacted Apple Developer Support (case ID is 30000008123797) but haven't received a solution yet. Has anyone else experienced subscriptions suddenly becoming unavailable across multiple apps? Could this be related to updated agreements or account information?

Subject: Supported fail-closed ACL absence verification on macOS 27.0.1 / APFS Environment: macOS 27.0.1, build 26A434; APFS; installed macOS 27.0 SDK. We need a supported, documented way to determine whether an existing filesystem object has no effective ACL entries, while rejecting genuine retrieval failures and unsupported or unavailable ACL evidence. We are seeking clarification of the public interface contract, not alleging an Apple defect. For existing directory and regular-file fixtures, pathname metadata and descriptor metadata identify the same object. Errno is cleared immediately before each native call and captured immediately afterward. ACL retrieval uses ACL_TYPE_EXTENDED: acl_get_file(path, ACL_TYPE_EXTENDED) acl_get_fd_np(fd, ACL_TYPE_EXTENDED) On fresh objects, both return NULL with ENOENT. Explicit one-entry fixture ACLs are retrieved successfully. Explicit zero-entry fixture ACLs can also yield NULL/ENOENT, while attribute queries return a serialized zero-entry ACL. The attribute queries use getattrlist() and descriptor-bound fgetattrlist(), requesting ATTR_CMN_RETURNED_ATTRS | ATTR_CMN_EXTENDED_SECURITY, with FSOPT_NOFOLLOW | FSOPT_REPORT_FULLSIZE and WITHOUT FSOPT_PACK_INVAL_ATTRS. Buffer lengths, variable-reference bounds and returned-attribute validity are checked. For the existing directories of interest, both calls succeed but omit the ATTR_CMN_EXTENDED_SECURITY returned bit. Explicit populated and zero-entry fixture records do set the bit. APFS reports valid VOL_CAP_INT_EXTENDED_SECURITY support; we do not assume that volume capability proves per-object ACL availability. On macOS 27.0.1, build 26A434, using APFS, which supported interface and documented conditions allow software to distinguish an absent ACL from unavailable or unsupported ACL evidence when descriptor-bound attribute queries succeed but omit ATTR_CMN_EXTENDED_SECURITY and native ACL getters return ENOENT for an existing object? Please clarify: Whether ENOENT has a supported ACL-absence interpretation, and under exactly which checked conditions. Whether an omitted extended-security attribute can establish ACL absence, rather than unavailable or unsupported evidence. How explicit zero-entry ACLs differ from absent ACL records through supported interfaces. How KAUTH_FILESEC_NOACL should be interpreted through supported APIs. How genuine retrieval failures, including permission, I/O, allocation and unsupported-operation errors, must remain distinguishable. Whether a supported descriptor-bound verification method exists that preserves fail-closed security checks and object identity binding; please identify its guarantees and limitations regarding pathname/ancestor changes and later operations. Whether relevant behavior is specific to this macOS/APFS version. Please identify the applicable public documentation or supported verification sequence. We do not want to modify permissions, synthesize ACLs on target objects, treat invalid-attribute defaults as real evidence, or accept ambiguous omission/ENOENT as success. Existing ownership, mode and confinement checks must remain separate mandatory checks. If no public API can make this distinction reliably, please state that limitation.

I’m investigating delayed HealthKit background delivery in an iPhone calorie-tracking app installed through TestFlight. The app reads activeEnergyBurned and submits a local notification with a custom sound for every newly accumulated 20 kcal. The intended behavior is passive: the user walks normally without explicitly starting a workout. Current behavior: Rewards appear after opening the app. Unlocking the phone to the iPhone Home Screen does not trigger the accumulated rewards. The app is backgrounded, not force-quit. A separate local notification scheduled 10 seconds ahead successfully displays and plays its custom sound while the phone is locked. Implementation: An HKObserverQuery for activeEnergyBurned, with predicate nil, is registered during application(_:didFinishLaunchingWithOptions:). Background delivery is requested with frequency .immediate. The installed TestFlight app has the HealthKit and HealthKit background-delivery entitlements. With valid locally stored access, Health processing does not wait for a StoreKit subscription query. In the captured trace, observer callbacks complete promptly and healthd reports no outstanding launches afterward. Recorded test on November 7, 2026 (device-log times, UTC−07:00): Around 07:03, I manually added 40 kcal in Apple Health. At 07:03:42, Health received an added sample. healthd scheduled the next Active Energy background launch for 08:03:14, approximately one hour after our previous observer completion. At 07:05:42, I unlocked to the Home Screen. Protected Health data became available, but no corresponding observer callback reached our app. At 07:08:40, I opened our app. Its observer callback arrived immediately, and two reward notification requests were accepted without error. Earlier development installations appeared to deliver accumulated rewards upon unlocking to the Home Screen, even after the debugger had disconnected. Subscription integration occurred between those versions, but we have not established the cause of the difference. My questions: Is an approximately one-hour interval expected for activeEnergyBurned on iPhone despite requesting .immediate? Can foreground observer completions advance the next permitted background delivery time? Is there a supported way to receive pending Active Energy updates after unlocking, without opening the app or starting an HKWorkoutSession? I can provide targeted implementation details and additional relevant log excerpts if needed. Thank you.

I purchased the $99 membership 2 weeks ago and it’s still pending; is there any solution to this?

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.

Hello, I’m a paid Apple Developer Program member and I want to share my frustration with Apple Developer Support. I have emailed Developer Support 5 times about my App Store Connect issue and have received no reply at all. My case ID is 30000005720177, but nobody has updated me on it in any way. For a company of Apple’s size, this level of unresponsiveness is unacceptable. I pay for my membership, so I expect at least basic communication. What I think needs to change: Clear status updates: Even if a fix takes time, developers should be told so properly, with an estimated timeline. A real contact person: A case ID alone is not enough. There should be a named person or team we can follow up with. 24/7 live support: Apple has developers in almost every country and time zone. Round-the-clock live support should be standard for a company this big. I’m very disappointed with this experience. If anyone from Apple sees this, I’d really appreciate a response on my case 30000005720177. If other developers have run into the same problem, I’d like to hear how you got a response. Thank you.

On Apple silicon macOS, is there a supported public mechanism that can enforce a hard combined mapped virtual address-space ceiling of 512 MiB for a parent process and its new child from the first charged creation step through loading the child's executable image, before the child runs any application code? The current investigation targets macOS build 26B123 on arm64. We need to know how the supported limit accounts for inherited maps, shared-region reservations and image mappings during process creation. If the supported route is to partition the ceiling between per-process limits, please specify whether the child limit applies before its first charged map and how a limit failure is reported. Please identify the public API or documentation, supported OS versions and required setup. A control that only applies to resident memory or starts after application code begins would not cover this question.

I have been waiting for over 2 weeks now for getting my account activated, and now the account is still pending? Is there any solution please? Best regards Kais

Is there a publicly supported macOS API, entitlement, or framework capable of enforcing a hard 64 MiB aggregate memory ceiling across a process tree, including its supervisor, observer, and descendants? Enforcement must be established before workload execution, survive fork/exec, and remain effective if the controlling process crashes. We have examined per-process resource limits and process-memory reporting, but these do not establish the required aggregate guarantee. If supported, which API and enforcement mechanism should we use? If not, is there a documented platform limitation?

Device and software: iPhone model: iPhone 15 Pro iOS 27 Public Beta 6 Build: 24A5430a BLE receivers: two independent ESP32's IRK has worked reliably on iOS 26 and past versions. Observed behavior: With the iPhone display on both BLE receivers detect advertisements that resolve correctly using the enrolled IRK. No more than 10 seconds after the display is turned off, the IRK-resolvable advertisements stop. The IRK identity returns immediately when a notification wakes the display or when I manually do. Bluetooth itself remains active while this happens. The receivers continue to see several strong advertisements from the phone with some unidentified rotating addresses. The unidentified addresses rotate periodically and cannot be associated with the enrolled IRK. Additional observations: When my Apple Watch is powered on and connected, the iPhone remains IRK-detectable while the screen is off. It stops again when watch is disconnected. Connecting Bluetooth headphones does not have the same effect. The IRK-resolvable advertisement stops even while music continues playing. Moving the affected phone between two receivers confirmed that the unidentified rotating advertisements physically followed the phone. The existing IRK remains valid because it resolves the phone again immediately whenever the display wakes. I couldnt find any intentional IRK, private-address or screen-off advertising change documented in the iOS 27 release notes or any discussions online. Has anyone else observed this on iOS 27?

Summary Recent macOS release observed intermittent system-wide DNS failures after sleep/wake on multiple devices running Global Secure Access (GSA) with NETransparentProxyProvider. Previously successful DNS lookups time out after wake across applications, including browsers and GSA. Two captures contain failure-time evidence of the mDNSResponder resolver queue predominantly waiting in close()/kernel. Other captures show similar DNS failures, but a shared root cause has not been established. Call chain, from thread entry to kernel wait: start_wqthread + 8 _pthread_wqthread + 292 _dispatch_workloop_worker_thread + 720 _dispatch_root_queue_drain_deferred_wlh + 284 _dispatch_lane_invoke + 392 _dispatch_lane_serial_drain + 332 _dispatch_source_invoke + 920 _dispatch_source_cancel_callout + 208 _dispatch_continuation_pop + 596 _dispatch_client_callout + 16 close + 8 fleh_synchronous + 72 sleh_synchronous (sleh.c:1610) unix_syscall (systemcalls.c:181) fp_close_and_unlock_with_action (kern_descrip.c:1874) fg_drop (kern_descrip.c:287) soclose (uipc_socket.c:1345) soclose_locked (uipc_socket.c:1138) cfil_sock_close_wait (content_filter.c:5743) soflow_db_apply (socket_flows.c; line unavailable) cfil_filters_udp_attached_per_flow (content_filter.c:6675) _sleep (kern_synch.c:213) lck_mtx_sleep_deadline (locks.c:1583) thread_block_reason (sched_prim.c:4060) thread_invoke (sched_prim.c:3443) Steps to reproduce The issue is intermittent. These steps describe the observed sequence, not a deterministic minimal reproduction. Run the GSA client using NETransparentProxyProvider. The affected configurations also have Microsoft Defender network extensions active. Verify that a system DNS lookup succeeds for a known hostname. Allow the Mac to sleep, including maintenance DarkWake cycles. Wake the Mac and repeat system DNS lookups or use applications requiring hostname resolution. Observe repeated approximately 30-second lookup timeouts, sometimes longer. Observed results November 5, 2026 - UTC+05:30 capture User-reported impact: Recurrence of the same sleep/wake connectivity symptoms. OS: macOS 27.2 (26B123). Incident window: 20:38-20:41 IST / 15:08-15:11 UTC. The same Chrome client/name A lookup succeeds earlier in 12.984 ms but times out after wake in 29,999.705 ms. The DNS service/server route changed, so this is not a controlled identical-network comparison. The resolver records 1,007 timeout callbacks during the incident window, across browsers, Teams, GSA, Defender and other processes. The failure-time spindump at 20:40:21.009-20:40:31.013 IST shows the original mDNSResponder PID 78534 with 715/715 resolver-queue samples under dispatch-source cancellation → close() → kernel → lck_mtx_sleep_deadline. Source: spindump.txt:75998-76093. This establishes a sampled wait, not a permanent deadlock or proof of the same root cause as November 2. The file descriptor and kernel/filter wait owner remain unidentified. A later matching Chrome lookup returns an address at 20:43:18.191816 IST on the same resolver PID, without a recorded resolver restart. This establishes some recovery, not that every application or tunnel recovered. November 2, 2026 - UTC-08:00 capture User-reported impact: No network upon wake. This eventually resolves without a reboot, after approximately 5 to 15 minutes of waiting. OS: macOS 27.2 (26B123). Incident window: 09:40-09:45 PST / 17:40-17:45 UTC. The same Edge A lookup succeeds before sleep in 19.346 ms but times out after wake in 29,999.826 ms. The resolver records 1,403 timeout callbacks during the incident window. The failure-time spindump shows 770/777 resolver-queue samples under dispatch-source cancellation → close() → kernel; 769 include lck_mtx_sleep_deadline. This establishes a dominant sampled wait, not a permanent deadlock. The file descriptor and kernel/filter wait owner remain unidentified. November 3, 2026 - UTC-08:00 capture (Mihai) Evidence: mihai_gsa_error.tar.gz The following example records a failure resolving GSA’s own control-plane endpoint, whose DNS lookup is not intercepted by the GSA tunnel. Times in these excerpts are local (UTC-08:00). GSA error [2026-11-03 10:13:58.463] Network connection to the Global Secure Access Edge could not be established StreamId: ControlStream Hostname: <tenant>.auth.client.globalsecureaccess.microsoft.com:443 Error: hostname lookup error: Address lookup failed os_error: nodename nor servname provided, or not known syscall: getaddrinfo mDNSResponder records 10:13:19.663661 [R125367->DupQ50990->Q38408] Duplicate question <private> dn:04wpeA (Addr) 10:13:58.468519 [R125367] DNSServiceQueryRecord STOP -- name hash: dn:04wpeA, duration: 39s 10:13:59.078847 [R125340] QueryRecordOpCallback: Question <private> dn:04wpeA (Addr) timing out, InterfaceID 0x0 Additional observations The original resolver records 11 timeout callbacks across GSA, Defender, Spotify and the system time service. A GSA A-query returns a positive result in 1.282 ms earlier (cache-compatible, not a cold upstream baseline), then the same client/name/qtype/flags times out after 41.865784 wall-clock seconds; that interval includes sleep. The DNS service/server set changes, so this is not a controlled same-network comparison. At 09:40 PST the Wi-Fi interface becomes inactive and loses its IPv4 address, followed by no-dns-service results. The first native lookup errors precede this link loss; it does not explain the entire case. Four GSA A/AAAA timeout transactions have matching late UDP replies. For one A-query, the reply is logged 25.095999 seconds after its matching send and 7.197434 seconds after the API timeout, during shutdown. 48 acceptable UDP response records appear within 1.467 ms. The location of the delay is not identified.

Hello Apple Developer Forum, We have implemented the Declared Age Range API exactly as described in Apple's documentation. Our implementation checks isEligibleForAgeFeatures before calling requestAgeRange, as recommended. We have been testing with different users located in Texas (US) and Brazil. However, for all users, isEligibleForAgeFeatures consistently returns false, so the Declared Age Range prompt is never displayed. We would appreciate some clarification on the following: Under what conditions does isEligibleForAgeFeatures return true? When is the Declared Age Range prompt expected to be shown? Besides the user's region, are there any additional eligibility requirements, such as whether the Apple ID has a verified payment method (credit/debit card), verified identity or address, account age or a phased rollout? Since all of our test users are in supported regions (Texas and Brazil), we expected at least some users to be eligible. However, all four test accounts consistently return false. Could you please clarify how Apple determines eligibility for the Declared Age Range feature and when developers should expect the prompt to appear? Thank you for your guidance.

Summary A minimal read-only FUSE-T filesystem cannot be mounted over a newly created, empty directory on an external APFS volume. FSKit reaches the LIFSv2 mount stage, but the final mount(2) returns EPERM. In the same timestamp window, sandboxd requests kTCCServiceSystemPolicyRemovableVolumes on behalf of root /usr/libexec/fskitd. The request is forwarded to com.apple.tccd.system, but TCC logs an invalid XPC connection and sends an empty reply with no auth_value. sandboxd then reports the missing authorization value and denies the request; fskitd immediately reports mount(2) error 1. No user-facing consent prompt appears. This looks like an authorization handoff or policy-integration failure in the system FSKit mount path, rather than a denial returned by the filesystem implementation. The exact reason com.apple.tccd.system returns an invalid or empty reply is unknown. Environment ItemValueTest date/time2026-11-06, approximately 18:47:31 CETMacApple silicon (arm64)macOS27.2, build 26B123FUSE-T receiptsorg.fuse-t.core.1.2.9, org.fuse-t.fskit.1.2.9Registered FSKit extensionorg.fuset.fskit-srv.module, version 0.1.3FUSE-T library/Library/Application Support/fuse-t/lib/libfuse-t-1.2.9.dylibTarget volumeWDBlack4TB, /dev/disk8s1; case-sensitive APFS; owners enabled; read/write; diskutil reports Protocol: PCI-Express and Device Location: ExternalMount pointNewly created, empty directory on the target volume; owned by logged-in user (UID 501), mode 0700Minimal reproduction Enable/register the FUSE-T FSKit extension using its normal installation flow. Build or use a minimal read-only FUSE filesystem whose callbacks expose only the root directory and one static hello.txt file. The fixture used here was linked directly to FUSE-T 1.2.9 and did not read backing files or modify the target volume. As the logged-in user (UID 501; no sudo), create a new empty directory on an external APFS volume. Start a bounded unified-log capture for fskitd, sandboxd, and tccd, then run: ./hello -f -o backend=fskit <empty-directory-on-external-volume> Observe the mount failure and preserve the same-window logs. Actual result The FUSE process exits 1 and prints: fuse: mount failed with error: -1. No mount is created at the test path. fskitd finds/starts the FSKit extension instance and reaches “will mount over LIFSv2”. The final mount(2) fails with errno 1 (EPERM / “Operation not permitted”). The TCC events below occur at the same timestamp as the mount(2) error. No permission prompt is shown to the logged-in user. Timestamp-correlated attribution and authorization evidence At 18:47:31.793, fskitd enters the LiveFS mount path. At 18:47:31.801, tccd records the relevant attribution chain: accessing={TCCDProcess: identifier=com.apple.fskitd, pid=36573, auid=0, euid=0, binary_path=/usr/libexec/fskitd} requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=472, auid=0, euid=0, binary_path=/usr/libexec/sandboxd}At 18:47:31.824, TCC logs a platform-binary prompting policy of Deny. In this trace that message is associated with a separate SystemPolicyAllFiles check; the All Files result is not being presented as the final Removable Volumes denial. At 18:47:31.829, sandboxd checks kTCCServiceSystemPolicyRemovableVolumes for fskitd. Because the audit token has auid=-1, sandboxd routes the authorization request based on euid 0 to com.apple.tccd.system. The request includes fskitd’s audit token (pid 36573, auid -1, euid 0). The system tccd endpoint returns an invalid XPC connection / an empty reply without auth_value. The relevant messages are: sandboxd: checking kTCCServiceSystemPolicyRemovableVolumes for fskitd sandboxd: auid = -1; routing based on euid (0) instead tccd: REQUEST ... tccd_uid=0 ... service=kTCCServiceSystemPolicyRemovableVolumes sandboxd: RECV ... { count = 0 ... contents = } sandboxd: Error ... Code=2 "missing 'auth_value' in reply message" tccd: XPC forwardMessage error: Connection invalid tccd: sending empty reply ... auth_value absent sandboxd: kTCCServiceSystemPolicyRemovableVolumes denied by TCC for fskitd fskitd: mount(2) error: 1 fskitd: mount launch failed with result "Operation not permitted"The same EPERM/TCC failure was seen in earlier diagnostic attempts and again in this fresh invocation; this run provides the full timestamp-correlated attribution capture. It happens before a successful mount. The captured report contains the exact log lines selected from the bounded unified-log stream. Expected behavior / questions for Apple Is kTCCServiceSystemPolicyRemovableVolumes expected to authorize the final LIFSv2 mount performed by fskitd when a client asks to mount over a directory on external APFS? For a root system daemon with auid=-1, should sandboxd route this request to com.apple.tccd.system? Why does that endpoint return an invalid connection / empty reply rather than an authorization result? What is the supported authorization flow for this case? Should a user-consent prompt be shown to the initiating application, or should the system broker authorize fskitd using the caller’s audit token or security-scoped destination access? If this mount operation is unsupported by design, could the documentation or returned error distinguish that policy from a generic EPERM? Impact FSKit-based user-space filesystems cannot mount into an existing folder on this external APFS volume, despite the empty mountpoint being owned by the user and despite the FSKit extension loading successfully. This blocks applications that must expose a virtual filesystem at the user-selected original folder. The failure is in the system mount / authorization path; the minimal filesystem does not implement writes or access external backing data. Limitations This reproduction establishes the behavior on one Apple-silicon Mac, macOS 27.2 (26B123), FUSE-T 1.2.9, and one external APFS volume. It does not establish whether this is a general macOS defect, a machine-specific TCC daemon condition, or an intentional policy with a broken authorization response. The cause of com.apple.tccd.system’s invalid XPC reply remains unknown.

I've just bumped into a weird problem. I've created a pretty simple and perfectly working event trigger with a non-trivial predicate which is just an AND of two characteristic-value ones. Then I've renamed it in the Home application, and it stopped working. A dump suggests the cause is a broken predicate, for it looks now rather differently — one of those two characteristic-value predicates seems broken (details below). Is that possible? Could please someone check whether the problem is really a Home ugly bug, or whether I do something wrong at my side? Versions are macOS 27.0.1 (26A434) Home 11.0 (1241.1.7.4.3) I would gladly post a bugreport, but at this moment I am far from being sure I do not overlook something of importance myself. Thanks! My code — for clarity stripped of all the error checking and reporting — looks like this: HMHome *home=...; HMCharacteristic *knihovna=..., *stul=..., *sklenik=...; // light chars, found by names HMActionSet *switchOff=...; // trivial switch-off for another light, found by name HMEventTrigger *trigger=...; // found by name if exists if (trigger) { // if found, the predicate is logged out and that's all NSLog(@"=== predicate found: %@", trigger.predicate); return; } // otherwise, the trigger and predicate are created this way: HMCharacteristicEvent *evt=[[HMCharacteristicEvent alloc] initWithCharacteristic:sklenik triggerValue:@1]; NSPredicate *p1=[HMEventTrigger predicateForEvaluatingTriggerWithCharacteristic:knihovna relatedBy:NSEqualToPredicateOperatorType toValue:@1]; NSPredicate *p2=[HMEventTrigger predicateForEvaluatingTriggerWithCharacteristic:stul relatedBy:NSEqualToPredicateOperatorType toValue:@1]; NSPredicate *p=[[NSCompoundPredicate alloc] initWithType:NSAndPredicateType subpredicates:@[p1, p2]]; NSLog(@"=== predicate created: %@", p); HMEventTrigger *et=[[HMEventTrigger alloc] initWithName:@"TEST-ONLY" events:@[evt] predicate:p]; [home addTrigger:et completionHandler:^(NSError *error) { if (!error) [et addActionSet:switchOff completionHandler:^(NSError *error) { if (!error) [et enable:YES completionHandler:^(NSError *error) { if (!error) NSLog(@"=== success!"); }]; }]; }];As already mentioned, the trigger works perfectly (is trivial enough, would be weird if not). When created and also later, when found by name, the predicate looks like this: === predicate found: (characteristic == <HMCharacteristic, Unique ID: 7444CCCE-1C1B-5234-8CAE-01DA4D811B8B, Type: 00000025, Instance ID: 9> AND characteristicValue == 1) AND (characteristic == <HMCharacteristic, Unique ID: 2E046807-9127-565F-B9CB-10BC0F2EE6D2, Type: 00000025, Instance ID: 9> AND characteristicValue == 1)Then, I just go to the Home application and rename the trigger, nothing else. It immediately stops working properly, and from that moment on, the predicate looks like this — note the difference: === predicate found: characteristic == <HMCharacteristic, Unique ID: 2E046807-9127-565F-B9CB-10BC0F2EE6D2, Type: 00000025, Instance ID: 9> AND (characteristic == <HMCharacteristic, Unique ID: 7444CCCE-1C1B-5234-8CAE-01DA4D811B8B, Type: 00000025, Instance ID: 9> AND characteristicValue == 1)

Hi, I'm having an issue, My app has disappeared from the app store all of a sudden without any email or warning, when I checked my account, App Store connect says Pending Agreement on my app but on the same page it says my membership has expired even tho its been only 2 or 3 months since I purchsed apple developer account. Current status shown in App Store Connect: "Developer Program Membership Expired" – my apps have been removed from the App Store "Pending Agreement" – the updated Developer Program License Agreement cannot be signed The core problem: I purchased my Apple Developer Program membership only about 2 or 3 months ago, so it cannot legitimately have expired. I have received no email notification about any membership expiration or agreement change. Despite this, the system now shows my membership as expired and my app has been removed. Most importantly, there is no renewal button and no agreement accept button anywhere in my account (developer website or App Store Connect), so I cannot resolve this myself. This appears to be a system error on Apple's side, not an actual expiration. What I have already tried: Checked the Membership section on developer.apple.com/account — no renewal option Checked App Store Connect Agreements section — no agreement to accept Checked App Store subscription management Contacted Apple Developer Support by email multiple times — no response received Please help.

Hello, Our iOS app has been rejected four times under Guideline 2.1(a) because sign-in fails on the review iPad. The latest rejection showed NSURLErrorDomain error -1001 (the request timed out) on an iPad Air 11-inch (M3) with iPadOS 27.0, on November 5, 2026, at about 11:54 UTC. The same happened on October 16, 2026. Setup: API: https://wp.pavilion.az, HTTPS on port 443, fixed DNS name DNS and proxy on Cloudflare (IPv4 and IPv6), publicly trusted certificate The app uses URLSession, with no custom certificate checks and no proxy settings What we checked: Neither our origin server nor Cloudflare logged any request from the review device on either day. Other clients were served normally during the same minutes. The domain resolves normally from many public DNS resolvers in the United States and Europe, over IPv4 and IPv6. The app signs in in under one second on an iPad simulator in a data center in Los Angeles, and on our own devices through TestFlight. This looks similar to https://developer.apple.com/forums/thread/773444, where a Cloudflare-hosted domain resolved to a wrong address inside Apple's network. Could someone from Apple check how wp.pavilion.az resolves, and whether it is reachable, from the App Review network? We have resubmitted a build that adds a short network check to the error message (the DNS result and which connection step fails), but each review cycle takes many days. Thank you.