Overview

I want to connect a BluetoothHFP microphone to MFi hearing aids. Whenever I make the microphone the input it steals the output and whenever I make the MFi the output it steals the input. Is it possible to do this using AVAudioSession? Is it possible to redefine the MFi hearing aids as a speaker and use Live Listen?

See FB22358865. I have a formerly working app. From within the app, Queries to 4 'Record Types' work fine. Queries to one Record Type return only some records. When I 'Query Records' from the CloudKit dashboard I get 100-300 records downloaded for this Record Type. If I repeat 'Query Records' I get an additional 100-300 records. There are more than 4000 records. Apple Developer Technical Support has stated 'the index in your CloudKit container gets in a bad state." How can I fix this?

Our App has a feature that needs to determine if the phone was stationary during the last 10 seconds. For the past several years, we have been using CMMotionActivityManager for this feature and it has worked very reliably. We query motion activity for the past 10 seconds (using queryActivityStarting(from:to:to:) method) and check for any events where the stationary property is false. However, the behavior of CMMotionActivityManager has changed in iOS 16.4 Beta: CMMotionActivityManager no longer reports motion as it did on iOS 16.3 and earlier versions. With iOS 16.4 Beta, CMMotionActivityManager will falsely return events where the stationary property is true (or return no events) even though the phone was in motion during the query interval. There are times when it does return motion events correctly, but that only happens if the phone is in constant motion for a sustained period of time. This behavior is drastically different from previous iOS versions where even the slightest bit of movement would generate motion events. i'm really hoping this is an issue in the beta and will be sorted out soon. Feedback Filed: FB12005598

iPhone 16Pro 512GB..UI FREEZES, HARDWARE CONTINUES

Since the App Store only allows adding one native app, I want to disable my “Mac Catalyst” version app to enable its “Designed for iPad” version. How can I achieve this?

Hi Kevin, I'm starting this new thread to focus on alignment optimization and recalibrating our HBA constraints. Following up on your suggestion about UserReportHBAConstraints and alignment optimization, here are our current DEXT settings: Via UserReportHBAConstraints(): kIOMaximumSegmentCountRead/WriteKey: 129 kIOMaximumSegmentByteCountRead/WriteKey: 65,536 (64 KB) kIOMinimumSegmentAlignmentByteCountKey: 4 bytes kIOMaximumSegmentAddressableBitCountKey: 32 kIOMinimumHBADataAlignmentMaskKey: 0 Via SetProperties() (additional injection): kIOMaximumByteCountRead/WriteKey: 524,288 (512 KB) kIOMaximumBlockCountRead/WriteKey: 1,024 We inherited the segment count (129) and max I/O length (512 KB) from our legacy KEXT, which were originally calculated based on a 4 KB segment size (Max I/O 512 KB / 4 KB + 1 = 129). The current alignment value of 4 was essentially a placeholder, as the legacy hardware didn't enforce strict page-level alignment. Given that our testing is on Apple Silicon, we are considering increasing kIOMinimumSegmentAlignmentByteCountKey to 16,384 (16 KB) to match the native page size. However, I have two specific questions regarding this: Stripe Size vs. Page Size: Our RAID stripe size is typically larger than 16 KB (e.g., 64 KB or 128 KB). Should we be aligning the system to the RAID stripe size for hardware efficiency, or is it more critical to stick to the 16 KB page size to optimize the IOMMU/DART mapping overhead in DriverKit? Recalibration: If we increase the alignment to 16 KB, should we also adjust the kIOMaximumSegmentByteCount to match (i.e., 16 KB), or is it better to keep it at 64 KB to allow fewer, larger segments per I/O? We suspect that the 38% gain we saw in 4 KB Random Reads might improve even further if we fix this alignment bottleneck. Looking forward to your thoughts. Best regards, Charles

