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.

I've been trying to mount an FSKit volume at the location where FileProvider saves files: ~/Library/CloudStorage . I've discovered that FileProvider attempts to call setAttributes in order to assign a value for an access control list (ACL). This call fails, because FSKit does not support this attribute, and causes FileProvider to stop working. FileProvider refuses to continue beyond creating it's domain folder when this occurs. Do you believe this constitutes a valid enhancement request for FSKit and/or FileProvider?

Heating issues on MacOS 27 Beta on normal browser surfing.

StoreKit 2 returns zero subscription products in Sandbox/TestFlight — FB24199369 I’m experiencing an issue where StoreKit 2 returns zero subscription products in both Sandbox and TestFlight for my iOS app. App: Bundle ID: com.sleeplessnight.naengbiseo Subscription group: Naengbiseo Premium Product IDs: naengbiseo_premium_monthly naengbiseo_premium_yearly Although the production app uses RevenueCat, I reproduced the same issue in a separate minimal native SwiftUI app using StoreKit 2 directly, with no RevenueCat, Expo, React Native, or other third-party SDK involved. Native StoreKit 2 call: let products = try await Product.products(for: [ "naengbiseo_premium_monthly", "naengbiseo_premium_yearly" ]) Current native test result: STOREKIT_COUNTRY_CODE: KOR STOREKIT_STOREFRONT_ID: 143466 DIRECT_STOREKIT_COUNT: 0 Returned products: None Test environment: Physical iPhone StoreKit Configuration: None Sandbox Apple Account signed in Storefront: KOR In-App Purchase capability enabled Correct Bundle ID and Product IDs I have rechecked the following configuration: The subscriptions are available in the test storefront Subscription pricing is configured Subscription localization is configured Paid Apps Agreement, banking, and tax information are active App ID has In-App Purchase enabled The App Store/TestFlight build has the expected Bundle ID, provisioning, and signing configuration I also created a StoreKit Configuration file using “Sync this file with an app in App Store Connect”. The sync completed, but the resulting configuration contained: products: [] subscriptionGroups: [] The same subscriptions also fail to load in TestFlight. The subscription products currently show Rejected in App Store Connect because the associated app version was rejected. App Store Connect states that the subscriptions were returned because the associated app was rejected and will remain Rejected until resubmitted for review. However, App Review also stated: “In-App Purchase products do not need prior approval to function in review.” I have reviewed TN3186 and have not found a remaining developer-side configuration issue that explains why Product.products(for:) returns zero products. Since the issue reproduces in a minimal native StoreKit 2 app, this does not appear to be caused by RevenueCat or another third-party SDK. Feedback Assistant: FB24199369 Could an App Store Commerce / StoreKit engineer advise whether there is any remaining developer-side configuration that could cause this, or whether the subscription catalog / app association may need to be reprocessed on Apple’s side? Thank you.

We submitted our first iOS app for review on August 4, 2026 (App ID: 6797034989). Today is August 12, and it has now been 8 days in “Waiting for Review”. Apple’s submission confirmation stated that 50% of apps are reviewed within 24 hours and over 90% within 48 hours. We understand that delays can happen, but 8 days is significantly longer than expected. Since August 8, we have also sent 3 emails to Developer Support regarding this issue, but unfortunately received no response. We have deadlines for our app launch and cannot keep waiting indefinitely without any information. Could someone from App Review or Developer Support please take a look at our submission and let us know if everything is OK? We would really appreciate it if the review could begin as soon as possible. Thank you.

