I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: 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. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note 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. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

I am developing a consumer iOS app for App Store distribution and would like to confirm the appropriate public API for the following use case. The app needs to measure the amount of network traffic passing through the device over short time intervals, for example once per second or more frequently. The app does not need to inspect packet contents, block or filter traffic, or provide a remote VPN service. It also should not generate dedicated network traffic solely for speed measurement. The goal is only to observe device-wide network traffic volume and convert that information into a simple real-time indicator for the user. I am currently investigating the Network Extension framework. Would NEPacketTunnelProvider be an appropriate API for this use case? If not, is there another supported Network Extension provider or other public iOS API intended for measuring device-wide network traffic in this manner? I would like to choose an architecture that is technically supported by Apple and appropriate for a consumer app distributed through the App Store before beginning implementation.

I have just lost all records of all record types in a cloud kit database. All schema for all record types are still present. There are no mentions of record deletion or zone deletion in the console. The logging for the App has no mention of any deletion operations... Any idea how this could happen?

In macOS Tahoe 26.7 or Sequoia 15.7.5 (and probably other prior versions), when you install a .pkg, symlinks are followed: i.e. if your payload install a file to /Users/Shared/my-folder and, on the target volume, the /Users/Shared/my-folder item is a symbolic link to /Users/Shared/actual-folder, the file will be installed inside /Users/Shared/actual-folder. It used to be possible to tell the installation framework/mechanism not to follow symbolic links by using the followSymLinks attribute in the raw package PackageInfo file. And in this case, the symbolic link would be replaced by a real directory and the file would be installed where it was supposed to be installed. This attribute is apparently not taken into account anymore by the framework/mechanism. [Q] Is this on purpose or is it a bug (in shove for instance)? If it is on purpose, why was it considered a good idea to always follow symbolic links considering the security issues this can create?

On both iOS & macOS 27.2 Beta 2 the call: let token = try await MusicDataRequest.tokenProvider.developerToken(options: [.ignoreCache]) is throwing an error. I can reproduce this on all of my 27.2 Beta 2 devices and I have users worldwide reaching out to me with this issue. The error that gets thrown is: Unknown error "Error returned from daemon: Error Domain=com.apple.accounts Code=9 "(null)"" Have raised FB24895830.

Hello Apple Developer Forums, We are developing an iOS companion app that supports multiple Bluetooth earbud products, and we are evaluating AccessorySetupKit for one specific product family. Our current product situation is: EU: Earbud A → AccessorySetupKit Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Non-EU: Earbud A → legacy CoreBluetooth discovery Earbud B → legacy CoreBluetooth discovery Earbud C → legacy CoreBluetooth discovery Earbud D → legacy CoreBluetooth discovery Earbud E → legacy CoreBluetooth discovery Only Earbud A needs to adopt AccessorySetupKit. The other four products are existing products and need to keep their current CoreBluetooth discovery and authentication flow. According to Apple's AccessorySetupKit documentation, an app using AccessorySetupKit needs to declare: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> Apple's documentation also describes AccessorySetupKit as the mechanism for discovering and configuring Bluetooth accessories: https://developer.apple.com/documentation/accessorysetupkit/discovering-and-configuring-accessories Our concern is the interaction between this declaration and the existing CoreBluetooth discovery flow. For the AccessorySetupKit-managed product, the intended flow is: ASAccessorySession ↓ Accessory Picker ↓ User authorization ↓ CoreBluetooth communication For the other existing products, we need to retain: CBCentralManager ↓ scanForPeripherals() ↓ Discover nearby peripheral ↓ User selects device ↓ Existing authentication / binding flow We understand from Apple's WWDC24 AccessorySetupKit session that once AccessorySetupKit is involved, CoreBluetooth scanning is subject to the AccessorySetupKit authorization model. This raises an important compatibility question for us. If the application declares: <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> but only one product family is intended to use AccessorySetupKit, can the same application continue to perform unrestricted CoreBluetooth discovery for the other four legacy Bluetooth products? For example: Nearby: Earbud A → ASK-managed Earbud B → legacy Earbud C → legacy Expected: ASK Picker → Earbud A CBCentralManager.scanForPeripherals() → Earbud B → Earbud C Or does declaring NSAccessorySetupKitSupports = Bluetooth cause CoreBluetooth discovery to be restricted to accessories that have already been authorized through AccessorySetupKit? We are particularly concerned about first-time discovery of a legacy accessory: User upgrades the app ↓ Earbud B has never been authorized through AccessorySetupKit ↓ Earbud B is nearby ↓ The app needs to discover Earbud B for the first time ↓ Existing CBCentralManager discovery flow If CoreBluetooth discovery is restricted after AccessorySetupKit is enabled, we don't see how the app can discover this new legacy accessory in order to continue using the existing flow. We are aware of ASMigrationDisplayItem and the AccessorySetupKit migration mechanism for existing Bluetooth accessories. However, migration appears to require an already-known peripheral identifier, so we are unsure how this applies to a new legacy accessory that has never been discovered or authorized through AccessorySetupKit. Questions Is it officially supported for one application to use AccessorySetupKit for only one Bluetooth product family while continuing unrestricted CoreBluetooth discovery for other Bluetooth product families? If yes, what is the recommended architecture/API configuration? Does NSAccessorySetupKitSupports = Bluetooth affect CoreBluetooth discovery globally for the application, or can its effect be limited to specific accessory families through ASDiscoveryDescriptor? How should an application discover a new, previously unauthorized legacy Bluetooth accessory after AccessorySetupKit has been enabled? Is there an Apple-recommended migration strategy for an application that has multiple existing Bluetooth product families, where only one product family is required to adopt AccessorySetupKit? Any clarification from Apple on the officially supported architecture would be greatly appreciated. Thank you.

