I'm developing a macOS security tool using NEFilterDataProvider as a system extension. On macOS 26 beta (25E241), sysextd consistently rejects my extension with: sysextd: no policy, cannot allow apps outside /Applications Configuration: App installed in /Applications/ Signed with Developer ID Application (693DSH8GN5) Entitlement: com.apple.developer.networking.networkextension = content-filter-provider com.apple.developer.system-extension.install = true Developer Mode enabled on test machine Comparison with Little Snitch: Little Snitch runs correctly on the same machine. Key differences I found: Little Snitch uses content-filter-provider-systemextension instead of content-filter-provider Little Snitch has com.apple.security.app-sandbox = false Both signed with Developer ID Application When I switch to content-filter-provider-systemextension, Xcode rejects every provisioning profile because none match that entitlement value, and the Developer Portal doesn't expose fine-grained control over the Network Extensions array values. Questions Is content-filter-provider-systemextension the correct entitlement for system extensions on macOS 26? How should the provisioning profile be configured to support it? Is there a known sysextd issue on macOS 26 beta causing this regardless of configuration? Is there - somewhere! - a guide on how to build such an extension? Thanks in advance for your help.

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 am working on a Launch Daemon (part of a DLP). One of its requirements is to modify PDF files on the fly—specifically, to reduce the page count and truncate the document to meet specific size criteria. I am planning to use the CoreGraphics framework, specifically CGPDFDocumentRef, CGPDFPageRef, and CGDataConsumerRef to rebuild the document in memory and write the modified version. However, since CoreGraphics is historically tied to the graphic subsystem, could you please confirm if the specific PDF-handling subset of CoreGraphics (CGPDFDocument, CGPDFContext) is completely session-independent, memory-safe, and daemon-safe to use from a launch daemon context without any Aqua session? If using CoreGraphics in this context is discouraged, what are the recommended best practices or native alternatives for performing headless PDF modifications within a system daemon on modern macOS? Thank you in advance!

I am testing NEURLFilter on macOS using the SimpleURLFilter sample, and I am seeing a failure from neagent while it is saving the local URL prefilter Bloom filter to its mmap file. The relevant log is: neagent +[NEBloomFilter mmapToFile:data:dataLength:numberOfBits:numberOfHashes:murmurSeed:tag:]: NEBloomFilter - failed to open mmap file /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.com.example.apple-samplecode.SimpleURLFilterTC3Q7MAJXF <errno 13 - Permission denied> neagent <NEAgentURLFilterExtension: 0xc8ce64280>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to save first fetch of pre-filter data Environment: macOS: 26.5.1 (25F80) Xcode: 26.5 (17F42) Platform: macOS Signing type: Apple Development (automatically manage signing) What I am doing: Build and run the containing app. Save and enable the NEURLFilterManager configuration. The URL filter provider starts. The provider's prefilter code is reached. neagent logs the mmap failure above while trying to open a temporary file under /private/var/db/urlPrefilter. Expected result: neagent should be able to create or open its system-managed URL prefilter cache / mmap file under /private/var/db/urlPrefilter, and the local Bloom filter should be loaded successfully. Actual result: neagent fails to open the temporary mmap file with errno 13 Permission denied: /private/var/db/urlPrefilter/com.apple.networkextension.url-prefilter-data.temp.<bundle/team-specific suffix> I am not manually creating, modifying, or chmod/chown-ing /private/var/db/urlPrefilter or anything inside it. The directory and its contents are entirely system-managed. The failure appears to happen inside neagent while it is handling the system-managed URL prefilter cache. The failure occurs at the mmapToFile: step while neagent saves the Bloom filter prefilter data. Directory state: drwxr-xr-x 2 root wheel 64 /private/var/db/urlPrefilter Has anyone else encountered this? Any suggestions on what could cause neagent to fail with errno 13 on its own mmap file under /private/var/db/urlPrefilter?