Hi, Need some advice on a broken enrollment loop. I registered as an individual in the UK last week. Since enrollment, I have: Day 1: Received the "Your order is being processed" email Day 2: Received the "Review your Apple Developer Program enrollment" email requesting ID verification, and I uploaded my ID as soon as I got the email Day 4: Received an invoice number and "your order has been confirmed" from Apple However, as I log on to developer.apple.com, the website is still stuck saying "To continue your enrollment, complete your purchase now", despite Apple having successfully taken payment from my card and processed the enrollment. If I click it, it attempts to loop me back into a transaction I have already completed. I opened a ticket (Case ID: 102910351530), but got no email response. Attempting to use the phone callback system has been impossible. I have also tried requesting callbacks during their UK (and Ireland) business hours on working days. Every time the system dials my phone, I ended up being placed on hold with the music without anyone actually taking the call. There was once I've even had to endure 4 hours straight on the call before I eventually had to hang up. I completely understand that WWDC is around the corner and support queues are likely heavily backlogged, but the callback loop seems fundamentally broken. A few questions: Is anyone else registering as a developer in the UK / Ireland experiencing the same issue? Is there a path to escalate the issue to human support? Case ID: 102910351530 Any insight or guidance from fellow devs or Apple moderators would be incredibly appreciated. Thank you in advance!

Hello, I started an Apple Developer Program enrollment, but I accidentally entered the wrong name during the process. The enrollment was not completed yet. I would like to know what is the correct way to reset, cancel, or restart the enrollment so I can submit it again with my correct legal name. I already contacted Apple Developer Support, but I have not been able to resolve the issue yet. I would appreciate any guidance on the proper next step. Thank you.

Posting here after a month of going in circles through Developer Support email, in the hope an Apple staff member can review or escalate. Timeline: Individual-to-organization migration submitted for Spentz LLC. Enrollment ID: S4QC6PLPTT. During the migration my active signing certificate was revoked. I have been unable to produce ANY builds (EAS or device) for over 30 days. This is the core blocker. 20 May: advisor confirmed my documents were received and forwarded to the review team, and that the team would contact me directly if anything further were needed. Nothing further was requested. 29 May: automated email warning the enrollment would be withdrawn within 7 days if requested info wasn't received but no email has ever specified what is outstanding or where to send it. This directly contradicts the 20 May confirmation. Callback requested only to be left on hold for over an hour before giving up What I'm trying to resolve: (1) confirmation of whether anything is genuinely outstanding from my side and, if so, what and where to send it; (2) assurance the withdrawal timer won't fire while my documents are confirmed with the review team. If any Apple staff can look at S4QC6PLPTT, I'd be grateful. Happy to provide anything needed. This is the sole blocker on a scheduled launch. Topic: Developer Tools & Services SubTopic: Apple Developer Program

Our application currently uses Sign in with Apple through Microsoft Entra ID (B2C) rather than a direct integration with Apple's Authentication Services framework. We understand the requirement that users should not be asked to provide information that is already supplied by Sign in with Apple. However, in our current implementation, Microsoft Entra ID (B2C) does not provide the user's name details to our application, and as a result we are unable to access this information after authentication. Could you please provide guidance on how to satisfy this requirement when Sign in with Apple is configured through Microsoft Entra ID (B2C)? Specifically, we would appreciate clarification on whether there is an Apple-approved approach for obtaining the user's name in this federated authentication scenario without requiring the user to re-enter information. Apple rejected my app with these reasons "Issue Description The app offers Sign in with Apple as a login option but does not follow the design and user experience requirements for Sign in with Apple. Specifically: The app requires users to provide their name and/or email address after using Sign in with Apple. This information is already provided by the Authentication Services framework. These requirements provide the consistent experience users expect when using Sign In with Apple to authenticate or log in to an account. Next Steps Please revise the Sign in with Apple experience in the app to address the issues we identified above. Resources To learn more about App Store design requirements, see guideline 4. For an overview of design and formatting recommendations for Sign in with Apple, review the Human Interface Guidelines."

To gain exclusive access to keyboard HID devices like Amazon Fire Bluetooth remote controls, my app has been installing a privileged helper tool with SMJobBless in the past. The app - which also has Accessibility permissions - then invoked and communicated with that helper tool through XPC. Now I'm looking into replacing that with a daemon installed through the newer SMAppService APIs, but running into a permission problem: If I try to exclusively open a keyboard HID device from the SMAppService-registered XPC service/daemon (which runs as root as seen in Activity Monitor), IOHIDDeviceOpen returns kIOReturnNotPermitted. I've spent many hours now trying to get it to work, but so far didn't find a solution. Could it be that XPC services registered as a daemon through SMAppService do not inherit the TCC permissions from the invoking process (here: Accessibility permissions) - and the exclusive IOHIDDeviceOpen therefore fails?