Hi, We received a notice that our Pass Type ID certificate will expire soon, and we plan to renew it for the same Pass Type ID (we will not create a new identifier, and we will not revoke the old certificate until the new one is in place). Our app adds payment cards to Apple Wallet via in-app provisioning (PKAddPaymentPassViewController / com.apple.developer.payment-pass-provisioning). We do not sign or distribute .pkpass files with this certificate. The app entitlement com.apple.developer.pass-type-identifiers includes our existing Pass Type ID. Developer Support pointed us to the standard certificate overview: if the certificate expires, installed passes keep working, but we can no longer sign new passes or send updates. That sounds like generic Wallet passes, not payment-card provisioning. Could someone from Apple confirm: If we renew the Pass Type ID certificate for the same identifier, will Add to Wallet for payment cards still work for current users (no need to remove and re-add the card)? After renewal, can users add new payment cards as usual? Is the Pass Type ID certificate required for in-app provisioning, or do we only need the Pass Type ID identifier in entitlements? Thanks.

We make a BLE peripheral that streams continuously. It's been running against Android, Windows, macOS and iOS for years. Android and Windows sit at ~1000 kbps and stay there — many host devices, many OS versions, no per-host tuning. macOS and iOS give us about half that. We've sniffed the BLE link using a Bluetooth sniffer to find out where it goes. Same board, same firmware, every session. Read off the air trace, not from host APIs: 2M PHY both directions (LL_PHY_UPDATE_IND 0x02 / 0x02) DLE max_tx_octets = 251 ATT MTU 247 15.00 ms interval, peripheral latency 0 no encryption no other BLE or BT Classic connections active during the session (all other devices removed and forgotten) WiFi turned off for around half of the sessions, didn't seem to make any difference Peripheral airtime per connection event: central airtime/event duty @ 15 ms throughput Android 11.14 ms 74% 995 kbps, sustained Windows ≥10.70 ms ≥71% ~1000 kbps, sustained macOS 6.96 ms 46% 561 kbps iOS 6.96 ms typical 46% ~560–600 kbps macOS comes out median 6.96, p90 6.96, max 7.09 across a whole session. Same number every time. iOS normally sits in the same place, with occasional brief excursions up to Android-like performance before dropping back down. Those excursions are worth describing, because they're the interesting part. In a handful of sessions out of many, iOS runs at 12.53 ms, 84% duty, ~1030 kbps. It never holds. It drops back inside 150 ms, with no renegotiation, no parameter change and no channel-map change anywhere in the trace. Sometimes it parks at 8.35 ms for ten seconds before moving again. This isn't us saying iOS is fine in practice — it clearly isn't, we can't ship against it. The point is that the radio and the stack demonstrably can fill a 12.53 ms event when they're allowed to, so whatever is holding them to 6.96 ms isn't a hardware ceiling. "It's a factor of ability" doesn't fit. This has been asked before and answered. In thread 774487, asked directly whether iOS limits packets per connection event to 4: "there is no 'limiting' going on as it is commonly understood ... We find that 4 is a more commonly true number than 6 or more some chipsets claim." In thread 770717, to a developer on iOS 18.2 running the same parameters we are: "iOS does not 'limit' the number of writes. It is just a factor of ability." Both answers need the accessory to be the variable. Ours isn't — same board, same firmware, minutes apart, and two non-Apple hosts take it to 1000 kbps and hold it indefinitely. The only thing that changes is which OS is acting as central. We don't think this can be explained by chipset capability when the chipset is the one thing held constant. It's airtime, not packet count. The "4 packets per connection event" number people quote here is the wrong unit, and we think that's why these threads go nowhere. Within one regime, as PDUs per event go up, PDU size goes down and the airtime doesn't move: iOS 9 PDUs @ 250.4 B -> 12.51 ms 10 PDUs @ 211.1 B -> 12.32 ms 11 PDUs @ 186.4 B -> 12.47 ms macOS 5 PDUs @ 239.4 B -> 6.73 ms 6 PDUs @ 178.1 B -> 6.60 ms Nothing is counting packets. The event closes on a clock. Count and airtime were the same measurement back when everything was 1M PHY and 27-byte PDUs — with 2M and DLE they aren't, and quoting a packet count now hides the mechanism instead of describing it. The peripheral isn't the limiter. The MD bit was set on the peripheral's last PDU in 2147 of 2148 connection events. It always had more data queued, and the central closed the event anyway. This isn't a new report. The same mechanism has been described here before. Thread 133092 (2019) reports macOS closing the connection event while the peripheral still has MD set — exactly what we measure. Thread 713349 reports "about 5 response packets per connection event," which is the same budget: 6.96 ms is 5 full-size PDUs. Thread 6025 reports a drop from 7 packets to 3. None of those received a reply. We're not raising them to relitigate old threads. The point is that three independent reports arriving at the same number across several years, on different accessories, points at a property of the scheduler rather than of anyone's hardware. On iOS, this looks like it changed in iOS 18. macOS has apparently behaved this way for years, going by the threads above. On iOS it's recent. We have video and screen recordings of this same peripheral tested on iOS 17, documented at the time as running consistently at around 1000 kbps. The behaviour described here started appearing when we moved to iOS 18. The firmware and the negotiated parameters are the same now as they were then, which points at a change in radio scheduling rather than anything on our side. What we're asking: Is the per-event airtime budget deliberate? ADG §55.6 and QA1931 cover interval, latency and timeout only. Neither mentions connection event length. Why do macOS and iOS give roughly half what Android and Windows give for the same accessory, and why can iOS reach 12.53 ms without staying there? Did anything change in iOS 18 around connection event scheduling? Is there anything we can do from the accessory or app side? We're already at 2M PHY, DLE 251, MTU 247 and the 15 ms floor. If the answer is "design for a floor, not a peak" — what's the floor? Right now we plan for ~560 kbps on Apple and roughly double that everywhere else, and that decides what we can ship, and whether we can count on Apple devices as a reliable platform for our product. Captures, recordings and analysis available if they're useful.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