Hi All, We build a new feature according to the Apple docs: In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. and based on that we proceeded with our development, our but in our appclip we are not able to see the wallet capability in the developer portal but for our main application the wallet is there and we enabled it and therefore the com.apple.developer.pass-type-identifiers entitlement has been added to our main app and the appclip, the signing for the main app is working fine, but for the appclip we are getting this issue: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file.

我们基于 ActivityKit Push-to-Start 实现远程推送创建 iOS 实时活动，当前遇到异常问题： 预期逻辑 Push-to-Start 推送到来、主 App 不在进程时，系统收到创建推送会后台拉起主 App；我们在 App 被拉起的时机，获取本次实时活动对应的updateToken并上报服务端，服务端拿到 token 后，才能持续推送更新该实时活动。 2. 异常现象（部分iOS27设备偶现） 设备成功收到 Push-to-Start 推送，实时活动正常创建并在锁屏 / 灵动岛展示；但埋点统计证实：系统没有在活动创建的同时后台启动主 App。 3. 带来的后果 因为主 App 未被唤醒，获取updateToken并上报的代码逻辑不会执行；服务端拿不到本次活动实例的更新 token，该实时活动创建成功后，无法接收后续状态更新推送。 我们想知道，为什么部分iOS27设备会偶现系统收到实时活动的创建推送，但是没有启动主APP的情况，我们可以采取什么措施避免这个问题

I have several Live Activities running concurrently for different trips in a delivery app (same app, multiple active Live Activities, each with its own activity ID). I update relevance-score via ActivityKit push notifications at each status change: Trip picked up → 20 route to destination → 40 Arrived at destination → 60 Delivery delayed → 80 Confirmed → 100 (sent with "event": "end") Per Displaying live data with Live Activities, "the relevanceScore also determines the order of your Live Activities on the Lock Screen." However, when the Confirmed Live Activity is sent with "event": "end" and "relevance-score": 100, it does not move to the top of the Lock Screen stack, even though other still-active trips have lower relevance scores (20–80). Questions: Does relevanceScore only apply to ordering among currently active Live Activities, and get ignored (or treated differently) once a Live Activity has ended? Is there a separate/implicit ordering rule for ended Live Activities during their dismissal window (e.g., always sorted below active ones, or sorted by end time instead of relevanceScore)? Is there a recommended pattern for making a Live Activity appear prominently right as it ends — e.g., sending a high relevanceScore via update first, then a separate end shortly after? This isn't documented explicitly in either the "Configure the Live Activity" or "End the Live Activity" sections, so I wanted to confirm the intended behavior rather than rely on trial and error.

Hello Apple Developer Forums, We are unable to authorize the Production App Store Server API Request a Test Notification endpoint. Environment: Production API: Request a Test Notification Library: Apple App Store Server Library for Java 5.2.0 Client: AppStoreServerAPIClient Result: HTTP 401 Unauthorized before a testNotificationToken is returned. We have verified the following: The key is an active In-App Purchase key created in App Store Connect under Users and Access > Integrations > In-App Purchase. The production server uses the matching .p8 private key, Key ID, Issuer ID, and bundle ID. The bundle ID is com.ansio.serviceproof.ios. The server clock is NTP-synchronized. The request uses the official Apple Java Server Library rather than a manually generated JWT. We rotated the production In-App Purchase key once and received the same 401 result. The notification URL is configured for the Production environment, uses HTTPS, and is reachable. Sandbox uses an independent key and notification configuration. We intentionally do not include the private key, JWT, Key ID, or Issuer ID publicly. According to the documentation, HTTP 401 means the JWT is invalid. Since the official library creates the JWT and the active In-App Purchase key configuration has been verified, could Apple clarify: Is any additional App Store Connect role, agreement, team activation, or entitlement required for a Production In-App Purchase key to authorize App Store Server API requests? Is there a known propagation or authorization issue that can cause a newly created active In-App Purchase key to return 401? What non-sensitive diagnostic details can help distinguish a JWT construction issue from a team-level authorization issue? Thank you.

