I provide a paid feature behind an annual auto-renewable subscription, using StoreKit 2 and Transaction.currentEntitlements. Many of my users work in remote places with no connectivity for days at a time, so I need to know what happens when a device is offline at the moment the current period ends. The renewal succeeds server-side, but the device cannot fetch the updated signed transaction, so the cached transaction still carries the previous expirationDate, now in the past. Does Transaction.currentEntitlements stop returning the subscription once the cached transaction's expiration date has passed, even though the renewal has already succeeded server-side? Is there any built-in tolerance window on the device that keeps the entitlement alive until the next successful sync with the App Store? Does grace period effect the outcome? I want to avoid revoking access from a paying subscriber who happens to be offline when renewal falls due. Many thanks.

Hi everyone, I am trying to wake up/relaunch an app that was force-quit by the user via a BLE advertisement packet. According to TN3115 ("App Force Quit by the user" section), an app generally cannot be woken up after a user force-quit. However, Note 5 states that starting in iOS 26, an app authorized via AccessorySetupKit can indeed be relaunched. Environment iOS Version: iOS 26.5 (Note: revised to standard versioning) Xcode Version: Xcode 26.3 Implementation Details 1. Info.plist Configuration <key>NSBluetoothAlwaysUsageDescription</key> <string>We need Bluetooth to discover and connect to your accessory.</string> <key>UIBackgroundModes</key> <array> <string>bluetooth-central</string> </array> <key>NSAccessorySetupKitSupports</key> <array> <string>Bluetooth</string> </array> <key>NSAccessorySetupBluetoothServices</key> <array> <string>0000XXXX-0000-1000-8000-00805F9B34FB</string> </array> <key>NSAccessorySetupBluetoothNames</key> <array> <string>MyDeviceName</string> </array> 2. Workflow & Code Steps Initialize ASAccessorySession and call activate(). Pair/authorize the BLE peripheral using ASPickerDisplayItem. Initialize CBCentralManager with state restoration: let options: [String: Any] = [ CBCentralManagerOptionRestoreIdentifierKey: restoreIdentifier, CBCentralManagerOptionShowPowerAlertKey: true ] centralManager = CBCentralManager(delegate: self, queue: nil, options: options) Start scanning: let scanOptions = [CBCentralManagerScanOptionAllowDuplicatesKey: true] centralManager?.scanForPeripherals(withServices: serviceUUIDs, options: scanOptions) Handle state restoration: func centralManager(_ central: CBCentralManager, willRestoreState dict: [String : Any]) { if let services = dict[CBCentralManagerRestoredStateScanServicesKey] as? [CBUUID], let options = dict[CBCentralManagerRestoredStateScanOptionsKey] as? [String : Any] { central.scanForPeripherals(withServices: services, options: options) } } Receive discovery callback: func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) { if peripheral.name == "MyDeviceName" { // Send a local notification } } Current Behavior Foreground: Local notification triggers as expected. Background: Local notification triggers as expected. Force Quit by User: No notification is received / App is not relaunched. Issue The app fails to relaunch when force-quit by the user, which seems to contradict the behavior described in TN3115 Note 5. Is there a specific configuration, entitlement, or additional CBCentralManager setup required to allow BLE advertisements to relaunch the app after a user force-quit via AccessorySetupKit? Any guidance would be greatly appreciated!

Beginning July 29, 2026, we observe communication erros while sending push notifications to https://api.push.apple.com like: Error in the HTTP2 framing layer Send failure: Connection reset by peer Also we ran tcpdump which clearly indicates that TCP RESET packets are coming from various APNS IP like 17.188.x.x. Errors mostly occure during traffic peak but also outside. We also did a test from different datacenter in other country and which resulted a same issue

General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post URL filter: WWDC 2025 Session 234 Filter and tunnel network traffic with NetworkExtension URL filters documentation Filtering traffic by URL sample code Setting up a PIR server for URL filtering sample code Using the Bloom filter tool to configure a URL filter sample code PIR Service Example open source server sample and specifically its documentation Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Saving a CKShare together with its root record in a custom zone in the user's private database fails on every attempt. The client sees CKError .serverRejectedRequest / .invalidArguments. The CloudKit Console server log shows the failure is on the system record type _pcs_data, not on our own record type: { "database":"PRIVATE", "zone":"SharedStatusZone", "operationType":"RecordSave", "platform":"iPhone", "clientOS":"iOS;26.5.x", "overallStatus":"USER_ERROR", "error":"BAD_REQUEST", "requestId":"FDB0D10E-0B82-4C71-9262-90D9A2EA3787", "returnedRecordTypes":"_pcs_data" } In the same session, ZoneSave and RecordFetch SUCCEED. Only the RecordSave that carries the CKShare fails. Container: iCloud.com.nyeong.yakmeokping (Production) Device: iPhone, iOS 26.5.x What we do (simplified) let zone = CKRecordZone(zoneID: ownerZoneID) _ = try await db.modifyRecordZones(saving: [zone], deleting: []) // succeeds let record = CKRecord(recordType: "MedStatus", recordID: ownerRecordID) // plain String / Int64 / Date fields only let share = CKShare(rootRecord: record) share[CKShare.SystemFieldKey.title] = "..." as CKRecordValue share.publicPermission = .none _ = try await db.modifyRecords(saving: [record, share], deleting: [], savePolicy: .allKeys, atomically: true) // FAILS User-visible symptom: UICloudSharingController shows "Cannot add people / Unable to create a link for sharing", and a Messages collaboration attachment spins forever, because no share URL is ever minted. Already ruled out iCloud sign-in - accountStatus() == .available immediately before the call. iCloud Keychain - enabled on both the iPhone and a Mac on the same account. Advanced Data Protection - OFF. Leftover/broken share - also fails when no record exists yet (brand new). UICloudSharingController - reproduced with a code path that never presents the controller and only performs the CloudKit save. Schema - the record type and every field we write are deployed to Production. Entitlements - com.apple.developer.icloud-services: (CloudKit), icloud-container-environment: Production, CKSharingSupported = true in Info.plist. Zone is a custom zone, not the default zone. Record and share are saved together, atomically, as documented. Possibly related Two recent threads report CKErrorServerRejectedRequest limited to the PRIVATE database in Production, starting around July 25: "iCloud Dashboard returns Internal Error when querying records across all containers" - the author reported on July 30 that the service had been down for a few days and had since recovered. "CloudKit CKQueryOperation returns CKErrorServerRejectedRequest" (FB24046201) - failures since July 25, error code 15, CKInternalErrorDomain Code=2000, HTTP 500. Those are read operations rather than a CKShare save, so they may be unrelated. Our failure still reproduces on July 31, after the other report says the incident was resolved. Note that developer System Status showed green throughout. Questions What does a BAD_REQUEST on _pcs_data during a CKShare save indicate? It appears to be the encryption key material for sharing rather than our own record. Is there an account-level or container-level condition that can block PCS key provisioning? Has anyone else seen CKShare creation (not query) failing in the same period? Any pointer would be appreciated - the client-side CKError carries no server error description, so the console log above is all we can see.

Hello, We operate an app that grants users credits after a successful in-app purchase. Our current purchase-processing flow is as follows: A user completes an in-app purchase. Our app or server receives the purchase-related information. Our server sends a transaction verification request to the App Store Server API. After verifying the transaction, our service marks the purchase as completed and grants credits to the user. However, we are intermittently experiencing connection timeouts and unidentified server errors when retrieving transaction information through the App Store Server API. One example of the timeout error is: HTTPSConnectionPool( host='api.storekit.itunes.apple.com', port=443 ): Max retries exceeded with url: /inApps/v1/transactions/330003085668123 Caused by ConnectTimeoutError: Connection to api.storekit.itunes.apple.com timed out. (connect timeout=3) We also intermittently receive the following error response: { "code": 5000001, "message": "An unknown error occurred. Please try again." } When this issue occurs, the payment may have been successfully completed through the App Store, but our server is unable to immediately verify the transaction. As a result, the user may not receive the purchased credits in our app. We would appreciate your guidance on the following questions: What are the common causes of connection timeouts or error code 5000001 when calling /inApps/v1/transactions/{transactionId}? What retry strategy does Apple recommend when these errors occur? Please advise whether there are recommended timeout values, retry limits, or exponential backoff parameters. Is there another reliable method to confirm a completed purchase when the transaction lookup API does not return a response immediately? Does Apple recommend using App Store Server Notifications V2 to process completed purchases asynchronously rather than relying solely on an immediate transaction or receipt verification response? For an app that grants consumable digital credits, which value should be used as the primary identifier for purchase completion and duplicate-grant prevention: transactionId, originalTransactionId, or the information contained in signedTransactionInfo? When a temporary API error occurs, is it recommended to store the purchase as pending and perform transaction verification again from our server until a definitive result is received? We would appreciate Apple’s recommended implementation approach for reliable transaction verification and recovery, particularly to prevent cases in which a payment is successfully completed but the purchased credits are not granted due to a temporary API communication error. Thank you.

Configuring a VPN with includeAllNetworks causes CarPlay / Netflix Cast. Even enabling excludeLocalNetworks does not resolve this issue. Is this a known issue and can we work around this?

Our app uses a Distribution.xml-based installer. Within the postinstall script, we attempt to untar a signed and notarized .app to the /Applications directory. On macOS 27 (tested up to Developer Beta 4), the tar command randomly fails to write random unpacked files with an I/O error; in the console there is "spolicyd[721] revoked access to "/Applications/XXX.app/file/within". It can be reproduced approximately every 4th install. Is this happening for anyone else? Any known workaround?

Subject: Clarification Request – Private Relay and Silent Network Verification (SNV) Hello, Context: our app uses Silent Network Verification (SNV), the standard carrier method where the network recognizes a subscriber's connection to verify their identity without needing an SMS code. When a user has iCloud Private Relay enabled, the request path changes in a way that breaks this recognition, and the user falls back to OTP instead. We're evaluating an approach where the app would handle DNS resolution itself for this specific verification request, so the request stays on a path our network can recognize — without the user having to turn Private Relay off. Before we go further with this, we'd like clarity on two things: Would this kind of app-level DNS handling, used only for this verification step, be acceptable under the App Store Review Guidelines — or would it likely be treated as working around a user's privacy setting (for example under 2.5.1, 2.5.9, or 5.1.1)? If we added an explicit, transparent consent step in the app — telling the user we're bypassing Private Relay for this one request so they can be verified without an SMS code — would that change how this is viewed? We'd rather get this in writing from Apple than build against an assumption, and we'll need to share your response with our internal IT and compliance team, so a written reply would be genuinely helpful. Happy to provide more technical detail if useful. Thank you,

Our macOS app makes an URLRequest (via URLSession) to an HTTP(S) server on the local network (a device at a private IP address, e.g. 192.168.x.x). The request fails with NSURLErrorNotConnectedToInternet (-1009) whose underlying error resolves to ENETDOWN (POSIX errno 50) at the socket/connection level — i.e. the failure happens before any TLS/HTTP exchange, at connect() time. This only reproduces on macOS 27 "Golden Gate" Public Beta. The exact same build/binary works correctly on: macOS 26 "Tahoe" (shipping release) macOS 27 "Golden Gate" Developer Beta Based on our diagnosis, we believe the Local Network permission prompt itself is never firing for direct-IP (non-Bonjour) connections on this Public Beta build, leaving the app's Local Network TCC grant permanently stuck in an "undetermined" state — which then surfaces as ENETDOWN. This is consistent with the app not appearing at all in System Settings → Privacy & Security → Local Network, and with tccutil reset LocalNetwork failing both per-app and system-wide (there's no grant to reset in the first place). We'd like a sanity check / to know if others are seeing this, and whether there's a known workaround. Environment App: com.example.Client, non-sandboxed Target: https://:/api/... macOS versions tested: macOS 26 Tahoe — OK; macOS 27 Golden Gate Developer Beta — OK; macOS 27 Golden Gate Public Beta (build: 26A5388g) — fails Mac model: Mac mini Xcode version used to build: 27 beta 2 Error details URLSession completion error: Error Domain=NSURLErrorDomain Code=-1009 "..." UserInfo={ _kCFStreamErrorCodeKey=50, NSUnderlyingError=0x... { Error Domain=kCFErrorDomainCFNetwork Code=-1009 UserInfo={ _NSURLErrorNWPathKey=..., _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1 } }, ... } _kCFStreamErrorDomainKey=1 is kCFStreamErrorDomainPOSIX, and code 50 is ENETDOWN. Console log for the same request shows the failure at the connection layer, before any TLS/HTTP activity: Connection 1: received failure notification Connection 1: failed to connect 1:50, reason -1 Connection 1: encountered error(1:50) Task <...>.<1> HTTP load failed, 0/0 bytes (error code: -1009 [1:50]) What we've ruled out / tried Added NSLocalNetworkUsageDescription to Info.plist — no change in behavior. Confirmed via codesign -d --entitlements - and plutil -p Info.plist that the built/signed app bundle actually contains the key. Checked System Settings → Privacy & Security → Local Network — the app itself does not even appear in the list. Tried resetting the Local Network TCC grant: sudo tccutil reset LocalNetwork com.example.Client → tccutil: Failed to reset LocalNetwork approval status for com.example.Client Also tried a full reset for the service (no bundle id): sudo tccutil reset LocalNetwork → tccutil: Failed to reset LocalNetwork Confirmed tccutil itself is functioning normally on this machine — resetting other services succeeds, e.g.: sudo tccutil reset Camera → Successfully reset Camera So tccutil works in general, but the LocalNetwork service specifically cannot be reset, on this Public Beta build, either per-app or system-wide. Question for the forum Is there a known change/regression on the Golden Gate Public Beta where the Local Network permission prompt doesn't fire for direct-IP connections that don't go through Bonjour/NWBrowser? (The same code works fine on the Developer Beta.) Has anyone else seen tccutil reset LocalNetwork fail (while other services reset fine) specifically on the macOS 27 Golden Gate Public Beta? Any known workaround short of downgrading — e.g. restructuring the connection to use Bonjour/NWBrowser instead of a direct IP connection, or some way to explicitly trigger the permission prompt? We're also planning to file this via Feedback Assistant with a full sysdiagnose, but wanted to check here first in case this is already a known/tracked issue or someone has a workaround. Thanks in advance.

Hello, We are using the UPI device validation APIs on iOS 26+ in a production banking/UPI app, and we are seeing a recurring failure from CoreTelephony that we need guidance on. API / entitlement Framework: CoreTelephony API: CTCellularPlanStatus.checkValidity(ofToken:) Related: CTCellularPlanStatus.token() Entitlement: com.apple.developer.upi-device-validation Availability: iOS 26.0+ Minimal call site do { let isValid = try await CTCellularPlanStatus.checkValidity(ofToken: token) // isValid == true/false -> expected outcomes } catch { // Unexpected: API throws instead of returning Bool print(error.localizedDescription) } Error error.localizedDescription is: English: Couldn't communicate with a helper application. Same failure also appears with a localized Hindi message on Hindi-locale devices. This is distinct from checkValidity(ofToken:) returning false (token/SIM mismatch). Here the API throws, so we cannot tell whether the token is valid. In production we currently only have this localizedDescription from telemetry. Production observations (large fleet, last few days) Observed only on production user devices so far; we have not reproduced it reliably on lab hardware. Occurs across multiple iOS 26.x builds (notably 26.5.2, 26.5, 26.6; also seen on 26.0-27.0). Not limited to a single patch. Seen on many iPhone models (not one SKU). Latency is bimodal for the same error string: large share fails in under 100 ms (immediate) another large share fails after about 2-10+ seconds (timeout-like) Observed under Wi-Fi, cellular (4G/5G), and No Connection / radio-not-ready conditions. Same device can emit many identical failures within about 1 second when validity is checked from multiple call sites concurrently. Token generation (CTCellularPlanStatus.token()) and successful checkValidity work for the vast majority of users; this throw is a smaller but material failure class. Questions for Apple Is "Couldn't communicate with a helper application." an expected / documented failure mode of checkValidity(ofToken:) (for example CommCenter/XPC unavailable, radio not ready)? What conditions typically trigger this error from checkValidity(ofToken:)? Recommended client handling: retry (with backoff)? treat as transient and skip forcing re-binding? surface to user? Does validation require cellular registration / SIM ready state even when docs indicate internet is not required? Any known issues on specific iOS 26.x builds, dual-SIM, eSIM, or airplane-mode transitions? Is concurrent checkValidity from multiple tasks unsupported / unsafe? Because this is currently production-only and not reliably reproducible on lab devices, we cannot attach a sysdiagnose or Instruments trace at this time. We can share aggregated production telemetry and API details via Feedback Assistant if helpful. Thank you.

We're investigating an edge case around push/local notification handling on macOS when multiple instances of the same app are running simultaneously, launched via open -n /path/to/App.app. We're aware this isn't the standard/expected usage pattern for macOS apps, which are singleton by default, but we need to understand and correctly handle this case, so any clarity here would help. Setup: macOS app, AppKit, using NSApplicationDelegate and UNUserNotificationCenterDelegate. Two separate processes of the same app launched via open -n, each independently calling UNUserNotificationCenter.current().delegate = self and registerForRemoteNotifications() on launch. Questions: Device token : is the device token unique per device and app installation, or could two separately-running processes of the same installed app each be issued a different token? Our understanding from Apple's documentation is that the token identifies the app and device combination, not a specific process. Can you confirm this holds even in a multi-instance scenario? Notification tap routing : when a notification, local or remote, is tapped and both process instances have independently registered a UNUserNotificationCenterDelegate, which instance's delegate receives userNotificationCenter didReceive withCompletionHandler? Is this deterministic, for example the most recently registered instance, or the one most recently connected to usernoted? Is it arbitrary or undefined? Or does the system only allow one instance's delegate connection to be active at a time, silently disconnecting the other? Is there any documented or recommended way for an app to detect it's running as a secondary instance launched via open -n, and adjust its notification handling behavior accordingly, if relevant? We understand this falls outside the normal supported usage pattern for macOS apps, but since the behavior isn't documented for this scenario, any insight, even confirming this is undefined behavior, would be genuinely useful for us to plan around.

I’m using Apple’s Network framework to implement a UDP client using NWConnection, and I have a question regarding the lifecycle of the DispatchQueue associated with an NWConnection instance. Let's assume I have an NWConnection instance, and I associate it with a dispatch queue using the start(queue:) API, such that network OS events for the NWConnection instance can be delivered to this queue. My understanding is that this association would result in NWConnection holding a strong reference to the DispatchQueue object. Now, I perform some I/O (send/receive) on the NWConnection instance and immediately perform the following steps. Also, assume that the completion closures for those I/O operations do not capture or otherwise retain the NWConnection. Call connection.cancel() and then release my last strong reference to the NWConnection. Without waiting for the connection to transition to the .cancelled state, I also release my last strong reference to the associated DispatchQueue. My question is: Does NWConnection, during its teardown, retain the DispatchQueue until the cancellation completions for all pending I/O operations associated with the connection have been delivered/executed, given that the application no longer holds any strong references to either the NWConnection or the DispatchQueue? Or, once cancel() is called, does NWConnection immediately release its reference to the DispatchQueue, in which case whether the pending callbacks are ultimately executed depends on whether the application has kept the queue alive?

Hi there, Starting with iOS 26.2 RC, all my DeviceActivityMonitor.eventDidReachThreshold get activated immediately as I pick up my iPhone for the first time, two nights in a row. Feedback: FB21267341 There's always a chance something odd is happening to my device in particular (although I can't recall making any changes here and the debug logs point to the issue), but just getting this out there ASAP in case others are seeing this (or haven't tried!), and it's critical as this is the RC. DeviceActivityMonitor.eventDidReachThreshold issues also mentioned here: https://developer.apple.com/forums/thread/793747; but I believe they are different and were potentially fixed in iOS 26.1, but it points to this part of the technology having issues and maybe someone from Apple has been tweaking it.

We are implementing StoreKit External Purchase Link for an iOS app distributed in the European Union and are trying to determine whether we are missing a configuration step or encountering a StoreKit server-side eligibility issue. The failure is reproducible in a focused native Swift Xcode project that directly calls StoreKit: let eligible = await ExternalPurchaseCustomLink.isEligible The sample contains no Flutter code, PayPal SDK, networking, or application business logic. Configuration we have verified: The Account Holder accepted the StoreKit External Purchase Link Entitlement Addendum for EU Apps. StoreKit External Purchase Link is enabled and shown as Assigned for the App ID. The regenerated Development provisioning profile contains com.apple.developer.storekit.external-purchase-link = true. The installed app's signed entitlements contain the same value. The application-identifier and team-identifier match the intended App ID and team. The compiled Info.plist contains SKExternalPurchaseCustomLinkRegions with all 27 lowercase EU region codes, including "de". Germany is available for the app in App Store Connect. No local StoreKit Configuration file is enabled. Test environment: Physical iPhone running iOS 26.5.2 (23F84) Xcode 26.6 (17F113) Real German Media & Purchases Apple Account German Sandbox Apple Account StoreKit 2 storefront ID 143443, country code DEU StoreKit 1 also reports country code DEU AppStore.canMakePayments = true AppTransaction verifies in the Sandbox environment Clean build and reinstall using the regenerated Development profile Observed result: ExternalPurchaseCustomLink.isEligible = false For diagnostic purposes only, after observing false eligibility, we also requested both token types: ACQUISITION: StoreKitError.notAvailableInStorefront SERVICES: StoreKitError.notAvailableInStorefront A delayed recheck still reports storefront DEU and isEligible=false. Our production flow does not request tokens unless eligibility is true. We found the similar thread "Unable to enable eligibility for External Purchase Link APIs" (https://developer.apple.com/forums/thread/808349). In that case, the production Media & Purchases account had an unsupported storefront. In our case, both the real Media & Purchases account and the Sandbox account are German, and StoreKit itself reports DEU. We also found "External Purchase in Japan" (https://developer.apple.com/forums/thread/822618), where an Apple App Store Commerce Engineer requested a Feedback Assistant report with a sysdiagnose and screen recording for isEligible=false. Questions: Should ExternalPurchaseCustomLink.isEligible return true in a developer-signed Sandbox build when the entitlement, compiled Info.plist, German storefront, and account conditions are all satisfied, or is TestFlight/App Store approval required? Is there any additional App Store Connect storefront election, entitlement approval, or server-side activation step required beyond the EU addendum, Assigned capability, signed entitlement, and SKExternalPurchaseCustomLinkRegions? If this configuration is complete, could Apple verify whether eligibility has not propagated correctly for the German Development/StoreKit Sandbox environment, and which diagnostics should be included in a Feedback Assistant report? We have also opened a code-level support request and prepared a minimal native Swift reproduction project. Any guidance from StoreKit engineering would be appreciated.

Overview I would like to observe calendar changes using NotificationCenter.messages(of: for:) I want receive Sendable messages, not traditional Notification which is not Sendable Problem I can't seem to get the following code to compile import EventKit NotificationCenter.default.messages( of: EKEventStore.EventStoreChanged.Subject.self, for: .changed ) Reference https://developer.apple.com/documentation/foundation/notificationcenter/messageidentifier/changed-50yz5 Questions How can I use by using NotificationCenter.messages(of: for:) for Calendar changes?

Hello, I have a question about App Intents and the Action button on iPhone. I have an App Intent that opens the app and navigates to a specific entity, conforming to OpenIntent with a single AppEntity parameter. The entity conforms to EnumerableEntityQuery, and the intent is registered as an App Shortcut via the AppShortcutsProvider. When assigning this shortcut to the Action button in Settings, the system doesn’t prompt the user to select a default entity upfront. Instead, it prompts on every activation, creating friction. In contrast, shortcuts like “Open Note…” and other third-party ones prompt the user for a note to open when setting up the Action button, and its title also includes three dots, indicating a pre-configurable parameter. My shortcut’s title shows no dots. What’s required to make an App Shortcut prompt for a default parameter during Action button setup? Sincerely, Holger

Is macOS 27 Public Beta 2 able to activate new non‑MDM CMIO system extensions that fail on macOS 26.5.2? I'm building a virtual-camera app with a CMIO camera system extension (Developer ID signed + notarized), for personal use on my own Macs — no MDM. On macOS 26.5.2 (25F80) I can't get a new activation to succeed, and I'm trying to find out whether macOS 27 resolves it. Two failure modes I've seen: With SIP enabled, OSSystemExtensionRequest reaches the daemon, then sysextd logs: "no policy, cannot allow apps outside /Applications" — even though the app is in /Applications (verified real path, single copy, running from there). This matches other reports (e.g. LuLu / network extensions). With SIP disabled + systemextensionsctl developer on, it now fails earlier, client-side, with OSSystemExtensionErrorDomain code 4 — "Extension not found in App bundle / Unable to find any matched extension with identifier" — the request never even reaches sysextd. Things I've already verified/ruled out: Product type com.apple.product-type.system-extension; extension embedded at Contents/Library/SystemExtensions/; matching CFBundleIdentifier and Team ID; CMIOExtensionMachServiceName = $(TeamIdentifierPrefix)$(bundle id). App has com.apple.developer.system-extension.install (with authorizing profile); shared App Group + camera entitlement on both app and extension. Valid codesign --deep --strict; notarized + stapled; single LaunchServices registration; running the correct bundle. Reproduces with both Developer ID and Apple Development signing, and running straight from Xcode with a signed-in account. So the app/extension appear structurally correct; this looks like an OS-side regression in 26.5.x. My question: Has anyone successfully activated a new Developer ID (non-MDM) CMIO / system extension on macOS 27 Golden Gate Public Beta 2? Is this sysextd / code‑4 activation regression fixed there, or is it still present? Trying to decide whether upgrading is worth it. Thank you!

I'm building a freediving app for Apple Watch Ultra using the shallow depth entitlement (com.apple.developer.submerged-shallow-depth-and-pressure). My app uses WKExtendedRuntimeSession with the underwater-depth background mode, and it works correctly — the session starts, Water Lock activates automatically, and Crown hold water ejection ends the session as expected. However, the app does not appear in Settings > General > Auto-Launch > When Submerged on the watch. Other third-party apps (including one that hasn't been updated in ~2 years and presumably only has the shallow entitlement) do appear in this list. My configuration: WKBackgroundModes: ["underwater-depth", "workout-processing"] WKSupportsAutomaticDepthLaunch: true (Boolean, in watch app Info.plist) Entitlement verified in both the signed binary and provisioning profile watchOS 26.3, Apple Watch Ultra 2 Tested with: development build, TestFlight, and direct Xcode deploy. Watch restarted after each. The app does not appear in any case. The documentation at https://developer.apple.com/documentation/coremotion/accessing-submersion-data states: "Adding the underwater-depth Background Mode capability also adds your app to the list of apps that the system can autolaunch when the wearer submerges the watch." Does auto-depth-launch require the full depth entitlement (com.apple.developer.submerged-depth-and-pressure), or should the shallow entitlement be sufficient? Is there an additional step required for the app to appear in the When Submerged list? Any guidance appreciated.

Hello, I've been working on this side project to help me understand the uses of Swift and CloudKit. In the middle of this project my "MHLocation" Data Record always keeps facing an internal error and this has been happening on and off for the past 6 months. What can I do to stop this error? I am willing to work with anyone on this. Best, Jordan