We occasionally observe es_mute_process_events() called on an es_client_t while an AUTH event delivered by the same client is still outstanding. In the problematic state, es_mute_process_events() stops returning inside IOConnectCallStructMethod. Subsequent calls to es_respond_flags_result() and a fallback es_respond_auth_result() on the same es_client_t also block in IOConnectCallStructMethod, eventually causing the AUTH deadline to be missed. We would like to clarify the concurrency semantics of these APIs: Is it supported to call es_mute_process_events() before responding to an outstanding AUTH event delivered by the same es_client_t? Can es_mute_process_events() wait for in-flight/outstanding AUTH processing? Are mute operations and es_respond_*() calls serialized internally for a single es_client_t? Can an in-progress mute operation prevent a concurrent es_respond_*() call from completing? Is the recommended pattern to respond to the AUTH message first and update mute state asynchronously afterward?

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

hi folks, im working on an application for downlink time of difference arrival. im using a DWM 3000 ultrawide band board to send DLTDoA pulses. i have followed the protocol in the FiRA 2.0 spec, and properly implemented the swift api, but im getting issues with the iPhones UWB radio chip(rose). i have no issues if i use another board as a receiver instead of my phone. specifically, im using the SP1 frame format, and am getting errors at the PHR stage. to my knowledge, the 0x18 SECDED error means that the PHR header could not be properly decoded. does anyone have advice on how to debug or next steps? its difficult since i cant get access to lower level logs of the chip to actually see whats going wrong. thanks.