Hello, Feedback Assistant report: FB24876147. I develop a Unity-based iOS app. Some customers in mainland China report losing Internet access after an app update, while most installations continue working. We have received similar reports since at least iOS 16, across several years and multiple app releases. Earlier iOS versions are uncertain, and we cannot confirm that all historical occurrences share the same cause. Updates without networking-code changes can be followed by failures. A later update sometimes restores connectivity, but not consistently. Customer-reported recovery attempts: The app's wireless-data permissions appear enabled in Settings. Switching the app's network permission to another setting and back did not help users who reported trying it. Reset Network Settings also did not help users who reported trying it. Some users reported that deleting and reinstalling the app restored connectivity. At least one user reported that deletion and reinstallation did not help. These are customer reports, not controlled tests on our development devices. We would prefer a recovery that preserves local save data. Captured evidence from one affected installation: App version 1.89, build 1; Unity 2022.3.62f3. Device identifier: iPhone18,1; iOS 26.2.1. App in foreground. Capture time: 2026-09-07 13:04:31–13:04:32 UTC. An unfiltered Network.framework default-path monitor reported: status=unsatisfied reason=wifiDenied interface=Wi-Fi UnityWebRequest and a newly created native ephemeral NSURLSession both failed against our public HTTPS origin and Apple's independent test endpoint: https://www.apple.com/library/test/success.html The native requests failed after approximately 1 ms and 3 ms, with NSURLErrorDomain -1009, underlying kCFErrorDomainCFNetwork -1009, and no HTTP response. The native session allowed cellular, expensive and constrained network access, used normal TLS verification, and had waitsForConnectivity=false. It bypassed Unity's reachability precheck. CTCellularData changed from unknown to notRestricted. We understand this does not establish successful cellular connectivity or Wi-Fi permission. Important limitations: The native probes ran inside the same Unity-built process, not a separate standalone native app. The captured measurements demonstrate a Wi-Fi failure. Cellular failures and enabled Settings permissions are customer reports, not independently verified by these measurements. We cannot reliably reproduce the affected state on our development devices and do not have a focused Xcode project that reproduces it. An affected-device sysdiagnose is not yet available. Unity Customer QA reviewed this evidence, assessed it as an iOS network-policy issue rather than a Unity bug, and referred us to Apple. We are seeking Apple's investigation, not presenting that assessment as a confirmed root cause. The Code-Level Support form directed us to these forums because we cannot currently provide a focused reproducer. Questions: Which affected-device diagnostics or logging profiles would help identify why the effective network policy reports wifiDenied? How should we investigate an installation-specific issue when a new minimal app may not reproduce that installation state? Is there a supported, data-preserving recovery or application-side mitigation when permission changes and network resets do not help, and reinstallation is not consistently effective? We have diagnostic screenshots and relevant probe source available. Any customer system logs would be collected with consent and shared privately with Apple, not posted publicly. Thank you.

We have a macOS USBDriverKit DEXT for our own USB hardware and are currently blocked from production distribution while waiting for the required DriverKit managed capabilities. Team ID: 2H6U9GHYLR Correct request: Request ID: U577A4MPBB Submitted: July 10, 2026 Vendor ID: 0x39D3 (this is our official USB VID) Product IDs: 0x0011, 0x0012, 0x0101 Capabilities: DriverKit USB Transport - VendorID and DriverKit UserClient Access The request has now been pending for 10 weeks and 3 days. There is an unusual complication: we originally submitted request GTL6N6D8K9 on June 24, this request should have been disregarded, but Apple has approved it anyways, 10 weeks after submission. The corrected request (U577A4MPBB) is still not approved. Our implementation is complete and works in development. The production entitlement is now the only blocker preventing us from signing and distributing the driver. Is there any way to have someone check whether U577A4MPBB is correctly in the DriverKit entitlement review queue, or whether additional information is required from us? We can provide documentation confirming ownership of USB VID 0x39D3 if needed. Thank you Simon

