@SwiftBeginner2026 Thanks for the detailed summary. Given the checks you have already completed, my next recommendation would be to collect a CoreDevice diagnostic archive while the problem is occurring. Apple’s Developer Tools team has specifically recommended this for devices missing from Device Hub: Device Hub issue — Apple engineer’s diagnostic recommendation There is also a similar report where Finder and Apple Configurator recognized the devices but Xcode did not. In that thread, DTS recommended enabling CoreDevice logging before collecting the diagnostics: Xcode not seeing devices — DTS response Here is the specific next step I would suggest: Open Apple’s Profiles and Logs page and find CoreDevice Framework for iOS/iPadOS. Follow the linked instructions to enable the relevant logging on your iPhone. The page also provides a separate CoreDevice entry for macOS. With logging enabled, reproduce the problem: connect the unlocked iPhone and open Device Hub so that it shows “No Physical Devices.” Note the approximate time of this attempt. Keep the iPhone connected and run this in Terminal: xcrun devicectl diagnose Save the diagnostic archive at the location reported by the command. If collection reports errors, keep those exact messages and any archive it manages to generate. Submit a report through Feedback Assistant, attaching the archive, your troubleshooting summary, the exact macOS/Xcode/iOS versions and build numbers, and a link to this thread. Then post the Feedback ID here so the Apple engineer already participating can refer to it. Please attach the full diagnostic archive to Feedback Assistant; a Feedback ID and a redacted error excerpt are sufficient to share publicly here. This is a diagnostic collection step and does not erase your iPhone. I cannot confirm a particular failing service or a known Xcode 27.1 bug from the two status fields alone, but these diagnostics give Apple a concrete basis for investigating the discovery and pairing failure.

@SwiftBeginner2026 Thanks for checking. Configurator being able to read the device information makes a basic USB connection problem less likely. However, it doesn’t confirm that Xcode’s development connection is working, and pairingState: unsupported alone isn’t enough to identify the cause. There are a few more checks you can try without resetting your iPhone: 1. Confirm that Terminal is using the same Xcode installation you have open. Run: xcode-select --print-path xcodebuild -version xcrun --find devicectlCompare the version and build with Xcode > About Xcode, and check that the paths point into the expected Xcode installation. If they don’t, select the correct version under Xcode > Settings > Locations > Command Line Tools, then run xcrun devicectl list devices again. This helps ensure the command-line results actually correspond to the Xcode version you’re troubleshooting. 2. Check for VPN or network-filter interference. If you use a VPN or third-party network filter, temporarily disconnect or pause it, reconnect the iPhone, and check Device Hub again. Re-enable it after the test. Xcode uses network communication even over USB, so a working Finder/Configurator connection doesn’t rule out interference with the development connection. Apple explains this in TN3158: Resolving Xcode 15 device connection issues. 3. Try explicitly starting wireless pairing. Since your iPhone is running iOS 27, put the Mac and iPhone on the same Wi-Fi network, then choose Device Hub > + > Pair Nearby Device…. Allow device discovery if macOS prompts, and follow the pairing instructions. This is covered in Apple’s Device Hub guide. Could you share the version/path outputs from step 1, whether any VPN or network filtering is installed, and whether the iPhone appears in the nearby-device pairing dialog? If an error appears there, its exact wording would help narrow this down.

Apple’s transfer guide says keychain access ends at the first update, and users must sign in again. For guests with no other credential, assume the old token won’t be available to the B-signed app. Please confirm any rollback or migration option with Developer Support before shipping.

That message doesn’t indicate that your password is wrong. It says Apple rejected Rork’s app-token request before checking the credentials, and it specifically mentions the client identity Rork sent. That points more toward Rork’s sign-in integration or a temporary service issue than a problem with your developer account or certificates. Try signing in directly at developer.apple.com. If that works and only Rork fails, send Rork support the exact error and time it happened and ask them to check their Apple sign-in client. Only enter your Apple ID details on Apple’s own sign-in page, and don’t send anyone your password or verification code. If Apple’s own site gives the same error, check Apple System Status and contact Apple Developer Support.

The copy installed from Xcode doesn’t exercise the TestFlight delivery path. TestFlight processes builds and testers download thinned variants. Apple’s docs say the build must have its app identifier in the provisioning profile, finish processing, and be assigned to the tester group. I’d check that this exact 27.1 build is listed under the failing group’s Builds, then compare the old 26.5 build and new 27.1 build on the same phone and one other tester. If 26.5 still installs but 27.1 fails for multiple testers, include that comparison, the build numbers, upload times, iOS version, and whether the Watch app is embedded in a Developer Support case. Does the failure affect every tester or just one? Apple’s overview: https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/

Apple’s privacy page separates Siri Suggestions from using Siri to make a request. It says Siri Suggestions uses on-device processing and can use information on the device, including information contributed by apps, to offer suggestions. Apple says those suggestions aren’t stored on Apple’s servers or shared with other third-party apps. Siri settings and personalization can sync between your devices through iCloud with end-to-end encryption. That’s different from Siri request processing. Depending on the request and settings, some request context may be sent to Apple. Apple’s page also says you can turn off Learn from this App per app under Settings > Siri > Apps. It documents deleting Siri and Dictation history, but doesn’t describe an item-by-item log of what an app contributed. Details: https://www.apple.com/legal/privacy/data/en/ask-siri-dictation/

First thing I’d check is the Automation tab after saving it: make sure the automation is still listed and enabled, and that it’s set to run immediately rather than ask for confirmation. You could temporarily replace its actions with a simple Show Notification action, so you can tell whether the schedule fires independently of the shortcut itself. If that still doesn’t run on the first Saturday, delete and recreate the automation and check the iPhone’s date, time, and time zone settings. What iOS version is this on?