Hi, We're implementing a HCE contactless app on iOS. The intention of this app is to only support contactless payments. Next to the com.apple.developer.nfc.hce and com.apple.developer.nfc.hce.default-contactless-app entitlements, we've listed the identifiers that we're interested in through the com.apple.developer.nfc.hce.iso7816.select-identifier-prefixes in the Info.plist. (325041592E5359532E4444463031 & A0000000041010 f.e.) When the app is configured as the Default Contactless App, we start receiving NFCWindowSceneEvents through our NFCWindowSceneDelegate. However we notice that also non-payment related NFC events are being received, such as when the device is close to a NFC reader for Access cards for example. This experience results in launches of our app when it's not intended. Is there a way to allow the app to only receive NFC events related to ISO 7816 identifiers when the when the app is configured as the Default Contactless App? Thanks in advance for any guidance! Kind regards, Dimitri

We are an interdisciplinary research team involving Gazipaşa Science High School and Akdeniz University in Türkiye, including student researchers, a project advisor, and a medical researcher. We are conducting a non-commercial scientific research project within the TÜBİTAK 2204-A High School Students Research Projects Competition. As part of the project, we are developing an experimental wrist-based optical monitoring system. We plan to use an Apple Watch Series 9 (A2980, Part Number MR9A3TU/A) as a comparative benchmark during the development and evaluation of our system. In particular, we are interested in accessing Apple Watch photoplethysmography (PPG) data through SensorKit. We intend to use these data to support the iterative development of our optical monitoring system and to evaluate and report how modifications to our system affect its signal characteristics and performance relative to an established commercial wearable optical sensing platform. Apple Watch measurements will be used for comparative research and system evaluation, rather than as a clinical reference or diagnostic measurement. We would therefore appreciate guidance on the appropriate procedure for obtaining SensorKit access and the required entitlement for Apple Watch PPG data for this type of scientific research. To perform a scientifically meaningful comparison, we also need reliable technical information about the optical sensing system of the Apple Watch used in our study. However, we have been unable to find an authoritative and citable Apple source specifying the wavelengths or wavelength ranges of the optical emitters used in the Apple Watch Series 9 (A2980). Could you please direct us to any official Apple documentation, publication, technical specification, or other authoritative resource containing this information? If the exact specifications are not publicly available, we would appreciate guidance on whether such information can be provided for academic research purposes. We would also appreciate recommendations for the appropriate Apple technical support channel, Developer Forum, research contact, or other point of contact for further questions that may arise during the development and research process. Thank you for your time and guidance.

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.

There have been 2 serious regressions in the hypervisor framework since developer beta 6 of macOS 27 that have continued into the final release, and the first beta of 27.2 The first is that since developer beta 6 of macOS 27, virtual machines that have an Apple ID with iCloud+ signed in fail to route traffic in Safari through iCloud Private Relay despite it being on. Parallels, UTM, VirtualBuddy have all been tested and the issue applies to all of them, exposing the host machine's IP address. I have reported the issue since I discovered it and there hasn't been any communication that Apple even knows its an issue to my open report in Feedback Assistant. The second issue is a newer one, and it affects macOS 26.6.2 and earlier virtual machines. Attempting to install 26.7 through the built-in software update causes the virtual machine to black screen upon reboot during the installation. Forcing the machine off and back on causes the virtual machine to revert back to macOS 26.6.2. There has been no available IPSW file to test if a clean install of 26.7 in a virtual machine is a viable workaround, or to see if there is a bug in the updating mechanism or bug in the 26.7 release itself in virtual machines. The Parallels Desktop forum is beginning to get reports from users of that software of the same black screen issue trying to update their own 26.6.2 VMs to 26.7. These issues have also not been corrected in either 27.2 Beta 1 nor 26.7.1 Has anyone found a workaround to either of these 2 issues, or submitted similar reports and got any kind of response from Apple? The feedback reports about these issues are FB24828992 and FB24791716

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.