I'm developing an iPad app where I want to annotate things on a pdf. I subclassed PDFAnnotation to drag text on a pdf. When I use Xcode 26 everything is working fine and everything is rendered perfect. But when I run the same code with Xcode 27 on iOS27 I get a pixelated annotation. iOS26 iOS27 The code: import UIKit final class ManualPlacementPreviewAnnotation: PDFAnnotation, DraggablePreviewAnnotation { private let text: String private let textFont: UIFont private let textColor: UIColor var isGrabbed = false init(bounds: CGRect, text: String, font: UIFont, color: UIColor) { self.text = text self.textFont = font self.textColor = color super.init( bounds: bounds.insetBy(dx: -PreviewAnnotationChrome.padding, dy: -PreviewAnnotationChrome.padding), forType: .freeText, withProperties: nil ) } required init?(coder: NSCoder) { text = "" textFont = .systemFont(ofSize: 12) textColor = .black super.init(coder: coder) } override func draw(with box: PDFDisplayBox, in context: CGContext) { context.saveGState() context.translateBy(x: 0, y: bounds.minY + bounds.maxY) context.scaleBy(x: 1, y: -1) let content = contentBounds UIGraphicsPushContext(context) NSAttributedString(string: text, attributes: [ .font: textFont, .foregroundColor: textColor, ]).draw(in: content) UIGraphicsPopContext() PreviewAnnotationChrome.draw(context, around: content, grabbed: isGrabbed) context.restoreGState() } } Is this a bug in iOS27 or am I doing something wrong?

I am designing a cross-platform application whose core application is a web/PWA application. I want to distribute a very small native wrapper through the Apple App Store. The customer would purchase the application once through the App Store. There would be no subscription, no developer-managed customer account, no developer password, and no cloud storage of the customer's data. The customer's songs remain entirely on their device. The native Apple wrapper would use StoreKit to determine whether the customer owns the application. If they do, the web application should operate in unlimited mode. If they don't, the web application should operate in a free mode limited to 10 songs. Can an App Store-distributed native wrapper securely communicate the verified StoreKit entitlement to the embedded web/PWA application, without requiring my own customer account or licensing server? If yes, what Apple-supported mechanism should be used to pass that entitlement from the native application to the web application? Additionally, does Apple's App Store license for a non-consumable purchase automatically allow the purchaser to use the application on multiple Apple devices associated with the purchaser's Apple Account?

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.

I'm building an accessibility feature where a user walks around and taps NFC tags to trigger updates in the app (e.g., wayfinding/context info). I want a "Live Mode" toggle that keeps the app listening for NFC reads continuously while it's on, processing each tag as it's scanned, rather than one-shot read-and-dismiss. Is there a Core NFC API or session configuration that supports this kind of continuous/persistent listening, or does every read still require invalidating and restarting the session afterward? Currently: I have high-performant reads working reliably with passive NDEF/tag detection. What I'm trying to figure out: Recommended approach — should I keep a single long-lived NFCReaderSession alive and handle repeated reads within it, or restart a new session immediately after each read? VoiceOver / accessibility — how does the system NFC sheet interact with VoiceOver, especially if the session is restarting frequently while the user is mid-walk? Session timeout and restart handling — what's the best way to detect and recover from a session timing out or invalidating unexpectedly, without the user noticing a gap in "Live Mode"? Battery/radio use — are there known concerns with keeping NFC polling active over an extended period (minutes, not seconds)? Thank you.

Hi there, I am working on bluetooth functionality of iOS and I have a feature that display all bluetooth paired devices on list view. Is there a way to get the list of paired device using swift programming. Many Thanks!

I'm testing Bluetooth Channel Sounding interoperability between an Apple device and a BLE peripheral. During Channel Sounding configuration, the peripheral sends an LL_CS_CONFIG_REQ, but the request is rejected by the central device with: LL_REJECT_EXT_IND Rejected Opcode: LL_CS_CONFIG_REQ Error Code: Unsupported Feature Or Parameter Value I would like to understand which parameter in the Channel Sounding configuration may be incompatible with the Apple device. Could the expert clarify which Channel Sounding configuration parameter would cause the Apple device to reject this LL_CS_CONFIG_REQ? if sniffer log is needed, I can send it via e-mail.

