An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

Hello everyone, I would like to ask whether other developers are currently experiencing unusually long App Review delays for new apps. Here is the timeline for my app (Apple ID: 6759361892): Build 1 — Feb 19, 2026: Initial build submitted Feb 21, 2026: Rejected because ads were not working properly Build 2 — Feb 23, 2026: Updated build submitted Build 3 — Feb 26, 2026: Another updated build submitted Mar 11–18, 2026: Status remained “Waiting for Review” and never entered the “In Review” stage Mar 18, 2026: Submission cancelled and resubmitted Current status: Still “Waiting for Review” During this period, I have already tried several ways to resolve the issue: Contacted Apple Developer Support multiple times Submitted an expedited review request Sent several follow-up emails regarding the delay Contacted Apple Support and asked them to leave messages for the App Review team Each time, I was told that the situation would be checked or that the review would “begin shortly.” I have now received that same response multiple times, including after my expedited review request was accepted, but there has still been no visible progress or transition into active review. While browsing the Developer Forums, I also noticed that several recent posts seem to describe similar situations, especially involving new app submissions remaining stuck in “Waiting for Review.” So I would like to ask: Are other developers currently experiencing similar delays? Has anyone recently seen their app finally move from “Waiting for Review” to “In Review” after a very long delay? Could this possibly be related to a broader App Review queue slowdown? I’m mainly trying to understand whether this is an isolated issue or something other developers are also currently facing. Any recent experiences or information would be greatly appreciated. Thank you.

Dear App Review Team, I am writing to follow up again regarding our app review, which has now been pending for over 20 days. App ID: 6705133649 Status: Waiting for Review since April 30, 2026 Despite previous communication indicating that the issue was being investigated and that we would be contacted via App Store Connect, we have still not received any update or outreach. To summarize: April 30 – Submitted for review May 5 – Apple responded that the issue is under investigation Multiple follow-ups since then Today – Over 20 days with no progress, no communication This ongoing delay is significantly impacting our users and business operations. Given that our app reviews were previously completed within 24–48 hours, and considering the extended delay in our last submission as well, we are concerned that there may be an underlying issue affecting our account or app. We kindly request: Immediate escalation to a senior App Review team member A clear explanation for the delay Confirmation if any action is required from our side An estimated timeline for resolution We are fully available to provide any additional information, demo credentials, or clarification needed, and will respond promptly to any requests. We respectfully request that this matter be treated as urgent. Thank you for your attention. Best regards, Bishwajit

My app has been stuck in “Processing for Distribution” for several days. The version was approved, but it never fully completed the distribution process. In App Store Connect, I cannot create a new version because the “+” button is missing. I also cannot submit a new build, update metadata, or cancel the current process. The release pipeline is completely blocked on my side. I contacted Apple Developer Support, and the issue has been escalated to the engineering team under an internal engineering ticket. However, I am still waiting and there is no action available to me in App Store Connect. Has anyone experienced this exact issue before? If so, how long did it take Apple engineering to reset or unblock the app version state?

Hello, I'm posting again — and unfortunately, I already know how this thread is going to go. My app (ID: 6756186616) has now been stuck in "In Review" for 80 days. To save everyone time, here is the reply I expect to receive within a day or two, copy-pasted from the response on my last thread: "Thank you for your post. We're investigating and The App Review team will contact you in App Store Connect to provide further assistance. If you continue to experience issues during review, please contact us." Nothing actually happened after that reply last time. No follow-up in App Store Connect. No further communication. Just silence. When I escalated to Developer Support (case #20000111565861), I was told explicitly that Developer Support has no way to reach the App Review team and no authority to intervene on submissions stuck in review. So Developer Support points back to App Review, and the standard forum reply points back to "contact us" — which loops back to Developer Support. This is a closed loop that doesn't actually resolve anything for an independent developer. Concrete questions: Is there any real escalation path that doesn't end in an automated reply? Why has a submission been "In Review" for 80 days with zero communication? What should a solo developer do when both Developer Support and the forum response are dead ends? I'm not asking for special treatment. I'm asking for the review to actually move — in either direction. A rejection with feedback would be infinitely more useful than 80 days of silence. Thank you.

