Dear Apple Team,​ We are reaching out regarding several compatibility issues our app users have encountered after upgrading to iOS 26. These issues not only affect our application but also seem to impact the system's native settings, which has raised concerns about the universality of these problems.​ Problem Description​ Bluetooth Functionality: When users attempt to use the Bluetooth feature within our app after upgrading to iOS 26, the app freezes completely. What's more, when accessing the Bluetooth section in the system Settings app, it also freezes and ultimately crashes.​ Location Service: The location service on the device becomes inoperable after the iOS 26 upgrade. However, both the Bluetooth and location service issues are resolved after the user restarts the device.​ 2. Questions​ Universality: We are eager to know if these issues are exclusive to our app or are a more widespread problem among other applications on iOS 26. Are these known compatibility glitches in iOS 26? ​ Avoidance: Is there any guidance or best - practice that we, as developers, can follow to avoid these issues in our app? For example, are there specific API calls or configurations that need to be adjusted? ​ System - level Impact: If these are system - level bugs related to Bluetooth and location services, will they affect all apps that rely on these features? Or are there certain app - level mitigations that can be implemented? ​ We would greatly appreciate it if you could provide us with any insights, solutions, or information regarding these issues. Your prompt response will be crucial for us to address these problems and ensure a smooth user experience for our customers.​ Thank you in advance for your assistance.​ Best regards,

countries within one region Dear Apple Developer Team, We intend to launch our Avatr app for different countries in the same region. In consideration of local legislation and approved local cloud‑service providers, each build contains region‑specific configurations, slight code adjustments and connects to country‑exclusive backend services accordingly. The core business code remains consistent. We strictly limit app distribution scopes. Users from one country can only access the version released for their market, and duplicate apps will never show up within a single App‑Store territory. Our main concern: Would this release arrangement lead to rejection per App Store Guideline 4.3‑Spam? Kindly inform us if we need to provide extra supporting documents. Best regards, Avatr iOS Team

Dear Apple team, we have confusion about the test method for the specification that beacon-to-beacon transmit power average variation shall stay within ±5dB compared with the golden device. Could you kindly clarify the definition of the golden device, whether we should measure conducted or radiated Tx power, the averaging rule over advertising channels, required test sample quantity and environmental test conditions, and confirm if the ±5dB tolerance applies to each individual beacon’s average transmit power?

Our vehicle digital key app uses CBCentralManagerOptionRestoreIdentifierKey and bluetooth-central background mode to maintain BLE connections with cars. We want to confirm: if the app is actively connected to a BLE vehicle peripheral and then terminated by system memory reclamation (not user force-quit), will iOS automatically relaunch the app via Bluetooth State Restoration when the peripheral sends notifications or re-advertises? Also please list all mandatory conditions to trigger such Bluetooth-based background relaunch after system termination, and clarify whether this pure-BLE relaunch channel works independently apart from iBeacon location-triggered cold launch for our terminated app on iOS 26 without AccessorySetupKit. Best regards

We are conducting iBeacon compliance testing for our device and would like to clarify two test items from the iBeacon test specification: Regarding Tx power stability verification over time and across different battery capacities: Could you please specify the required test duration and the exact test procedure? Specifically, how long should the Tx power be monitored to verify stability within the 2dB standard deviation requirement, and what battery capacity levels (e.g., 100%, 50%, 20%, low battery threshold) should be tested? Regarding device interoperability with iOS CoreLocation APIs for beacon-based region monitoring and ranging: Could you please provide guidance on the test methodology? Specifically, what test cases, expected behaviors, and pass/fail criteria should we follow to verify correct interoperability with region monitoring (didEnter/didExit) and ranging (didRangeBeacons) APIs? Any official test guidelines or reference documents would be greatly appreciated.

Our current business goal is to improve the success rate of iBeacon wake-up on iOS. Apple's official iBeacon specification recommends a standard broadcast interval of 100ms; Now we are planning to shorten the broadcast frequency to 50ms, and we would like to consult the full dimensional impact of this change, and whether it can really improve the success rate of beacon identification and pull trigger on iOS devices.

We're using the iOS ibeacon APIs to wake up our app for vehicle bluetooth key and to enable the seamless walk-away features; Does the Measured Power value in the advertising packet affect an app’s background launch? If so, what is the mechanism? If not, what is the actual purpose of this field in Core Location? For different beacon devices/vehicle models, does this value need to be adjusted? For example, we have different vehicle models – should each model set this value based on actual calibration data? Our current understanding: Measured Power is typically used for our APP to do the distance estimation but we are not sure whether the system also uses it as a weighting factor for background wake‑ups or region triggers. We have noticed some discussions in forums about similar scenarios where it is mentioned that Measured Power needs to be set correctly.

Hello, I would like to consult Apple’s technical team regarding how different iBeacon Bluetooth advertising packet configurations impact iOS app background wake-up performance. My specific questions are outlined below: We have two available iBeacon advertising configuration schemes: Scheme 1: Encapsulate the non-connectable iBeacon advertising payload and connectable Bluetooth advertising payload into a single advertising packet for transmission. Scheme 2: Split the two types of advertising payloads above into two separate independent advertising packets and broadcast them respectively. Could you please clarify which packet format enables iOS apps to detect and recognize iBeacon devices more reliably and easily, thereby triggering app background wake-up more effectively? I would appreciate it if you could explain the differences, advantages and disadvantages of these two schemes under iOS’s Bluetooth scanning and app wake-up mechanisms, as well as provide your official recommendations. Thank you very much for your assistance.

We currently have the need to develop Smart Island. We need to identify whether the current mobile phone supports Smart Island. At present, the solution we can think of is to maintain a model list if the current phone is in the white list, it supports Smart Island. But we think this method is not good enough. Is there a better solution to support identification? In addition, will the later models support smart Island?

Our APP has integrated 3D function, in order to reduce the memory occupation of the APP in the background, we will uninstall the 3D after the APP enters the background. However, the uninstall also causes problems. When the uninstall process is executed in the background, the app will briefly trigger the background GPU rendering error warning with the error warning code: OGPUMetalError: Insufficient Permission (to submit GPU work from background) (00000006:kIOGPUCommandBufferCallbackErrorBackgroundExecutionNotPermitted) Execution of the command buffer was aborted due to an error during execution. Insufficient Permission (to submit GPU Work from background) (00000006: kIOGPUCommandBufferCallbackErrorBackgroundExecutionNotPermitted) excuse me this warning system will tighten APP permissions background?​ For example, limit or shorten the background survival time of the APP. In addition, will the background refresh function fail, resulting in the failure of Bluetooth Ibeacon activation?

We have recently developed the iwatch app. We will package the APP + iwatch app and publish it in testfight for test download. However, we often find that after the mobile app is downloaded, the iwatch app is also on the iwatch System application inside display. Click install is always in the installation. It has not been installed. Especially when the phone we tested is paired with several watches. Or delete the mobile APP and download it again to recover. But some situations still cannot be recovered. May I ask why it is always installed? We have confirmed that there is no problem with the network, and the pairing connection between the watch and the mobile phone is normal. This problem has caused us a lot of trouble. I wonder if this will happen in the app store. Please give the official reply

I have the following questions that need official answers: 1: Whether the Bluetooth scanning cycle can be controlled through the software level. If it can be controlled, please tell me how to control it. 2: Now the IOS mobile phone scanning strategy, how long is the scanning cycle, and what is the scanning duty cycle in this scanning cycle