I have created a cute watchOS virtual pet. It is "Made for Kids" and allows no external links/communication without a math gate in either the iOS companion or the main watchOS app. Customers have requested the ability to share their pet with their friends, and to be able to see their friends pets alongside their own in the both apps. Is this acceptable under "Made for Kids", as long as I use DeclaredAgeRange and PermissionKit for non adult users prior to allowing them to share or receive a share? As this is quite a complex feature I don't want to start it without an idea of how likely an update to be accepted. If this is not acceptable, is the solution to remove "Made for Kids" and increase the age rating?

Hello, I submitted my Apple Developer Program enrollment as an organization on 05/26/2026. My enrollment has been stuck in "In Review" status for approximately two weeks with no updates, no request for additional documentation, and no phone verification call. Enrollment details: D-U-N-S Number: 582645157 Country: Brazil Apple ID has 2FA enabled Work email on custom business domain Website publicly available Enrollment ID: Z9LB3C94GF I am the legal representative authorized to bind the company to Apple agreements. I have already contacted support through the developer contact page with no response. Could an Apple team member please review my enrollment and advise on what may be holding the process? Happy to provide any additional documentation needed. Thank you.

Hello App Review Team, Our app submission has been stuck in the “Waiting for Review” status for an extended period, and we would like to kindly ask whether there is any issue or additional action required from our side. We have already uploaded the latest build and verified the In-App Purchase configuration in App Store Connect. Since the status has not changed, we wanted to check if the submission queue is functioning normally or if there is anything preventing the review from starting. We would appreciate any clarification or guidance you can provide. Submission ID: 85a6b879-5218-4f2c-b444-de09d148268e Apple ID: 6766198981 Best regards, Mert Akgün

Dear Apple Developer Support Team,I am writing to respectfully draw your attention to a persistent technical bottleneck regarding the review status of our app, "未来洞-游戏搭档：专业指导，高效冲分" (Apple ID: 6756904154, Version 2.0.0)。 Currently, this version has been stuck in the "Waiting for Review" status for 13 consecutive days without any status migration or progress。 We completely understand and deeply respect that the App Store maintains a rigorous evaluation process to ensure user safety and quality.As a dedicated developer team striving for long-term and compliant operation, we noticed a consistent pattern in our previous submissions: each of our last three updates spent more than 20 days in the "Waiting for Review" stage, but once they moved to "In Review," the evaluation was successfully completed within a single day.This contrast encourages us that our application codebase, metadata, and in-app purchases (IAP) are fully aligned with the App Store Review Guidelines. We would also like to sincerely reassure your team that our app 100% strictly utilizes Apple's native IAP for all digital transactions, with absolutely no third-party payment frameworks or external billing methods.While we patiently appreciate your standard evaluation pipeline, waiting over 20 days for the system to assign a reviewer for each update has posed significant operational challenges for our scheduled marketing events, causing severe financial and operational distress to our small team. Therefore, we kindly request your technical intervention with the following: 1:Technical Pipeline Reset: We would be deeply grateful if a support engineering representative could look into our account backend to check if our queue is frozen, and help manually reset or refresh the dispatch status of this version. 2:Information Verification: Please let us know if any additional clarification, video demonstrations of our core features, or documentation is needed. We are fully prepared to cooperate and provide it immediately。 3:Root Cause Feedback: If there are any specific compliance parameters or meta-settings on our end causing this systematic 20-day queue delay, please advise so we can correct it permanently。 We greatly appreciate your time, professional understanding, and assistance in resolving this critical systemic bottleneck. Best regards, Contact Name: [阳 春 / Chun Yang]Apple ID / App ID: 6756904154

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Hello, I’m posting again because our previous forum post received the following Apple Staff reply: “Thank you for your post. We're investigating and will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us.” However, the issue has not been resolved yet. We have not received any separate contact in App Store Connect, the Resolution Center, or email. We currently have two active apps in the same developer account that are stuck in Waiting for Review. Because multiple apps in the same account are affected at the same time, this seems like it may be an account-level App Review queue or routing issue rather than an individual app binary issue. For one of the affected apps: App ID: 6760743106 Review submission ID: 6950ecff-f833-404d-b04b-ac34ec552b85 Submitted: June 1, 2026 Review submission state: WAITING_FOR_REVIEW Review submission item state: READY_FOR_REVIEW App Store version state: WAITING_FOR_REVIEW Build processing state: VALID Build audience type: APP_STORE_ELIGIBLE Build expired: false TestFlight installation works normally, and there is no Resolution Center message. We are also unable to submit an expedited review request because the expedited review form itself fails. After selecting the correct app and platform, the form sends a POST request and receives HTTP 200 OK, but the response page displays: “Sorry, we didn’t receive your request. An error has occurred and your submission wasn’t completed. Please go back and try again. If you continue to have issues, contact us.” The POST payload includes the correct app ID and platform: expedite_app_id_req: 6760743106 expedite_app_platform: ios Could Apple Staff please check whether our developer account or these submissions are affected by an internal App Review queue/routing issue? We are currently blocked because the review has not started for multiple apps, we have not received any follow-up contact, and the expedited review request form cannot be submitted.

