Hey everyone, Curious how other iOS teams/indies are dealing with Apple's Privacy Manifests (PrivacyInfo.xcprivacy) and Required Reason APIs now that enforcement is active. Recently had to deal with third-party dependencies (both CocoaPods and SPM packages) where an undeclared API usage buried deep inside an embedded framework caused an App Store submission headache (ITMS-91053). I wanted to ask: What does your pre-submission workflow look like? Are you auditing privacy manifests and API reasons manually, using Xcode’s built-in report, or do you have a custom script in your CI/CD pipeline? Third-party SDK visibility: How do you catch when an updated dependency introduces an undeclared restricted API or tracking domain before pushing to TestFlight / App Store Connect? Local vs Cloud tooling: If you were checking compliance pre-flight, would your team ever be allowed to upload compiled .ipa binaries to a 3rd-party cloud service, or does security require everything to run 100% locally on your machine/CI runners? Is this painful enough to care? Is this just a one-time setup headache you ignore once it passes, or does dependency churn cause regular release friction? Would love to know how you guys handle this in production builds. Thanks!

I have set up my app to allow for notifications and had previously tested it and it was working. Now, when I or others go into settings on our phones and go to the app, notifications is not even an option. When I go into settings and go to Notifications, the app doesn't even show up in the list. As mentioned, we had previously been able to receive notifications and the Key is set up to do so. Thanks for your help!

Is there a recommended way to include a resource bundle (images, json config) inside a Swift Package so it works correctly when the package is used as a local dependency vs a remote one? Running into path resolution differences between the two.

