Filed as FB_______. Related to thread 841386 ("iOS 27: Malicious link blocked") and FB25102183, but this case involves no link at all. The user pastes the code into the Phone keypad themselves. Setup: iPhone 17 Pro Max, iOS 27.2, Verizon (forwarding code *72 + 10-digit number; GSM carriers use **21* + number + #). What our app does: our customers forward their own cell to their own business number on our service. The app never opens a tel: link, never dials and never uses Shortcuts. It shows the carrier's forwarding code, copies it to the pasteboard only when the user taps "Copy code", and guides them to paste it into Phone > Keypad and tap call themselves. That normally works. Steps to reproduce: Copy a forwarding code (e.g. *72 + a 10-digit number). It can come from any app; Notes reproduces it. Open Phone > Keypad and paste it. Don't tap call. Leave the Phone app. Come back. The keypad is empty, so tap the green call button. Redial fills the code back in. Tap call. Result: "Call Forwarding Link Blocked", with only OK and Learn More. From then on, clearing the field and pasting the same code again is also blocked, every time, until the Phone app is force-quit from the app switcher. After a force-quit, paste + call works again. To be clear: a normal paste works every time. Paste the code and tap call right away, without leaving the Phone app, and it dials and the carrier confirms forwarding. Typing the code by hand also always works. Only the leave-and-redial path triggers the block, and it then sticks until force-quit. Expected: consistent behavior. A code the user pastes or types into the keypad and dials themselves should not be treated as a "link" depending on whether redial filled the field, and the block should not persist across fresh pastes. Questions for DTS: Is a user pasting a forwarding code into the keypad and dialing it themselves a supported flow going forward, or should apps tell iPhone users to type these codes by hand? Is there, or is there planned, a supported way for an app to ask iOS to set up call forwarding to a given number, with the user approving it in system UI? Legitimate services where customers forward their own number to their own account currently have no path that doesn't look like the scam pattern this protection targets. Happy to provide a sysdiagnose or a screen recording.

Our iOS app has been sitting in "In Review" for four weeks and we have not been able to get a status update through any channel, so I'm posting here in case someone from App Review can take a look. App: Epocra, iOS, version 1.0, build 268 Apple ID: 6813697639 Status: In Review since September 24, as Developer Support confirmed on October 1 Timeline Sept 22: build 267 rejected under 2.1(a), a launch crash on iPad Air running iPadOS 27. Fixed the same day and resubmitted as build 268. Sept 22: a reviewer signed in to the demo account that evening. No activity since. Sept 28: opened a status request through Contact Us, case 102979044954. On Oct 1 Developer Support replied that the review was "outside of our normal timeframe" and that the review team had been notified. Nothing since. Oct 5: second status request, case 102986888342. Acknowledgement only. Oct 9: replied in the App Review message thread for the submission citing both cases. No response. We have not changed anything on the submission while it is in review so we don't reset the queue. The app is a business phone app (CallKit and PushKit VoIP with server-side call recording and a consent screen on first launch). The review notes include a demo account, a walkthrough video, and a phone number the reviewer can call to test inbound calls. Is there anything else we should be doing to get this looked at, or can someone from App Review check on it? Happy to provide anything that would help.