Return journey from containing app back to original host

Question 1 (Return journey from containing app back to original host): Is there an alternative, supported method for a custom keyboard extension to launch its containing app such that when that containing app is later suspended/resigned, the system returns the user to the original host app (e.g., Notes) instead of the Home screen? Does iOS 26 provide any handoff/return APIs for the keyboard voice‑input scenario?

Question 2 (Full‑access‑off persistence and settings navigation): (a) Is the shared app group container expected to be effectively read‑only (with EPERM) when Full Access is off? If so, is there any supported way to persist keyboard settings (that require writing to shared files) without Full Access? (b) What is the supported method for a keyboard extension to direct the user to Settings to enable Full Access on iOS 26, given that openURL via responder chain and extensionContext.open both fail? We are seeking a reliable, non‑private API approach.

Return journey from containing app back to original host
 
 
Q