NSJSONSerialization silently drops U+FEFF from JSON string content — keys merge, characters vanish TL;DR: NSJSONSerialization deletes U+FEFF (ZERO WIDTH NO-BREAK SPACE / BOM) from anywhere inside parsed JSON strings — not just a leading document BOM, and even when written as the \uFEFF escape (it's removed after unescaping). Distinct strings/keys silently collapse onto their U+FEFF-less twins. If you're seeing JSON keys mysteriously merge or a character disappear from a parsed value, this is probably why. It is not your code. Workaround and exhaustive scope below. The workaround Two options, depending on how attached you are to Foundation: A. Stay on NSJSONSerialization — swap U+FEFF for a private-use sentinel before parsing, restore after. You must handle both the raw bytes and the \uFEFF escape (the escape bites too, since deletion happens post-unescape): // 1. Pick a private-use scalar you've verified is absent from the source text. // 2. Replace every in-content U+FEFF (raw char AND \uFEFF escape) with it. // 3. Parse. NSJSONSerialization preserves the sentinel. // 4. Recursively restore the sentinel -> U+FEFF in the parsed tree. static id RestoreSentinel(id o, NSString *s, NSString *bom) { if ([o isKindOfClass:NSString.class]) return [o rangeOfString:s].location == NSNotFound ? o : [o stringByReplacingOccurrencesOfString:s withString:bom]; if ([o isKindOfClass:NSArray.class]) { NSMutableArray *a = [NSMutableArray arrayWithCapacity:[o count]]; for (id e in o) [a addObject:RestoreSentinel(e, s, bom)]; return a; } if ([o isKindOfClass:NSDictionary.class]) { NSMutableDictionary *d = [NSMutableDictionary dictionary]; [o enumerateKeysAndObjectsUsingBlock:^(id k, id v, BOOL *stop) { d[RestoreSentinel(k, s, bom)] = RestoreSentinel(v, s, bom); }]; return d; } return o; } Swap the escape form with a backslash-parity-aware regex so \uFEFF (escaped backslash + literal "uFEFF") is left intact: (?<!\\)((?:\\\\)*)\\u[Ff][Ee][Ff][Ff] -> $1<sentinel> B. Don't use Foundation for this file — a spec-compliant C parser like ++yyjson++ preserves U+FEFF and is faster on large files. (This is the route swift-transformers took for tokenizer.json.) Minimal repro // Object keys collapse: NSData *d1 = [@"{\"\\uFEFF#\":1,\"#\":2}" dataUsingEncoding:NSUTF8StringEncoding]; id o1 = [NSJSONSerialization JSONObjectWithData:d1 options:0 error:nil]; // EXPECTED: 2 keys ("\uFEFF#" and "#"); ACTUAL: 1 key ("#") — \uFEFF stripped, keys merged // String content lost: NSData *d2 = [@"[\"\\uFEFF\"]" dataUsingEncoding:NSUTF8StringEncoding]; id o2 = [NSJSONSerialization JSONObjectWithData:d2 options:0 error:nil]; // EXPECTED: ["\uFEFF"] (one code point); ACTUAL: [""] (empty string) Same outcome whether U+FEFF arrives as raw EF BB BF bytes or the \uFEFF escape. Why this is a bug, not a quirk Per RFC 8259 §7, a JSON string is a sequence of Unicode code points; U+FEFF is ordinary content and doesn't require escaping. Tolerating a leading document BOM is fine — deleting U+FEFF from string content is not. U+FEFF leads a double life (BOM signal vs. ZERO WIDTH NO-BREAK SPACE character); Foundation treats every occurrence as a stray BOM to scrub. Scope — exhaustive, not anecdotal I swept all 1,112,064 valid Unicode scalars (U+0000–U+10FFFF minus surrogates) through a parse round-trip, in both the \uFEFF-escape and raw-UTF-8 forms: U+FEFF is the only scalar altered. Every other scalar round-trips byte-identically — including the other zero-widths (U+200B, U+2060, U+00A0), which all survive. No Unicode normalization occurs (NFD stays decomposed, combining sequences and compatibility characters are preserved). So this is a deliberate BOM-stripping heuristic applied too broadly to string content — narrow and fixable, not general mangling. Why it's nasty in practice U+FEFF is zero-width, so the corruption is invisible — no trace in a diff or editor. Real-world hit: ML tokenizer vocabularies (e.g. Google's Gemma) legitimately contain U+FEFF-bearing tokens; loading tokenizer.json via NSJSONSerialization collapses those keys and assigns wrong token IDs, with zero visible symptom until output is subtly wrong. Filed as FB23271905 — please dupe if this has bitten you. More duplicates is what gets it triaged.

On Apple silicon macOS 27.2 build 26B123, consider a launchd-managed supervisor making one posix_spawn call to start a dedicated worker. The supervisor may exit before receiving the PID or before it can wait for the child. Is there a supported API or OS-issued record that lets a surviving observer verify what happened to that one attempt? Can the observer distinguish an attempt that created no child from one that created a child before the caller received the PID? What stable identifier ties creation and any exec transition to that attempt? If the supervisor exits, which component actually performs the reap? Can the observer verify the same child's exit status, completed reap, and absence of surviving descendants after restarting? Please identify the supported macOS versions, privileges, record source, correlation fields, and any loss or retention limits. If no supported record covers a step, please identify that boundary.

Step: Create and persist a model. Encode its persistentModelID using JSONEncoder. Decode the encoded data back into a PersistentIdentifier. Use the decoded identifier in a FetchDescriptor predicate to fetch the model. Modify a property of the model without saving the context. Execute the exact same fetch again, using the same decoded PersistentIdentifier and the same predicate. Example: do { let item = Item() modelContext.insert(item) try modelContext.save() // Encode and decode the persistent identifier. // The decoded identifier is essential to reproduce the issue. let data = try JSONEncoder().encode(item.persistentModelID) let decodedPID = try JSONDecoder().decode( PersistentIdentifier.self, from: data ) func find(_ pid: PersistentIdentifier) throws -> Item? { let descriptor = FetchDescriptor<Item>( predicate: #Predicate { $0.persistentModelID == pid } ) return try modelContext.fetch(descriptor).first } // First fetch succeeds. var result = try find(decodedPID) print("0. Found: \(result != nil)") // true // Modify the persisted model without saving the context. item.timestamp = .now.addingTimeInterval(-3600) // Second fetch uses exactly the same PID and predicate, // but unexpectedly fails. result = try find(decodedPID) print("1. Found: \(result != nil)") // false } catch { print(error) }Actual Behavior: The first fetch successfully finds the model. After modifying one of its properties without saving the context, the second fetch returns an empty result, even though: The same ModelContext is used. The same decoded PersistentIdentifier is used. The same predicate is used. The model has not been deleted. No save operation has occurred between the two fetches. Expected Behavior: The second fetch should return the same model. Changing an ordinary property of a model without saving should not invalidate its persistent identity or cause a predicate matching that identity to stop finding the model. Additional Observations: If the original item.persistentModelID is used directly instead of the decoded identifier, the issue does not occur. If the model is not modified between the two fetches, both fetches succeed. Questions: Is it expected that a PersistentIdentifier restored through Codable can be used in a SwiftData predicate? Why does a predicate using a decoded PersistentIdentifier stop matching a model after an unsaved property or relationship change? Is this a known issue or a limitation of using persistentModelID inside a #Predicate? What is the recommended way to persist a PersistentIdentifier and subsequently use it to fetch the corresponding model across different operations or app launches?

Hello, We are developing an iOS app that helps people review their device use through daily carbon estimates, a garden, local history and Home Screen widgets. All processing stays on the device. We want users to grant permission without choosing each app or entering daily figures. The app has Family Controls distribution approval and the Family Controls App and Website Usage capability. However, the documentation for approvedWithDataAccess describes customer access for a device in the EU with an Apple Account set to an EU country or region. The Apple-provided development profile allows testing in other regions, so we do not treat a successful development test in Switzerland as approval for Swiss customers. Could an Apple engineer clarify the supported design for users located in Switzerland with a Swiss Apple Account? Is there a documented API, entitlement or approval route for direct app-duration access in this situation? If direct access is unavailable, can ordinary individual authorization and DeviceActivityReport show all available activity without an app-by-app picker? Under the report extension's privacy rules, can a daily result be made available to the main app's history and widgets through any supported mechanism, or must it stay inside the report? Do TestFlight installations follow the same regional conditions as App Store installations? We are looking for a design that follows the published access and privacy rules. We do not want to infer missing activity, work around regional restrictions, or treat development access as customer approval. Documentation: https://developer.apple.com/documentation/familycontrols/authorizationstatus/approvedwithdataaccess Thank you for any guidance.

Since November 5, in-app subscriptions have suddenly stopped working in all three of my apps on the App Store. Everything worked perfectly before, and no changes were made to the apps. The subscription purchase buttons no longer display prices, only a dash ("–"). Existing apps can still be downloaded normally. I reproduced the problem in Xcode on my own device. StoreKit reports: STOREKIT: Received 0 products STOREKIT: Invalid IDs = ( "TEE_year", "TEE_month", "TEE_week" ) All subscription products are still configured in App Store Connect, and the agreements appear to be active. Interestingly, the problem started around the time I accepted updated Apple agreements and changed my address in my developer account. I don't know whether this is related. Several customers have already independently reported the same problem, so this is not limited to my own device or Apple ID. I strongly suspect an App Store Connect or StoreKit backend issue rather than an app-specific programming error. I've contacted Apple Developer Support (case ID is 30000008123797) but haven't received a solution yet. Has anyone else experienced subscriptions suddenly becoming unavailable across multiple apps? Could this be related to updated agreements or account information?

I’m investigating delayed HealthKit background delivery in an iPhone calorie-tracking app installed through TestFlight. The app reads activeEnergyBurned and submits a local notification with a custom sound for every newly accumulated 20 kcal. The intended behavior is passive: the user walks normally without explicitly starting a workout. Current behavior: Rewards appear after opening the app. Unlocking the phone to the iPhone Home Screen does not trigger the accumulated rewards. The app is backgrounded, not force-quit. A separate local notification scheduled 10 seconds ahead successfully displays and plays its custom sound while the phone is locked. Implementation: An HKObserverQuery for activeEnergyBurned, with predicate nil, is registered during application(_:didFinishLaunchingWithOptions:). Background delivery is requested with frequency .immediate. The installed TestFlight app has the HealthKit and HealthKit background-delivery entitlements. With valid locally stored access, Health processing does not wait for a StoreKit subscription query. In the captured trace, observer callbacks complete promptly and healthd reports no outstanding launches afterward. Recorded test on November 7, 2026 (device-log times, UTC−07:00): Around 07:03, I manually added 40 kcal in Apple Health. At 07:03:42, Health received an added sample. healthd scheduled the next Active Energy background launch for 08:03:14, approximately one hour after our previous observer completion. At 07:05:42, I unlocked to the Home Screen. Protected Health data became available, but no corresponding observer callback reached our app. At 07:08:40, I opened our app. Its observer callback arrived immediately, and two reward notification requests were accepted without error. Earlier development installations appeared to deliver accumulated rewards upon unlocking to the Home Screen, even after the debugger had disconnected. Subscription integration occurred between those versions, but we have not established the cause of the difference. My questions: Is an approximately one-hour interval expected for activeEnergyBurned on iPhone despite requesting .immediate? Can foreground observer completions advance the next permitted background delivery time? Is there a supported way to receive pending Active Energy updates after unlocking, without opening the app or starting an HKWorkoutSession? I can provide targeted implementation details and additional relevant log excerpts if needed. Thank you.

Device and software: iPhone model: iPhone 15 Pro iOS 27 Public Beta 6 Build: 24A5430a BLE receivers: two independent ESP32's IRK has worked reliably on iOS 26 and past versions. Observed behavior: With the iPhone display on both BLE receivers detect advertisements that resolve correctly using the enrolled IRK. No more than 10 seconds after the display is turned off, the IRK-resolvable advertisements stop. The IRK identity returns immediately when a notification wakes the display or when I manually do. Bluetooth itself remains active while this happens. The receivers continue to see several strong advertisements from the phone with some unidentified rotating addresses. The unidentified addresses rotate periodically and cannot be associated with the enrolled IRK. Additional observations: When my Apple Watch is powered on and connected, the iPhone remains IRK-detectable while the screen is off. It stops again when watch is disconnected. Connecting Bluetooth headphones does not have the same effect. The IRK-resolvable advertisement stops even while music continues playing. Moving the affected phone between two receivers confirmed that the unidentified rotating advertisements physically followed the phone. The existing IRK remains valid because it resolves the phone again immediately whenever the display wakes. I couldnt find any intentional IRK, private-address or screen-off advertising change documented in the iOS 27 release notes or any discussions online. Has anyone else observed this on iOS 27?

Hello Apple Developer Forum, We have implemented the Declared Age Range API exactly as described in Apple's documentation. Our implementation checks isEligibleForAgeFeatures before calling requestAgeRange, as recommended. We have been testing with different users located in Texas (US) and Brazil. However, for all users, isEligibleForAgeFeatures consistently returns false, so the Declared Age Range prompt is never displayed. We would appreciate some clarification on the following: Under what conditions does isEligibleForAgeFeatures return true? When is the Declared Age Range prompt expected to be shown? Besides the user's region, are there any additional eligibility requirements, such as whether the Apple ID has a verified payment method (credit/debit card), verified identity or address, account age or a phased rollout? Since all of our test users are in supported regions (Texas and Brazil), we expected at least some users to be eligible. However, all four test accounts consistently return false. Could you please clarify how Apple determines eligibility for the Declared Age Range feature and when developers should expect the prompt to appear? Thank you for your guidance.

Summary A minimal read-only FUSE-T filesystem cannot be mounted over a newly created, empty directory on an external APFS volume. FSKit reaches the LIFSv2 mount stage, but the final mount(2) returns EPERM. In the same timestamp window, sandboxd requests kTCCServiceSystemPolicyRemovableVolumes on behalf of root /usr/libexec/fskitd. The request is forwarded to com.apple.tccd.system, but TCC logs an invalid XPC connection and sends an empty reply with no auth_value. sandboxd then reports the missing authorization value and denies the request; fskitd immediately reports mount(2) error 1. No user-facing consent prompt appears. This looks like an authorization handoff or policy-integration failure in the system FSKit mount path, rather than a denial returned by the filesystem implementation. The exact reason com.apple.tccd.system returns an invalid or empty reply is unknown. Environment ItemValueTest date/time2026-11-06, approximately 18:47:31 CETMacApple silicon (arm64)macOS27.2, build 26B123FUSE-T receiptsorg.fuse-t.core.1.2.9, org.fuse-t.fskit.1.2.9Registered FSKit extensionorg.fuset.fskit-srv.module, version 0.1.3FUSE-T library/Library/Application Support/fuse-t/lib/libfuse-t-1.2.9.dylibTarget volumeWDBlack4TB, /dev/disk8s1; case-sensitive APFS; owners enabled; read/write; diskutil reports Protocol: PCI-Express and Device Location: ExternalMount pointNewly created, empty directory on the target volume; owned by logged-in user (UID 501), mode 0700Minimal reproduction Enable/register the FUSE-T FSKit extension using its normal installation flow. Build or use a minimal read-only FUSE filesystem whose callbacks expose only the root directory and one static hello.txt file. The fixture used here was linked directly to FUSE-T 1.2.9 and did not read backing files or modify the target volume. As the logged-in user (UID 501; no sudo), create a new empty directory on an external APFS volume. Start a bounded unified-log capture for fskitd, sandboxd, and tccd, then run: ./hello -f -o backend=fskit <empty-directory-on-external-volume> Observe the mount failure and preserve the same-window logs. Actual result The FUSE process exits 1 and prints: fuse: mount failed with error: -1. No mount is created at the test path. fskitd finds/starts the FSKit extension instance and reaches “will mount over LIFSv2”. The final mount(2) fails with errno 1 (EPERM / “Operation not permitted”). The TCC events below occur at the same timestamp as the mount(2) error. No permission prompt is shown to the logged-in user. Timestamp-correlated attribution and authorization evidence At 18:47:31.793, fskitd enters the LiveFS mount path. At 18:47:31.801, tccd records the relevant attribution chain: accessing={TCCDProcess: identifier=com.apple.fskitd, pid=36573, auid=0, euid=0, binary_path=/usr/libexec/fskitd} requesting={TCCDProcess: identifier=com.apple.sandboxd, pid=472, auid=0, euid=0, binary_path=/usr/libexec/sandboxd}At 18:47:31.824, TCC logs a platform-binary prompting policy of Deny. In this trace that message is associated with a separate SystemPolicyAllFiles check; the All Files result is not being presented as the final Removable Volumes denial. At 18:47:31.829, sandboxd checks kTCCServiceSystemPolicyRemovableVolumes for fskitd. Because the audit token has auid=-1, sandboxd routes the authorization request based on euid 0 to com.apple.tccd.system. The request includes fskitd’s audit token (pid 36573, auid -1, euid 0). The system tccd endpoint returns an invalid XPC connection / an empty reply without auth_value. The relevant messages are: sandboxd: checking kTCCServiceSystemPolicyRemovableVolumes for fskitd sandboxd: auid = -1; routing based on euid (0) instead tccd: REQUEST ... tccd_uid=0 ... service=kTCCServiceSystemPolicyRemovableVolumes sandboxd: RECV ... { count = 0 ... contents = } sandboxd: Error ... Code=2 "missing 'auth_value' in reply message" tccd: XPC forwardMessage error: Connection invalid tccd: sending empty reply ... auth_value absent sandboxd: kTCCServiceSystemPolicyRemovableVolumes denied by TCC for fskitd fskitd: mount(2) error: 1 fskitd: mount launch failed with result "Operation not permitted"The same EPERM/TCC failure was seen in earlier diagnostic attempts and again in this fresh invocation; this run provides the full timestamp-correlated attribution capture. It happens before a successful mount. The captured report contains the exact log lines selected from the bounded unified-log stream. Expected behavior / questions for Apple Is kTCCServiceSystemPolicyRemovableVolumes expected to authorize the final LIFSv2 mount performed by fskitd when a client asks to mount over a directory on external APFS? For a root system daemon with auid=-1, should sandboxd route this request to com.apple.tccd.system? Why does that endpoint return an invalid connection / empty reply rather than an authorization result? What is the supported authorization flow for this case? Should a user-consent prompt be shown to the initiating application, or should the system broker authorize fskitd using the caller’s audit token or security-scoped destination access? If this mount operation is unsupported by design, could the documentation or returned error distinguish that policy from a generic EPERM? Impact FSKit-based user-space filesystems cannot mount into an existing folder on this external APFS volume, despite the empty mountpoint being owned by the user and despite the FSKit extension loading successfully. This blocks applications that must expose a virtual filesystem at the user-selected original folder. The failure is in the system mount / authorization path; the minimal filesystem does not implement writes or access external backing data. Limitations This reproduction establishes the behavior on one Apple-silicon Mac, macOS 27.2 (26B123), FUSE-T 1.2.9, and one external APFS volume. It does not establish whether this is a general macOS defect, a machine-specific TCC daemon condition, or an intentional policy with a broken authorization response. The cause of com.apple.tccd.system’s invalid XPC reply remains unknown.

Hello, Our iOS app has been rejected four times under Guideline 2.1(a) because sign-in fails on the review iPad. The latest rejection showed NSURLErrorDomain error -1001 (the request timed out) on an iPad Air 11-inch (M3) with iPadOS 27.0, on November 5, 2026, at about 11:54 UTC. The same happened on October 16, 2026. Setup: API: https://wp.pavilion.az, HTTPS on port 443, fixed DNS name DNS and proxy on Cloudflare (IPv4 and IPv6), publicly trusted certificate The app uses URLSession, with no custom certificate checks and no proxy settings What we checked: Neither our origin server nor Cloudflare logged any request from the review device on either day. Other clients were served normally during the same minutes. The domain resolves normally from many public DNS resolvers in the United States and Europe, over IPv4 and IPv6. The app signs in in under one second on an iPad simulator in a data center in Los Angeles, and on our own devices through TestFlight. This looks similar to https://developer.apple.com/forums/thread/773444, where a Cloudflare-hosted domain resolved to a wrong address inside Apple's network. Could someone from Apple check how wp.pavilion.az resolves, and whether it is reachable, from the App Review network? We have resubmitted a build that adds a short network check to the error message (the DNS result and which connection step fails), but each review cycle takes many days. Thank you.

Our app, Unscroll, has an auto-renewable monthly subscription. Users set a daily time limit inside the app. We plan to give a monthly subscriber a free next month through a promotional offer (type: Free, duration: 1 month) when they stayed within their limit on at least 20 days of the current subscription period. Eligibility is computed on the device from the app's own measurement of time spent inside Unscroll. We do not use Screen Time, Family Controls or DeviceActivity data for it. Every paid feature stays available to every subscriber. The free month is an extra, and nothing depends on it. The offer is shown inside the app; notifications are not required. The full monthly price is shown first on the subscription screen, with the condition written next to it. Questions: Is this use of promotional offers acceptable under App Review Guidelines 3.1.1, 3.1.2 and 3.2.2(x)? Can the same customer redeem the same free promotional offer again in later periods (once per qualifying period)? For an active monthly subscriber, does a free promotional offer for the same product take effect at the next renewal date? Thank you.

Hello, We are developing an application for users located in mainland China who need to plan outbound travel. Users need to search for locations outside mainland China and view rich information provided by Apple Maps services on a map. We have encountered certain limitations in MapKit’s behavior and would like to confirm the boundaries of the public API. Background and observations : Feedback report FB13557287 (originally filed on macOS 14.2) describes the following: when developers use MKLocalSearchCompleter, users in mainland China receive only results within mainland China. Searches for overseas locations such as “New York” or “Berlin” return no results, and using a VPN reportedly does not improve the situation. The developer quoted Apple’s response as “This is expected.” Is this still the expected behavior on the current versions of iOS/iPadOS/macOS 27? If the behavior has changed, what is the correct configuration? On the same device located in mainland China, the Apple Maps app can display overseas map data, and in our tests it can also return overseas locations. The China-region attribution page (https://gspe21-ssl.ls.apple.com/html/attribution-cn2-98.html) lists the data providers for mainland China and states, “Sources for map data outside China can be found here.” This appears to indicate that the Maps app uses a dual-data-source model combining mainland China data with global data. At the same time, we cannot find overseas locations in the “Add Location” feature of Reminders and Journal, which is consistent with the behavior we have observed in the public MapKit APIs. Questions : Can third-party applications obtain the same cross-border data capabilities as the Apple Maps app through public MapKit APIs? If so, which APIs, configurations, or entitlements are required? If not, is this an intentional design decision? Could this be explicitly documented in the MapKit documentation? Does the Maps app select its data source based on the map viewport or individual requests, while MapKit selects a single data source based on the device’s region? If so, do the public APIs allow an application to specify a data source per request? If public MapKit APIs cannot support this scenario, what architecture does Apple recommend as best practice? Are the same regional restrictions applicable to the Apple Maps Server API? Specifically, when /v1/search is called from a backend or account operating within mainland China’s network environment, can overseas results be returned when limitToCountries or searchRegion is configured? Does /v1/directions support cross-border routing? We are not asking about private APIs or seeking ways to bypass regional restrictions. Our goal is to understand the supported boundaries of the public APIs so that we can make appropriate product-design decisions. Thank you.

We have a BLE pulse oximeter (medical device, Bluetooth 4.0 module) that can no longer be connected from iPhone 17 running iOS 27.0.1 and 27.2. CBCentralManager.connect() never results in didConnect or didFailToConnect; the connection stays pending indefinitely. The same accessory works on: iPhone 17 with iOS 26.6.1 iPhone 15 with iOS 27.0.1 iPhone 14 Pro Max with iOS 26.5.2 The issue also reproduces with nRF Connect and LightBlue, so it does not appear to be specific to our app. Other BLE devices connect normally on the same iPhone 17. PacketLogger traces from iPhone 17 (failing) and iPhone 15 (working) are attached to FB25459075. It is possible that the accessory firmware does not fully follow the Bluetooth specification. However, many units are already in use by patients and may not be firmware-updatable. Questions: Is this a known issue with iPhone 17 on iOS 27? Could Apple consider an interoperability fix, since the same accessory works on iPhone 17 with iOS 26.6.1 and on older iPhone models with iOS 27? Is there any workaround we can apply in our app?

How do I conect Gatt over ble(not Gatt over br/edr) when classic connected ? My device must use ANCS by ble transport and A2DP/HFP by classic transport.

We are currently testing the implementation of our Location Push Service Extension (LPSE) in both Ad Hoc and Release environments. We have encountered an issue where LPSE notifications, which were previously working correctly, suddenly fail to be delivered on some devices. After a period of several hours, the notifications resume arriving, but the issue remains intermittent. Notably, during these periods of suspected delivery restriction, regular push notifications (e.g., those using apns-push-type: alert) are delivered and displayed without any problem. [Detailed Situation] Test Environment and Scope We are testing LPSE after obtaining the necessary entitlements, in both Ad Hoc and Release environments. The issue is not observed on all test devices; only certain devices are affected. Observed Behavior Under normal circumstances, LPSE notifications are received and the extension is activated; however, on some devices the notifications suddenly stop arriving. During these periods, even when sending notifications with apns-push-type: location directly via the CloudKit Push Notification Console, no response is observed on the affected devices. The APNs server (api.push.apple.com) always returns a 200 OK response via HTTP/2, and our server-side logs and configurations (DNS resolution performed on every request, using the same JWT token for 59 minutes per session, communication via HTTP/2 with ALPN Protocol: h2) show no issues. Other app functionalities (network communication, UI responsiveness, etc.) work normally. Sending content When sending notifications from our server to APNs (api.push.apple.com), we use the following configuration (over HTTP/2): const payload = { aps: { 'content-available': 1 } }; const headers = { ':method': 'POST', ':path': /3/device/${apnsToken}, 'Authorization': bearer ${jwtToken}, 'apns-topic': 'ot.Here.location-query', 'apns-priority': '10', 'apns-push-type': 'location', 'Content-Type': 'application/json' }; We perform DNS resolution for every request, use the same JWT token for a 59-minute period per session, and communicate via HTTP/2 with ALPN Protocol: h2. Hypothesis on the Cause We suspect that due to an implementation issue, silent push notifications (using content-available: 1) were being sent every few minutes concurrently, which may have triggered an APNs delivery restriction (rate limiting). As a countermeasure, we have completely stopped sending silent pushes and any other background notifications aside from LPSE; however, the issue persists. Additionally, even after resetting affected devices, the delivery problem continues to occur. [Questions for Diagnosis] Given the above situation, is it reasonable to suspect that excessive silent push notifications have triggered an APNs delivery restriction? Does such a silent push restriction affect LPSE notifications (i.e., those sent with apns-push-type: location)? Do APNs delivery restrictions persist even after a device has been reset? Can a high volume of LPSE notifications alone (without silent pushes) also trigger a delivery restriction? → This is our primary concern since it poses a significant implementation challenge. Please let us know if any additional information is required for diagnosis.

When using AlarmKit (AlarmPresentation.Alert), the native system buttons (Stop / Open) successfully trigger the assigned AppIntent (e.g., implementing AppIntent with perform()) when running on the iOS Simulator. However, on physical devices (Real iOS Devices), these native buttons are completely dead. Even with a paid Apple Developer Program account, Production/Release-level code signing, and a clean build, tapping the native buttons on the Lock Screen / Full Screen alert results in zero calls to perform() (no logs, intent handler is never invoked). OS Version: iOS 27.0 Xcode Version: Xcode 27.1 (27A9275) Device: iPhone Air Provisioning: Paid Apple Developer Account (Production / TestFlight build) Is this a known system-level bug in AlarmKit where SpringBoard fails to route intent events to third-party apps on real devices? If so, is there any workaround to capture the action of the native Stop/Open buttons, or are developers expected to rely solely on custom Live Activities (.widgetURL) for navigation? Any guidance would be greatly appreciated!

We are building a scheduled-audio app. We need a complete custom recording to start at a scheduled time while the device is locked, play exactly once, and stop automatically without user interaction. The app may be suspended at the scheduled time. Environment: iPhone 11, iOS 26.6.1; Xcode 26.6 with iOS 26.5 SDK; deployment target iOS 26.1. The app was signed for development, installed, and launched without an attached debugger. Alarm authorization was granted. No background audio mode or countdown Live Activity is configured. We bundle a 154.017959-second, mono 44.1 kHz 16-bit PCM CAF in the main bundle. The recording was converted to CAF without trimming. Minimal scheduling code, called after successful authorization (using the generic example filename sample-sound.caf): import ActivityKit import AlarmKit import SwiftUI struct PlaybackMetadata: AlarmMetadata {} @MainActor func schedulePlaybackTest() async throws { let attributes = AlarmAttributes( presentation: AlarmPresentation( alert: .init(title: "Audio playback test") ), metadata: PlaybackMetadata(), tintColor: Color.teal ) let configuration = AlarmManager.AlarmConfiguration.alarm( schedule: .fixed(Date().addingTimeInterval(60)), attributes: attributes, sound: .named("sample-sound.caf") ) _ = try await AlarmManager.shared.schedule(id: UUID(), configuration: configuration) }NSAlarmKitUsageDescription is present in the built Info.plist. Reproduction: schedule, lock the phone before the fire date, then leave it locked and listen through the end. The recording starts automatically and plays completely, but then repeats. This is a single fixed alarm, not a repeating schedule. Questions: Is there a supported public configuration for playing a custom AlarmKit sound once and dismissing/stopping the alarm at end of file? If not, is there an OS-managed maximum alert duration, scheduled stop, or guaranteed callback that can meet this requirement when the app is suspended or terminated? Is unattended play-once-and-stop unsupported with the current public APIs, so that this should be filed as an enhancement request? We understand that postAlert describes a subsequent countdown, and that stop(id:) can be called by executing app code. A foreground timer or a user-triggered stop intent would not meet the requirement. We want an intended public API solution appropriate for App Store distribution.