Hello, I have a few questions regarding the documentation here: Can this method described in the article be built with Xcode 26 and run on iOS 26? Or is it restricted to run only on iOS 26, since AppExtensionPoint appears to be available starting from iOS 26? Does this approach allow two apps under the same Team ID to communicate with each other? Does this approach also allow two apps under different Team IDs to communicate with each other? Is it mandatory to implement EXAppExtensionBrowserViewController and obtain user consent before using this method to exchange information? In our implementation, we followed the documentation. Inside EXAppExtensionBrowserViewController, we were able to see the Generic Extension from another app and enabled the permission. However, we still get the following error: Failed to connect: Error Domain=NABUExtensionConnector Code=1 "No matching extension found" UserInfo={NSLocalizedDescription=No matching extension found} Could someone clarify whether this is expected behavior, or if we are missing an additional configuration step? Thanks in advance!

[Question] Inconsistent Call Directory number matching across regions (Japan, Taiwan, U.S.) We’re developing a Call Directory extension and observed inconsistent number matching depending on carrier region and number format. Environment Device: iPhone (iOS 26.0) Call Directory Extension: Custom implementation Carrier A: Japan carrier SIM Carrier B: Taiwan carrier SIM Numbers added to Call Directory patterns: +81 120 580 2XXX +81 704 336 2XXX Observed Behavior (Japan Carrier SIM) Incoming call from +81 120 580 2XXX → Caller name not displayed (Call Directory match failed). Entering 0120 580 2XXX in the Phone app dialer → Name displayed correctly. Incoming call from +81 704 336 2XXX → Caller name displayed correctly. Entering 070 4336 2XXX in the Phone app dialer → Name displayed correctly. Observed Behavior (Taiwan Carrier SIM) Entering +81 120 580 2XXX in the dialer → Name not displayed until the call button is pressed. Entering +81 704 336 2XXX in the dialer → Name displayed immediately, before the call is placed. Steps to Reproduce For Japan carrier: Use a device running iOS 26 with a Japanese SIM card. Add the following numbers to the Call Directory extension: +81 120 580 2XXX and +81 704 336 2XXX Receive an incoming call from +81 120 580 2XXX → ❌ Caller name not displayed. Open the Phone app and enter 0120 580 2XXX → ✅ Caller name displayed. Receive an incoming call from +81 704 336 2XXX → ✅ Caller name displayed. Open the Phone app and enter 070 4336 2XXX → ✅ Caller name displayed. For Taiwan carrier: 7. Insert a Taiwan SIM card (keep the same Call Directory patterns). 8. Enter +81 120 580 2XXX → ❌ Name not shown until the call button is pressed. 9. Enter +81 704 336 2XXX → ✅ Name shown immediately. Expected Result For both numbers: Caller name from Call Directory should display consistently: a) On incoming calls. b) When entering the full number in the dialer (before pressing call). Behavior should be consistent across regions (Japan, Taiwan, United States). Actual Result Region / Carrier Number Pattern Incoming Call Dialer (Local Format) Japan +81 120 580 2XXX ❌ Not shown ✅ Shown (0120 580 2XXX) Japan +81 704 336 2XXX ✅ Shown ✅ Shown (070 4336 2XXX) Taiwan +81 120 580 2XXX N/A ❌ Not shown until call Taiwan +81 704 336 2XXX N/A ✅ Shown immediately Questions How should numbers be formatted or stored in the Call Directory patterns so that they match both incoming calls and dialer input consistently across regions? Are there region-specific number normalization rules (e.g., Japan’s 0-prefixed local dialing or Taiwan’s international format handling)? Is there an official guideline or recommendation for formatting phone numbers in Call Directory extensions (e.g., E.164 vs local format) to ensure consistent matching? Notes The inconsistent behavior appears to be related to how iOS normalizes numbers per carrier region and local dialing conventions. In Japan, incoming calls from mobile numbers starting with 070 match correctly, while 0120 (toll-free) fails unless entered in local format.

Hi all, I’m currently testing an auto-renewable subscription whose availability is restricted to Japan only (all other territories disabled in App Store Connect). However, when testing in the Sandbox environment, the behavior does not match the availability settings: Sandbox Apple ID storefront: Taiwan Subscription availability: Japan only StoreKit 2 (Product.products(for:)) still returns the product Sandbox purchase succeeds even though it should be unavailable in this region. Questions Is this expected behavior in the Sandbox environment? Does Sandbox not enforce subscription territory availability? Is this a known limitation where Sandbox validates the purchase flow only, without applying real storefront availability rules? Will territory restrictions be enforced correctly in production once the app and subscriptions are “Ready for Sale”? Is there any recommended way to test storefront-based availability before release? Thanks in advance!