Hello Apple Developer Support, We have submitted a DriverKit entitlement request for our iPadOS photo booth application, which uses a USB DriverKit extension to communicate with professional dye-sublimation photo printers over USB-C. Our request covers one USB Transport configuration with the following Vendor IDs: 0x1343 (4931) — DNP / Citizen 0x1452 (5202) — DNP 0x0D16 (3350) — HiTi The DriverKit extension is used exclusively by our own iPadOS application, and we do not require UserClient Access. Our entitlement request is currently pending. We would appreciate any guidance from the DriverKit team regarding the review of our request. Request ID: 2DN73H7DCY Thank you.

I have 27.2 developer beta running on my iPhone Air and Watch Ultra 4. My wife has an 18 Pro and also Ultra 4 but hers are both running the current public release versions of iOS 27 and watchOS 27. After 2 nights with the Ultra 4's, her sleep score is reporting accurate. Mine is way off. For example, last night we went to bed around 10 PM and woke up at 7 AM. Her scores were in the 90's with 7:36 hours of sleep. Mine is in the 40's with 4:20 hours of sleep. We both slept the same/great last night. Similar results for the night before - hers is accurate; mine are way off.

I've written an PDF viewing app, and there seems to be a correlation between files opened by the app and files that Time Machine says couldn't be backed up. The files can still "not be backed up", even after the app has closed them. Is there anything I specifically need to do to sever the link between the file and the app?

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (thread 774053), Feedback ID: FB24877994. Apple Developer Support case 102971044266 is open in parallel. Summary On our account no auto-renewable subscription renewal has ever succeeded, on either of our two products, while every customer-present initial purchase succeeds. In the last 48 hours 4 of 4 free trials that reached their renewal date with auto-renew ON failed with expirationIntent 2, in four countries (PK, GB, NL, US). What we observe Yearly product with a 7-day free introductory offer (all 175 territories, offerMode FREE_TRIAL, ONE_WEEK, 1 period). Monthly product with no offer. For each of the four, GET /inApps/v1/subscriptions/{originalTransactionId} returns status 3, and the renewal info has autoRenewStatus 1, expirationIntent 2, isInBillingRetryPeriod true, the correct renewalPrice and currency, no priceIncreaseStatus. Environment Production, inAppOwnershipType PURCHASED. The DID_FAIL_TO_RENEW notification (no subtype; billing grace period not enabled) arrives at the expiry time in each case. App Store Connect subscription events from 2026-08-01 to 2026-09-20: 18 free trial starts, 6 full-price starts, 4 voluntary churns from free trial, 4 from full price, 3 "Billing retry from free trial", 1 "Involuntary churn from full price", and no renewal event of any kind. So 5 of 5 unattended renewal charges ever attempted have failed, across two products and five countries, while the 6 paid monthly purchases in the same window (TR, FR, AU, MN, US) were charged normally at purchase time. The customers are in their own storefront countries (device time zones match), and none of the four cancelled. What we have verified Both products Approved, 175 price rows each, no scheduled or preserved prices; Paid Applications Agreement, Free Apps Agreement, banking, tax forms and both compliance items (DSA, MRDP) all show Active with nothing pending in App Store Connect > Business; our servers call no App Store Server API endpoint that modifies a subscription. Thread 847338 (posted today) describes every renewal on an account failing after an agreement issue, with expirationIntent 5. Ours is expirationIntent 2 and our agreements show Active, but the shape is the same: every renewal, no purchase affected. Questions for Apple engineers Is there any account, agreement or product condition that causes renewal charges to fail with expirationIntent 2 while initial purchases succeed? Is anything more than expirationIntent 2 available about these four renewals? The four original transaction IDs are in FB24877994. Is there a known issue affecting free-trial-to-paid renewals around 19 to 21 September 2026? Thank you.