我们基于 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.

I'm building a Matter irrigation system and I've hit a device-type wall in the Home app. This is not a commissioning or pairing problem - the accessory is found, setup proceeds, and then Home declines to create the accessory, reporting that the device is not supported. The controlled comparison, which is why I'm confident it is the device type and nothing else: Endpoint declares 0x0042 Water Valve (Matter 1.3) with cluster 0x0081 Valve Configuration and Control -> Home: NOT SUPPORTED, accessory is not created. Endpoint declares 0x010A On/Off Plug-in Unit with cluster 0x0006 On/Off -> Home: created, works, valve opens and closes. Same hardware, same firmware image, same network, same iPhone. The only variable is the device type ID. Other Matter controllers accept the 0x0042 version and control it correctly. Water Valve (0x0042) - is this device type supported by the Home app in any current or announced iOS version? If not, is support planned? Right now I ship the plug-in-unit substitution because it is the only thing Home will accept. It works, but it misrepresents the device: the user sees a row of "plugs" that are actually irrigation valves, with no valve semantics and nothing telling Home - or an automation the user writes - that switching this on releases water into a garden. Soil Sensor (Matter 1.5) - same question. Matter 1.5 added soil sensing (moisture, optionally temperature), explicitly positioned for irrigation paired with Matter water valves. Is it supported or planned in Home? Today I publish soil moisture on a Relative Humidity Measurement endpoint (0x0405) because that is what Home renders, so garden soil moisture appears as air humidity and pollutes any humidity-based automation the user has. The general question, which is the one I actually want answered: is there an authoritative list of the Matter device type IDs the Home app accepts? The public support article describes categories in prose (lights, plugs, switches, thermostats, sensors...), but gives no device type IDs, so there is no way to check a design against it before building. I would like to design to the list rather than discover at pairing time that Home will not create my accessory. A related composition question: my controller is a single accessory with seven independently controlled valve endpoints, and endpoints exist only for valves the installer has enabled. When a valve is disabled and its endpoint disappears, Home keeps showing it until the accessory is removed and re-added. Is there a supported way to make Home re-read a device's composition in place - and for seven valves, does Apple prefer one accessory with seven endpoints, or a Bridge (0x000E) exposing seven accessories? Setup: Matter over Wi-Fi (2.4 GHz), esp-matter / connectedhomeip, test VID 0xFFF1 during development. iOS 17 and 18, iPhone 12, Home hub present. Happy to provide the full endpoint and cluster composition or logs if useful.

Hi everyone, I recently submitted a request for the CarPlay Video App entitlement (com.apple.developer.carplay-video) via Apple's CarPlay entitlement request form. I submitted the request about a week ago, but I haven't received any update yet — no approval, rejection, or request for additional information. About the app: It is a video player designed for user-provided M3U/M3U8 playlists and locally imported media files. The app does not host, provide, or stream any built-in content itself. It follows Apple's CarPlay Video APIs and is intended to support video playback only when the vehicle permits video playback, such as when parked. I've noticed recent discussions from developers who already hold the CarPlay Video entitlement, but details regarding the review timeline seem quite limited. For developers who have successfully obtained the CarPlay Video entitlement: Approximately how long did it take from submitting the request form to receiving the entitlement decision? Did Apple reach out for additional details or clarification during the review process? Did you need an active TestFlight build or App Store submission prior to receiving the entitlement? Is there any dashboard or portal to track the status of a CarPlay entitlement request, or is email the only channel? Any insights from your experience would be greatly appreciated! Thanks!

My macOS app Find Any File contains another app inside its Resources folder. It's a background-only app that checks if the user presses a hotkey, in which case it launches my app. Since macOS 27, when the hotkey app is running, it appears in the Dock with a "Running in Background" subtitle. That's totally not wanted. How do I make it not appear in the Dock? I've got both "LSBackgroundOnly" and "LSUIElement" set to true in the Info.plist, to no avail.

We're experiencing an issue where the CarPlay Simulator (from Apple Developer Additional Tools) stopped connecting to our iPhones as of March 4th, 2025. The simulator gets stuck indefinitely on "Connecting to phone" and never completes the pairing. Environment App: Oracle Field Service iOS app (with CarPlay support) Tool: CarPlay Simulator from Apple Developer Additional Tools (developer.apple.com/download/all/) Issue start date: Wednesday, March 4th, 2025 Tested on: Multiple Mac machines, multiple iPhones Multiple CarPlay Simulator versions tested What's happening The CarPlay Simulator launches but displays "Connecting to phone" indefinitely. It was working correctly prior to March 4th with no changes on our end. What still works CarPlay functions correctly when the same iPhone is connected to a real car, confirming the issue is specific to the simulator. Troubleshooting steps already attempted Reset permissions and re-added the simulator Forgot the simulator and re-paired it Changed the USB cable Tested on multiple Mac machines Tested on multiple iPhones Tried multiple versions of the CarPlay Simulator Confirmed no VPN is in use Confirmed with IT, no OS updates or enterprise restrictions were applied Questions Has anyone else experienced this since March 4th? Was there a change in CarPlay Simulator behavior or a requirement on the Apple side (certificate, entitlement, protocol) around that date? Is there a known workaround or fix?

I see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.