We maintain a large file-sync app. After our upload endpoint moved to HTTP/2, we found that when multiple NSURLSessionUploadTasks run concurrently, all tasks send their request headers immediately (multiplexed on a single connection — confirmed identical localPort via URLSessionTaskMetrics), but request bodies are transmitted essentially one task at a time: while one task's body saturates the uplink, the other tasks send zero body bytes for the entire duration (countOfBytesSent == 0). This reproduces with both background sessions (BackgroundUploadTask) and default sessions (LocalUploadTask), on Wi-Fi and cellular. iOS 26.5, Xcode 26.3, tasks created with uploadTask(with:fromFile:), multipart POST. This becomes a hard failure behind a load balancer with slow-POST (RUDY) protection: requests whose first body KB doesn't arrive within 5s are rejected with 408. The starved tasks fail even though the network is healthy. For comparison, OkHttp on Android writes bodies in interleaved 16KB DATA frames under identical conditions, so all streams pass the first-KB check. Metrics excerpt (4 concurrent uploads, one h2 connection): task 1: duration 18.7s, sent 180MB (full line rate) task 2: duration 22.8s, sent 43MB (transmitted only after task 1 finished) task 3: duration 46.0s, sent 247MB (after task 2) task 4: duration 5.2s, sent 0 bytes → 408 from the gateway In one run a starved stream sent exactly 65,536 bytes (the default initial stream window) and then stalled. Questions: Is this sender-side scheduling (no round-robin between streams' DATA frames) the expected CFNetwork behavior? Does URLSessionTask.priority influence HTTP/2 stream weighting for upload bodies? Is there any other way to influence bandwidth sharing between concurrent uploads? Is there any supported way to opt out of HTTP/2 (constrain ALPN to HTTP/1.1) or cap concurrent streams per connection from the client side? We believe there isn't, but would like to confirm. What is the recommended pattern for concurrent large uploads in this situation? Filed as FB24062619 with full sanitized metrics attached. Happy to provide more data.

Hi Apple Developer Support / community, I am seeing a URL filter startup failure only in TestFlight builds. The same code path works in development and Ad Hoc builds. App setup: Host app bundle id: com.expleo.protectus.filter.main URL filter control extension bundle id: com.expleo.protectus.filter.main.buf Extension point: com.apple.networkextension.url-filter-control Using NEURLFilterManager / NEURLFilterControlProvider on iOS 26.x App Group and network extension entitlements are configured on host + extension Observed behavior: Extension process starts successfully (pid created) Status changes to starting Then updatePrefilterWithCompletionHandler runs Immediately after, plugin transitions to stopping with error 3 System retries in a loop Key logs: Error Domain=NEAgentURLFilterErrorDomain Code=3 Failed to startFilter NEPIRChecker start block reports: Error Domain=com.apple.CipherML Code=1100 Underlying Error Domain=com.apple.CipherML Code=1800 Message says details are redacted Example sequence: NEURLFilterPlugin ... started with pid ... status changed to starting updatePrefilterWithCompletionHandler enter acceptAgentClients enter setStatus:error ... NEAgentURLFilterErrorDomain Code=3 status changed to stopping with error 3 extension disposed / teardown repeats Important detail: This failure is reproducible in TestFlight only. Same code and configuration works in development and Ad Hoc builds. What we already checked: Extension launches and is discovered correctly by neagent App/extension bundle identifiers are correct App group and network extension entitlements are present in source and archive checks We tested startup gating around local bloom/prefilter readiness We still get NEMembershipCheckerErrorDomain Code=3 with CipherML 1100/1800 in TestFlight Questions: Is NEMembershipCheckerErrorDomain Code=3 in this startup path known to indicate PIR membership/status validation failure in distribution context? Are there TestFlight-specific prerequisites or server-side requirements for PIR/CipherML path that differ from development/Ad Hoc? Is there any supported way to get non-redacted diagnostic details for CipherML 1100/1800 (beyond sysdiagnose submission)? Are there recommended fail-open/fail-closed startup patterns when PIR status is temporarily unavailable? If needed, I can provide: Full sysdiagnose timestamped bundle Exact iOS version and device model Repro steps from clean install Full log stream around NEPIRChecker and NEURLFilterPlugin transitions Thanks in advance.

We are investigating an intermittent package installation failure on macOS Tahoe 26.5 and are trying to understand the conditions under which PackageKit may return the following errors during an upgrade installation: PKInstallErrorDomain Code=120 NSPOSIXErrorDomain Code=1 ("Operation not permitted") The package successfully passes validation and authorization, and pre-install scripts complete successfully. The failure occurs during the final PackageKit commit phase when PackageKit attempts to move/relink content from the installer sandbox to the destination volume. Relevant log snippets: PackageKit: Shoving /Root to / Error relinking file (primary): .../Contents/_CodeSignature/CodeResources failed _relinkFile(...) Operation not permitted PackageKit: Install Failed: Error Domain=PKInstallErrorDomain Code=120 NSUnderlyingError: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted" The issue is intermittent and only affects a subset of systems. The same package installs successfully on many machines running the same macOS version. Has anyone encountered similar _relinkFile / CodeResources failures during package upgrades? In particular, we are interested in understanding: Common causes of NSPOSIXErrorDomain Code=1 during PackageKit relink operations. Whether existing signed application bundle metadata (CodeResources) can cause relink failures during upgrades. Any Installer or PackageKit changes in recent Tahoe releases that could affect bundle replacement during package installation. Any insights would be appreciated.

Hi, I was trying to run a macOS VM under a launchd daemon as part of a requirement. The parent daemon spawns a macOS VM under root user. Sometimes this is fine, but sometimes I'm getting a security error from VZ library : Unable to access security information. The virtual machine encountered a security error. In system logs, I was able to see this : ctkd: unable to generate key: error e00002e2 for com.apple.Virtualization.VirtualMachine with SepKey ACL I think this indicates Virtualization.framework asked CryptoTokenKit/Secure Enclave to create a key, and the security subsystem rejected it in the current execution context. Is it possible to run VM this way ? If yes, what am I missing ?

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

I'm working on an iPhone app that continuously monitors device tilt with Core Motion. When the device has been held tilted forward past a threshold angle for a sustained period, the app raises a local notification. The detection has to keep running while my app is in the background. The situation I need to detect is, by definition, one where the user is looking at some other app — if my app were in the foreground, there would be nothing to detect. So a foreground-only implementation would not implement the feature at all. While testing this I ran into a behavior I would like to understand properly before I rely on it. What I observe CMMotionManager device-motion updates to a backgrounded app stop within a few seconds of the app leaving the foreground — unless a Core Location session is running at the same time. With location updates started under When In Use authorization and allowsBackgroundLocationUpdates = true, the device-motion callbacks continue for the whole time the app is backgrounded. Stop the location session, and they stop again. I built a focused sample to measure this. It starts device-motion updates at 10 Hz on a background OperationQueue and counts every callback, records the count on didEnterBackground, and on willEnterForeground logs how many arrived during the interval against how many would be expected at 10 Hz. Measured on an iPhone running iOS 26.5.2, launched from the Home screen with no debugger attached: location ON | background 137s | received 1366 / expected ~1373 (99.5%) location OFF | background 129s | received 2 / expected ~1286 (0.16%) Both callbacks in the second run arrived immediately after the transition to the background; nothing arrived over the remaining two minutes. One thing that cost me a test cycle, in case it saves someone else one: the difference only shows up when the app is launched from the Home screen. With the Xcode debugger attached the app is not suspended, and both cases deliver callbacks for the entire interval. The location session in the sample is configured as low as I can make it, since the app never reads the coordinates: manager.desiredAccuracy = kCLLocationAccuracyThreeKilometers manager.distanceFilter = 3000 manager.activityType = .other manager.pausesLocationUpdatesAutomatically = false manager.requestWhenInUseAuthorization() // started from the foreground, once authorization is granted manager.allowsBackgroundLocationUpdates = true manager.startUpdatingLocation() func locationManager(_ manager: CLLocationManager, didUpdateLocations locations: [CLLocation]) { // Intentionally empty. This sample does not use the location values. } My questions Is continuous CMDeviceMotion delivery to a backgrounded app dependent on an active Core Location session? Is that intended and expected behavior on current iOS versions, or an implementation detail I should not be relying on? If it is expected behavior, what configuration would you recommend for an app in this situation? Specifically, is kCLLocationAccuracyThreeKilometers with a large distanceFilter sufficient to sustain the session, or does reliable delivery require a higher accuracy or a smaller distance filter? Is there another supported API or background execution mechanism that delivers continuous device-motion or accelerometer data to a backgrounded app? I am aware of CMSensorRecorder for retrospective retrieval, but I need to react in near real time. I would like to be sure I am not overlooking a more appropriate API. Environment: iOS 18.0 and later, iPhone only, Swift / SwiftUI. I have the focused sample project available if it would be useful. Thanks very much for any help.

I’m building an app that contributes to a crowdsourced earthquake early warning network: the device reports anomalous accelerometer readings, a server correlates them across nearby devices, and users farther from the epicenter get a warning seconds ahead. Detection has to continue while the app isn’t in the foreground. I’ve ruled out the obvious paths — CMMotionManager stops on suspension, CMPedometer and CMMotionActivityManager only return historical data, BGTaskScheduler is too infrequent, and CMSensorRecorder is watchOS-only. I’ve also read thread 765258, where DTS confirmed there’s no background capability for accelerometer data and that repurposing another one risks rejection under 2.5.4, so I’m not looking for a workaround. Is there any supported way to do this on iOS, for instance restricted to when the device is stationary and charging? Or is this outside what the platform currently allows? Thanks.

大家好， 我们正在开发一款基于 CoreBluetooth 的 iOS 应用，希望确认 iOS 在不同应用生命周期状态下的预期行为。 我们主要关注以下几种常见场景： App 在后台运行（未被终止）； iPhone 处于锁屏状态，App 在后台运行； iPhone 处于锁屏状态，App 已被系统终止； iPhone 处于锁屏状态，App 已被用户从后台上滑关闭（Force Quit）。 当 BLE Peripheral 发生与该 App 相关的广播、连接或其他蓝牙事件时，我们想确认： 在上述不同场景下，BLE 设备是否能够触发 iOS 唤醒、启动或重新启动 App？ 如果可以，不同场景分别需要满足哪些条件（例如 CoreBluetooth Background Modes、State Restoration、连接事件等）？ 如果 App 已被用户 Force Quit，是否仍存在任何可以重新启动 App 的官方支持方式？ 锁屏状态是否会对上述行为产生额外限制？ 我们的目标是了解 iOS 官方支持的能力边界，以及不同应用状态下 BLE 与 App 生命周期的交互行为，而不是具体的实现细节。 感谢大家！

I'm trying to work out why Channel Sounding won't start on my device, and I'd be grateful for any pointers on what condition I haven't satisfied. What I see On an iPhone 17 Pro Max running iOS 27.0 beta (24A5390f), queried after the central manager reaches .poweredOn as the documentation requires: if #available(iOS 27.0, *) { print(CBCentralManager.supports(.channelSounding)) // false print(NISession.deviceCapabilities.supportsBluetoothChannelSounding) // true } No accessory or connection is involved — both are local queries. Because supports(.channelSounding) is false, the Core Bluetooth path fails with CBError code 13 ("Channel Sounding is not supported by the local or remote device"). I also tried calling startChannelSoundingSession(:) anyway, past my own capability check, against a connected peer; the same code 13 comes back from peripheral(:didCompleteChannelSoundingSession:), so it isn't merely an advisory check. The Nearby Interaction path gets further — its capability check passes, so session.run(_:) is called with NINearbyAccessoryConfiguration(bluetoothChannelSoundingIdentifier:previousBluetoothIdentifier:) against a paired, connected reflector — and then invalidates with NIErrorCodeSessionFailed (-5887). Same result with isCameraAssistanceEnabled set to both true and false. Apple's own "Measuring Distance Between Devices Using Channel Sounding" sample behaves identically on this device, so it isn't my code. What I've ruled out Querying before .poweredOn — the value is read in centralManagerDidUpdateState when the state is .poweredOn. Hardware — this is an iPhone 17 Pro Max, and Nearby Interaction's own capability check reports the hardware as capable. The Language & Region setting — changing it makes no difference. Beta staleness — updated across two betas, no change. The reflector — it implements the Ranging Service GATT server and the reflector role, and ranges successfully against another unit of its own model. What I'm unsure about The header comment for CBCentralManagerFeatureChannelSounding reads: The hardware and region supports channel sounding That's the only mention of "region" I can find in any Channel Sounding documentation — WWDC26 session 369 lists the N1 chip and the accessory-side requirements, but nothing about region, and there's no API to query that condition. My device is a South Korea market unit operating in South Korea, so I'm wondering whether that's what I'm hitting, but I have no way to confirm it. I'd also be glad to be told I'm simply wrong about something more mundane. Questions What conditions cause supports(.channelSounding) to return false on a device that has the N1 chip? Is region genuinely one of them, and if so, is it determined by the market the device was sold in, its current location, or something else? Should NISession.deviceCapabilities.supportsBluetoothChannelSounding be expected to agree with the Core Bluetooth check, or does it intentionally report hardware capability only? If the latter, is there a supported way to check Channel Sounding availability before running a session? For anyone with Channel Sounding working: which path are you using — Core Bluetooth's startChannelSoundingSession(_:), or NISession with NINearbyAccessoryConfiguration? And does supports(.channelSounding) return true for you? Question 3 is mostly to help me tell whether this is specific to my device. Thanks — happy to share more logs or a minimal reproducer if it's useful.

I have an accessory which uses both Bluetooth and WiFi to communicate with the app. I am trying to migrate to Accessory Setup Kit. However, the API expects both the bluetooth identifiers and WIFI SSID or SSID prefix in the ASDiscoveryDescriptor. The problem is we only have the WIFI SSID after BLE pairing. Our current flow looks like this: Pair via BLE Connect via BLE Send a BLE command to request WIFI settings (SSID and password) (Each device has a different SSID and password) Connect to WI-FI hotspot by calling NEHotspotConfigurationManager applyConfiguration with the retrieved credentials. Is there a way to set the Wi-Fi SSID of an ASAccessory object after the initial setup? To use Accessory Setup Kit we would need something like this: Call Accessory Setup Kit with bluetooth identifiers in the descriptor, finish the setup and get ASAccessory object. Connect via BLE Send a BLE command to request WIFI settings (SSID and password) Set the SSID of the ASAccessory to the retrieved value. Connect to WI-FI hotspot by calling `NEHotspotConfigurationManager joinAccessoryHotspot. Thanks!

Container ID: iCloud.com.bluecrestcreative.HouseholdWizard (and a brand-new test container, iCloud.com.bluecrestcreative.HouseholdWizard2 — see below) Calling persistentContainer.share(_:to:) on an NSPersistentCloudKitContainer never successfully completes against the Production CloudKit environment. The identical code works fine against Development. What I've ruled out so far, each with a real test: Stale local state — wiped the local Core Data store entirely and retried from empty. Same failure, new share/zone UUID each time. Container-specific corruption — created a brand-new CloudKit container under the same team (never used before, zero history) and pointed the app at it instead. Same failure. Permissions — confirmed full "Edit Production" access in Container Permissions for my account. Entitlements mismatch — verified identical entitlements between a working Development build and the failing Production build (only the environment key differs). Daemon/session staleness — rebooted the Mac, retried. Same failure. CloudKit Dashboard schema — "Deploy Schema Changes to Production" shows zero pending changes even after a successful share in Development, so the cloudkit.share system type doesn't appear to be tracked by the normal schema-deploy mechanism. The specific error captured from the original container (Xcode 26.6, macOS): NSCloudKitMirroringDelegate _requestAbortedNotInitialized: Never successfully initialized and cannot execute request due to error: CKError "Partial Failure" (2/1011); "Failed to modify some records"; partial errors: { cloudkit.zoneshare:(com.apple.coredata.cloudkit.share.:defaultOwner) = CKError "Invalid Arguments" (12/2006); server message = "Cannot create new type cloudkit.share in production schema" } On the brand-new test container, the failure mode was slightly different (an initial CKError Code=5 / notAuthenticated during user-identity fetch, then CKShare.url simply never populates, indefinitely), but the end result is identical: sharing never actually completes. Has anyone seen this, or know what's needed to make CKShare record creation work against Production for a container? Already have a DTS incident open (Case-ID 21466535) but wanted to ask here in parallel since code-level questions get routed here anyway.

On iPadOS 26, PDFKit runs VNRecognizeDocumentsRequest over the pages of a PDFDocument when those pages are rendered. The analysis pipelines are never released. Measured on an iPad Pro 12.9-inch 4th gen (iPad8,11), iPadOS 26.6, with a 61-page image-only scanned score: each newly-created-and-rendered PDFDocument costs about 2.7 OS threads and 20 MB, permanently. Repeatedly loading the same file from disk reached 153 threads and 1519 MB in under seven minutes, then died of an allocation failure. Nothing releases it: not replacing PDFView.document, not deallocating the PDFView entirely, not releasing the PDFDocument, and not time. With every code path in the app stopped, the thread count does not fall — it continues to rise. The stack -[PDFView visiblePagesChanged:] → +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] → -[VNImageRequestHandler performRequests:gatheredForensics:error:] → -[VNRecognizeDocumentsRequest internalPerformRevision:inContext:error:] → -[VNDetector processUsingQualityOfServiceClass:options:regionOfInterest:…] → -[VNControlledCapacityTasksQueue dispatchSyncByPreservingQueueCapacity:] Thread census at 1519 MB — 153 threads total, after 66 document loads: 66 PDFKit.PDFDocument.formFillingQueue 64 com.apple.VNRecognizeDocumentsRequestRevision1 10 ANEServicesThread 66 orphaned pipelines for 66 loads, all blocked on Vision's capacity limiter. The console also emits Invalid permutation index when reordering subregions. Index N must be less than number of subregions 1 continuously, with N increasing — and these keep arriving after all application activity has stopped. Isolation Each row is a separate run on the same device and OS, one variable changed. Counts are OS threads; baseline is 13. Configuration Result Page-stepping only on a stable document (~1000 visiblePagesChanged: events) No growth; footprint declines Recreating PDFThumbnailView on every load No growth Creating a PDFDocument and never rendering it No growth Creating + rendering, assigned to a PDFView +2.0 to +2.7 threads / +20 MB per load Creating + rendering, never assigned to any PDFView Same growth Creating + rendering, entire PDFView destroyed and rebuilt per load Same growth Two points worth drawing out: The leak occurs with no PDFView involved at all — plain PDFPage.thumbnail(of:for:) or PDFPage.draw(with:to:) on a freshly created document is sufficient. Destroying the PDFView releases nothing. Whatever retains the analyses outlives every object the application can reach. Also, for anyone who arrives here from the other PDFPageAnalyzerV2 threads: the usePageViewController(true, withViewOptions: nil) workaround does not help this. It reduces visiblePagesChanged: frequency, and page changes on a stable document leak nothing. The variable is newly rendered documents, not new pages. The switch already exists PDFView implements -setDocumentAnalysisEnabled: and -isDocumentAnalysisEnabled, plus -handleAnalysisCompletionOfPage:resultTypes:. None of these appear in any public header. With document analysis disabled, the leak disappears completely — 28 consecutive document loads with zero thread growth, and after stopping, the process released down to 6 threads and 64 MB, below its own idle baseline. It also suppresses the leak for documents never assigned to that PDFView, so whatever the flag gates is not scoped to a single view. For completeness, the per-page -setCandidateForOCR: / -setDidPerformOCR: accessors do not help: the writes land and read back correctly, and the analysis runs anyway. They appear to be state rather than policy. Request Either: Fix the leak — cancel and release analyses when the document or the view goes away; or Make documentAnalysisEnabled public on PDFView (or add an equivalent on PDFDocument). Ideally, please do both. The second costs Apple nothing: the property exists, it works, and it is exactly the control that is needed. Applications that render sheet music, engineering drawings, or any other content where document understanding provides no value are currently paying for it with unbounded memory growth and no supported way to decline. Filed as FB24211659. Happy to share the isolation harness with anyone from the PDFKit team. Related: 825803 (crash in PDFPageAnalyzerV2, FB22409977), 827781 (deadlock in the same class), 838272 / 837282 (PDFTileSurface over-release), 107007 (CGContextDrawPDFPage thread safety, open since 2018).

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

iPhone 12 pro with iOS 26.0 (23A5276f) App: https://developer.apple.com/documentation/wifiaware/building-peer-to-peer-apps We aim to use Wi-Fi Aware to establish file transfer between Android and Apple devices. Apple will act as the Publisher, and Android will act as the Subscriber. According to the pairing process outlined in the Wi-Fi Aware protocol (Figure 49 in the Wi-Fi Aware 4.0 specification), the three PASN Authentication frames have been successfully exchanged. Subsequently, Android sends the encrypted Follow-up PMF to Apple, but the Apple log shows: Failed to parse event. Please refer to the attached complete log. We request Apple to provide a solution. apple Log-20250808a.txt

I'm wondering if setting the correct activityType after initializing CLLocationManager will make the location results more accurate. locationManager = CLLocationManager() locationManager.distanceFilter = 20 locationManager.activityType = .fitness

I'm testing iOS 27 and face this issue that the accessoryImage on the CPListItem is no longer shown properly. It works fine up until iOS 26.5 but on 27 it is way to small. Check attached screen shot for details. Also filed FB23903072, hope this gets fixed before iOS 27 final arrives. 🤞