Is this on an iPad with a hardware keyboard connected, including a Magic Keyboard? iPadOS can hide the on-screen keyboard when it detects one. Also make sure you’re tapping a TextField in the running preview, not the code editor or a static text view. If there’s no hardware keyboard, try stopping and rerunning the preview, then test a new project with one plain TextField. That should help tell whether it’s an app-specific focus issue or a Swift Playgrounds/iPadOS issue. Which iPadOS and Swift Playgrounds versions are you using?

Since it has been six days, I would send one short status inquiry through the App Review page in App Store Connect. Apple says it aims to review 90% of submissions within 48 hours, but that is a goal, not a guarantee, and some submissions take longer. “Waiting for Review” means Apple has received it but has not started the review yet. Since you have already fixed the rejection items and resubmitted, check that the current submission has the intended build and that the review notes and recording are attached to it. If those are in place, ask whether it is correctly queued or whether anything else is needed. I would avoid withdrawing and resubmitting again just to check on the status. Apple’s pages on review status and contacting App Review explain the status and contact path.

I would be careful about treating the cosmetic themes as automatically separate from the music feature. Guideline 4.5.2 says an app may not require payment or indirectly monetize access to Apple Music. The Developer Program Agreement also says MusicKit content cannot be synchronized with other content unless Apple permits it in the documentation. I do not see either document spell out whether a paid theme in the same app, or an animation that only indicates playback without following the audio, falls on one side of that line. So I would not assume either is approved from the description alone. It may help to ask Apple Developer Support or App Review with the exact purchase screen and playback flow before you build around it. Keep purchases completely separate from starting playback, music access, and the controls. The official wording is in App Review Guideline 4.5.2 and section 3.3.6(D) of the Developer Program License Agreement.

I would treat NULL plus ENOENT as inconclusive for the security decision here. Apple’s acl_get_file man page documents ENOENT as the named object not existing (or an empty pathname); it does not document ENOENT as a portable signal that an existing object has no ACL: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/acl_get_file.3.html Likewise, I would not promote an omitted ATTR_CMN_EXTENDED_SECURITY returned bit to proof of absence unless the getattrlist contract for this attribute explicitly guarantees that interpretation. Your descriptor-bound query and fixture results are good evidence to include in a Feedback Assistant report, but I can’t find a public contract that resolves the APFS/macOS 27 case you describe. For a fail-closed check, keep treating both outcomes as “ACL state not established” and avoid using them to authorize the operation until Apple confirms a supported distinction.

I would avoid using a vertical pixel offset to detect the camera or whether the minimal view is attached or detached. The system chooses those presentations, and the minimal closure is the same view in either placement, so there isn’t a reliable detached flag to branch on. For the compact leading view, use the new isDynamicIslandLimitedInWidth environment value to switch to a simpler layout when width is constrained. Apple’s docs say it applies to compactLeading, compactTrailing, and minimal: https://developer.apple.com/documentation/swiftui/environmentvalues/isdynamicislandlimitedinwidth Keep the minimal presentation centered and sized to fit its available shape, and make the circle itself smaller or simpler when the width is limited instead of shifting it to compensate for the camera. The Live Activities essentials session also discusses the landscape constraint in iOS 27: https://developer.apple.com/videos/wwdc2026/223/

Given that all agreements show Active, a new build is valid, App Store submission succeeds, and TestFlight fails for both apps with the same BETA_CONTRACT_MISSING response, this looks like something Support needs to check on the TestFlight side. I would not keep uploading builds or changing agreements just to retry this. Since you already have FB25290077 and support case 103005423668, add the exact UTC timestamps, request IDs from the App Store Connect/API responses, and confirmation that internal tester installation fails too. Mention thread 813703 as a related report, but keep your own case and feedback number attached so they can correlate the account-specific records. The forum can’t reattach or inspect the beta contract, so Support will need to confirm what is missing.

The knownCount line is useful evidence that this particular Wi-Fi positioning check did not match any known access points, but by itself it does not tell us whether the cause is the local cache, the lookup service, or the database. Since it is happening in Apple apps and on two devices, I would avoid changing router settings based on that line alone. One quick thing to verify on the Mac is System Settings > Privacy & Security > Location Services, including that Location Services is on for Maps and the relevant System Services at the bottom of the list. Apple documents that Mac location can use nearby Wi-Fi information: https://support.apple.com/en-euro/guide/mac-help/mh35873/mac For a useful Feedback Assistant report, include the exact model and build for both devices, whether they use the same Apple Account, the time and approximate location of a failed lookup, and a sysdiagnose captured shortly after reproducing it. The fact that the iPhone works is a helpful comparison, but it does not establish a shared server-side cause. In the meantime, setting the time zone manually should avoid the incorrect clock setting while Location Services is investigated.

CallKit is designed to provide the system call interface for VoIP apps, so there may not be a supported switch to keep all call UI exclusively inside your app while still using CallKit. Apple's documentation describes CallKit as providing the calling interface for incoming and outgoing calls: https://developer.apple.com/documentation/callkit That said, FaceTime launching and leaving its camera preview running for an audio-only third-party call sounds unexpected. I couldn't find a documented macOS API to suppress that behavior. The default calling app option in Apple's docs is specifically described for iOS and iPadOS, so I wouldn't assume it changes this Mac Catalyst behavior: https://developer.apple.com/documentation/callkit/preparing-your-app-to-be-the-default-calling-app Since you already filed FB25284357, I'd add a small reproducible Catalyst sample, the exact macOS and Xcode builds, your CXProviderConfiguration (especially supportsVideo), and a sysdiagnose captured right after the call. That should help Apple determine whether this is a macOS bug or an intended CallKit routing behavior.