libquic.dylib crashes with a null/invalid buffer access in nw_protocol_data_access_buffer during QUIC connection path migration on iOS 26. App code is not in the stack — this is entirely within Apple system libraries. We are seeing a consistent crash on iOS 26 that does not reproduce on iOS 17 or iOS 18. The crash occurs on a background thread ("com.apple.network.connections") with no application code in the crashed thread's stack. The crash trace begins in quic_migration_probe_path and terminates in nw_protocol_data_access_buffer + 180, suggesting a use-after-free or buffer lifetime violation during QUIC connection path migration (e.g., Wi-Fi ↔ Cellular handoff). This crash does not appear to be reproducible on demand — it correlates with network path transitions while QUIC connections are active. Our app uses standard URLSession with default/ephemeral session configurations and does not explicitly enable HTTP/3; iOS 26 is automatically upgrading eligible connections. Crash thread (abbreviated): 0 libquic.dylib quic_conn_send_packet + 144 1 libquic.dylib quic_conn_continue_sending + 424 2 libquic.dylib __quic_conn_send_frames_for_key_state_block_invoke_2 + 1244 3 Network nw_protocol_data_access_buffer + 180 ← crash 4 Network nw_protocol_data_copy_buffer 5 Network nw_endpoint_flow_output_frames 6 libquic.dylib quic_conn_send_frames_for_key_state 7 libquic.dylib quic_conn_send_frames 8 libquic.dylib quic_migration_probe_path + 1464 9 libquic.dylib quic_migration_path_established + 2608 10 libquic.dylib __quic_migration_path_event_block_invoke.21 11 libquic.dylib quic_migration_path_event 12 Network nw_protocol_implementation_connected There is no app code in the crashed thread. This is a regression introduced in iOS 26, where libquic.dylib was separated into its own dynamic library and new path migration probe logic was introduced.

App: TokPass English (Education category) Bundle ID: com.tokpass.app Apple ID: 6762091232 Case Number: 102871336704 Timeline: Version 1.2: Stuck in "Waiting for Review" for 8 days across 5 attempts (May 1-5) Version 1.3 submitted: May 13 Expedited review approved by Developer Support Status changed to "In Review" - has now been there for 26 days with no movement TestFlight External Review also stuck since May 22 What I've already done: Multiple expedited review requests (one approved) Multiple Developer Support contacts (phone and email) All responses have been generic auto-replies This is a live app (v1.1 currently available) and the update contains critical bug fixes. Users are affected. Has anyone seen "In Review" stuck this long, and is there any escalation path beyond standard Developer Support?

Recently, I am developing an app based on user health data tracking, which involves a scenario where a user wears multiple electronic watches. In this case, I need to distinguish the data sources to prevent the data from not being correctly distinguished when the user wears multiple watches. Currently, bundle identifier seems to be a great choice for me, but after trying to read the materials, it seems that after unbinding, I rebind it. Alternatively, rebinding on another phone would cause this parameter to change. Do you have any better ideas?