This is my first time submitting an app for review. I'm unable to submit my iOS app for review due to a persistent 409 error when trying to attach a build to my App Store version record. This has been happening across multiple builds and version strings. { "errors": [{ "id": "80550434-590c-48c6-b2d3-5bd3b038539b", "status": "409", "code": "ENTITY_ERROR.RELATIONSHIP.INVALID", "title": "The provided entity includes a relationship with an invalid value", "detail": "The specified pre-release build could not be added.", "source": { "pointer": "/data/relationships/build" } }] } What I've tried: • Submitted build 34 (version 1.0) — same 409 error • Incremented to build 35, version 1.0.1 — same 409 error • Removed the build from the version page and re-added it — same error Environment: • Xcode 16 • iOS deployment target: 17.0 • Builds processed successfully in TestFlight (status: Ready to Submit) • Version record ID: 198605a5​-2671​-44d6​-bacb​-04157088319d Question: Has anyone encountered this? Is the version record itself corrupted/stuck? The builds show as valid in TestFlight but cannot be attached to the App Store version.

Hi all, We are developing an iOS app that includes private user-to-user chats, commercial offer details with monetary value, and customer identification data. In line with OWASP MASVS-PLATFORM-3 requirements regarding unintentional sensitive data exposure, we need to protect these specific screens from screenshots and screen recording. We have carefully reviewed the relevant App Review Guidelines (2.5.1 on public APIs, 2.5.2 on self-contained bundles, 5.1.1 on privacy) and the related Human Interface Guidelines. From this analysis we have observed the following: iOS does not expose a public API to globally disable screen capture (no direct equivalent of Android's FLAG_SECURE). The SwiftUI .privacySensitive() modifier is effective for Lock Screen widgets and Always-On Display, but it does not appear to prevent screenshots or screen recording of an app's main UI while in the foreground. A number of widely distributed App Store apps (banking, authenticator, secure messaging) implement some form of screenshot protection on sensitive screens. Several established open-source libraries leverage the system behavior of UITextField with isSecureTextEntry as a wrapping container for arbitrary views, in order to achieve pixel-level protection for sensitive content. We would appreciate clarification on the following points: For privacy-driven protection of sensitive screens (private chats, customer data, monetized offers), is there an officially recommended approach we may have missed? Are there public APIs intended specifically for this use case beyond .privacySensitive()? Is the practice of leveraging UITextField with isSecureTextEntry as a wrapping container for arbitrary views considered an acceptable use of public APIs under Guideline 2.5.1, or does it carry App Review risk? Are there official recommendations or documentation for apps handling sensitive personal data that wish to align with industry standards such as OWASP MASVS-PLATFORM-3 for screenshot and screen recording leakage prevention? The intended use is strictly limited to a small number of screens marked as containing sensitive data (private messages, deal details, customer information). The protection would be selective and clearly communicated to the user via in-app messaging, not global to the app. Thanks in advance for any clarification, including pointers to existing documentation or threads we may have missed. Deployment target: iOS 15+

Dear forum, I would love your help with this issue or if anyone ever experienced this. I'm working on an app. weeks and weeks of work and dedication, testing endlessly with users, perfecting my app, just to get rejected for - "The usefulness of the app is limited by the minimal functionality". it's the 2nd time it happens. insulting it is, i'm trying to put my feelings aside and solve the problem. apple reviewer's are using IPad to check my Iphone only apps, claiming their not useful, non Hebrew speakers (app is in Hebrew) are checking my app and telling me it's not useful without even understanding it's purpose. when i've uploaded the app apple reviewer responded after less then a minute, not even enough time to read all the materials I've uploaded for the app or wating for it to do it's thing (daily updates), no question was asked or a discussion was made, just one insulting line. i'm super frustrated, i've paid for the developer program just to get the most horrible service. Did anyone deal with that? solved it? have any ideas? I would love your help. Thanks :) Or

Hello App Review Team, I'd like to ask for guidance on an update that has been stuck in "Waiting for Review" longer than expected. SUBMISSION DETAILS App name: RhumArrangé App ID: 6767041700 Bundle ID: com.maximesaltet.rhumarrange Version: 1.2 (Build 8) Platform: iOS Submitted: 2026-05-14 Current status: Waiting for Review (5 days, as of 2026-05-19) Submission ID: 5d69e9ee-cb48-4218-9404-c171a252a5d5 Version ID: cc12db07-3303-49c9-b22e-0cfd73fad082 CONTEXT Previous versions (1.0 and 1.1) were reviewed and approved within 24–48 hours. Version 1.2 contains critical bug fixes for users already running the app in production (no new functionality, no policy-relevant changes). An Expedited Review request was filed but no action has been taken. App account is in good standing, all agreements are accepted. No messages in Resolution Center, no Missing Information state, no metadata rejection — the submission appears to simply not be picked up from the queue. WHAT I'M ASKING Could someone from App Review verify whether this submission is routed normally, or whether it is technically stuck in the queue? I am not asking for special treatment — I just want to confirm there is no backend issue or hidden flag preventing the review from starting, so that the bug fixes can reach the existing user base. Thank you for your time and help.

Hello Apple Developer Relations / App Review Team, Our first app release has been pending review significantly longer than expected, and we urgently need assistance. We had a coordinated marketing launch scheduled yesterday based on the standard review timelines communicated in App Store Connect. The delay is now impacting launch commitments, marketing campaigns, and user onboarding plans. Current status: First app submission Build status: waiting for review No messages or requests received in Resolution Center App is fully tested and production ready We respectfully request assistance or escalation for an expedited review if possible. We understand review times can vary, but we would sincerely appreciate any help or visibility into the current delay. App name: LiveVibe App ID: 6767975462 Thank you very much for your time and support.

Hello, Our app VIOO has been in "In Review" status for 15 days as of today (May 19, 2026), with no communication from the App Review team. Submission details: App name: VIOO Version: 1.0.0 (build 14) Bundle ID: com.vioo.klient Submission ID: eac3a31c-f8cc-47f2-afea-f41e00df3079 Date submitted: May 4, 2026 at 22:38 CEST Team: EcoMotionDrive Sp. z o.o. This is our initial submission (version 1.0). There are no messages in App Review or Resolution Center. We have not been contacted by a reviewer. We are preparing a public launch of our ride-hailing service in Białystok, Poland, scheduled for May 2026. The extended review period is blocking our launch coordination across iOS, Android, marketing, and B2B contracts. I have just submitted an expedited review request through the official form. Posting here in parallel as recommended by other developers experiencing similar delays. Any guidance or escalation assistance would be greatly appreciated. Thank you, Kamil Laskowski CEO, EcoMotionDrive Sp. z o.o.

My app has been stuck in “Waiting for Review” for a very long time and I’m honestly getting really frustrated. I already fixed all previous issues and submitted everything properly, but there has been no update at all. This delay is seriously affecting my launch plans and business operations. I understand reviews can take time, but the waiting period feels unusually long compared to my previous submissions. Has anyone else experienced this recently? Is there anything I can do to speed up the review process or get an update from Apple? I’d really appreciate any advice or shared experiences. Thank you.

Hello, I honestly don’t understand what’s going on with my app review. My app was already approved before, and I submitted a new build on April 7th with some new features and important bug fixes. Since then, it has been stuck on “Waiting for Review” with absolutely no update. It’s been 40 days now, which is honestly unacceptable. I even submitted an expedited review request, but that didn’t help either. The worst part is that this build contains bug fixes for users, and the delay is directly affecting the app experience. Waiting this long without any response or progress is really frustrating. Can someone from Apple please look into this and help resolve it ASAP? Thank you.

Hello Apple Review Team, Our app (Apple ID: 6758392381) has been stuck in “Waiting for Review” for the past 6 days. We have already contacted Apple Support and also submitted an Expedited Review Request, but unfortunately we haven’t received any response or update yet. This delay is affecting our release timeline, and we would really appreciate any guidance regarding the current status of the review. Could you please let us know: If any additional information or documentation is required from our side? If there is any issue or blocker causing the delay? We are ready to provide any details or make any necessary changes immediately. Thank you.

I have two auto-renewable subscriptions (RedBird.Monthly and RedBird.yearly) that have been stuck in "Waiting for Review" status through 4 separate app version submissions and approvals. Each time I submit a new app version, the app itself gets approved and released, but the subscriptions remain in "Waiting for Review" and are never reviewed alongside it. I have: Added screenshots to both subscriptions under Review Information Filled in all required localization fields Submitted the app with a build attached each time Tried clicking "Submit for Review" on each subscription individually The subscriptions are part of a subscription group called "RedBird Premium." The app is a Capacitor-based iOS app (com.redbird.wellness). Has anyone experienced this? Is there a specific step required to explicitly link subscriptions to an app version submission in the current App Store Connect UI? The "In-App Purchases and Subscriptions" section described in Apple's documentation does not appear on my version page. Any help appreciated.

Dear App Review Team, We would like to kindly follow up regarding our app submission, which has been in “Waiting for Review” status since Apr 10, 2026, with no progress update to date. We have also submitted 3 expedited review requests, plus 2 support requests email but unfortunately have not received any response yet. This prolonged delay is now significantly impacting our project timeline and scheduled deployment commitments. We understand review times can vary, but it has now been over a month without movement or communication. App ID: 6752937247

Dear App Review Team, I hope you are doing well. I am writing regarding our game My Garage Story (App ID: 6762339825), which has been stuck in the “Waiting for Review” status for a very long time. My Case ID is 102886678091. I have already contacted support multiple times regarding this issue, but unfortunately, we have not received a proper resolution or update yet. It has now been almost 3 weeks, and we kindly request that this matter be treated with priority and resolved as soon as possible. We currently have the game available for pre-order in the US region, and we are eagerly waiting for the review approval so we can officially launch it for iOS users. Our next build is also ready with further polish, optimizations, and bug fixes. Additionally, the same game is already live on Google Play under a changed title and the same developer account. For your reference, I am sharing the Android version link below: https://play.google.com/store/apps/details?id=com.playspare.mycardealershipsimulator We also have an active Discord community of around 400K members who have been waiting for the iOS release for quite some time. Due to the current delay, our iOS launch plans are being heavily impacted. We kindly request you once again to please review this case seriously and help us get the app into review and approved as soon as possible. Thank you for your time and support. We look forward to your response.

Hi App Review Team, My app Fluto AI: Anime & Art Painter (Apple ID: 6762746586) has been in "Waiting for Review" for 17 days with no update. Quick timeline: the app was previously approved but unpublished. After minor changes I resubmitted, it was rejected and a demo video was requested. I added the public video URL to App Review Notes and resubmitted. Since then, no movement, no messages in Resolution Center, no response to my support case or expedited review request. Could someone please confirm if there's a blocker or any additional information needed? Happy to provide anything immediately. Thank you.

Hello, Our iOS app “DOITDO” has been stuck in “Waiting for Review” since April 29, 2026, and it has not entered the “In Review” stage yet. This is the first App Store review submission for this app. Timeline: April 29, 2026: Submitted version 1.0.0 for App Review May 6, 2026: Submitted an expedited review request because the app had already been waiting for 7 days May 15, 2026: Apple Developer Support confirmed that the expedited review request was accepted and said the review should begin shortly May 19, 2026 KST / May 18, 2026 Pacific Time: The app is still in “Waiting for Review” with no status change App details: App Name: DOITDO Platform: iOS Version/Build: 1.0.0 Bundle ID: com.d107.doitdo Original Submission Date: April 29, 2026 Current Status: Waiting for Review We have checked the required review information, including the demo account, backend availability, and review notes. We do not see any pending action, rejection, metadata rejection, or request for additional information. At this point, the delay appears to be far outside a reasonable review timeframe, especially because the expedited review request was already accepted several days ago. The app has now been waiting for approximately 20 days since the original submission without entering review. We understand that expedited reviews cannot be guaranteed. However, we are not submitting a new expedited review request. We are asking whether Apple can investigate why this already-accepted expedited review has not moved forward. Could someone from Apple please check whether there is any blocker, queue issue, compliance issue, account issue, or missing information preventing the review from starting? If there is no blocking issue on our side, we would greatly appreciate it if this could be escalated to the appropriate App Review team so the review can begin as soon as possible. Thank you.

Hi Apple Developer community and Apple Review team, I'm hoping to get assistance with a persistent 4.3(a) rejection for our app ByGate (net.bygate.vpn). Submission ID: c8278a90-8e90-45b2-9256-d2e6b34e9518 Latest review date: May 19, 2026 Our situation: ByGate is not a generic VPN tool. It is a dedicated client application for ByGate's proprietary server infrastructure. The app works exclusively with ByGate servers - users cannot enter custom addresses, import third-party configurations, or connect to any other provider. It is functionally similar to a banking app or a streaming app: it only connects to one specific service. We have been operating ByGate as a cross-platform service: Android app live on Google Play Windows desktop app distributed via our website macOS desktop app distributed via our website Active paying subscriber base across all platforms Our existing users regularly contact our support team asking when the iOS version will be available. They are already using our servers and subscriptions on other devices and want the same experience on iPhone. Why we believe the rejection doesn't apply: Apple's own guidelines (4.8) recognize "apps that are a client for a specific third-party service" as a distinct, legitimate category. ByGate fits this exactly - the same way Netflix, Spotify, or any banking app is a dedicated client for one specific service. The concern about "similar binary" is understandable - like many VPN apps, we use an open-source networking library. But using a shared networking library (like WireGuard, OpenVPN, or in our case libbox) does not make an app conceptually identical to others, just as using SQLite doesn't make a database-backed app a duplicate of every other such app. Unique features of ByGate not found in other apps on the App Store: Split tunneling mode specifically pre-configured for Russian-language internet services Anonymous account creation (no email or phone number required) Freemium model with 100 MB free tier, no registration required Access exclusively to ByGate's own server nodes in Europe and USA Our 24/7 support on Russian-language We have responded to every rejection with detailed explanations, but receive only the standard templated response. We are genuinely committed to compliance and would welcome direct guidance on what specifically needs to change, or a review call with the App Review team. Thank you for your time.

I'm building a custom keyboard extension that offers voice dictation. Because keyboard extensions are constrained (memory cap ~30–48 MB, restricted audio session access), I delegate recording to my container app: User in a host app (e.g., Safari) taps the mic in my keyboard extension. The keyboard calls extensionContext.open(URL("myapp://dictation")) to launch the container app. The container app records audio via AVAudioEngine + SFSpeechRecognizer, writes the final transcript to the App Group, and signals completion via a Darwin notification. 4. The user is expected to be returned to the original host app (Safari) automatically so they can keep typing. The problem (step 4): On iOS 26.4 I can no longer identify which app was the host. Every previously-known path returns nil for the keyboard extension's host: parent.value(forKey: "_hostBundleID") → returns the literal string parent.value(forKey: "_hostApplicationBundleIdentifier") → returns NSNull xpc_connection_copy_bundle_id on the underlying XPC connection (via PKService.defaultService.personalities[…]) → returns NULL NSXPCConnection.processBundleIdentifier on extensionContext._extensionHostProxy._connection → returns nil proc_pidpath(hostPID, …) → EPERM from the keyboard sandbox LSApplicationWorkspace.frontmostApplication → selector unavailable from the extension RBSProcessHandle.handleForIdentifier:error: → returns an RBSServiceErrorDomain error Without the host's bundle ID, the container app has no way to call LSApplicationWorkspace.openApplicationWithBundleID: (the technique that worked on iOS 25 and earlier). UIApplication.suspend() correctly sends the container to background, but iOS treats us as a "fresh launch" — it returns the user to the Home Screen instead of Safari, because the container app was launched by an extension, not directly by Safari. KeyboardKit's maintainer reached the same conclusion (issue #1014) and shipped 10.4 without the feature. My questions: Is there a public, App-Store-safe API in iOS 26+ for a custom keyboard extension to identify its host application, or for the container app (launched via the extension's openURL) to identify which app initially hosted the extension that opened it? UIOpenURLContext.options.sourceApplication reports the extension's own container, not the actual host. 2. Is there a public mechanism for "return to source app" when the container app was launched by an extension's openURL? Equivalent to the ← Source affordance iOS shows for normal inter-app openURL, but triggered programmatically by the launched app. 3. Some popular keyboards (e.g., 微信输入法 / WeChat Keyboard) still appear to round-trip through their container app on iOS 26.4 and return the user to the original host — including the iOS ← WeChat back affordance in the host's status bar afterward. What's the recommended approach to achieve this? If it requires a specific scene-activation flow, NSUserActivity pattern, or extension-context configuration, please point at the relevant docs. 4. If there is no public path today, is FB22247647 (or a related radar) the right place to track this? Should developers in this position migrate to in-extension audio capture (which has its own significant constraints in keyboard extensions)? I'd much rather not rely on private APIs. Concrete guidance — or even an acknowledgment of which direction Apple intends — would help thousands of custom-keyboard developers who currently have a degraded voice-input experience on iOS 26.4+. Tested on iPhone 12 Pro Max running iOS 26.4.2 (build 23E261), Xcode 26.x, Swift 5. Thanks!