“DTiPhoneSimulatorErrorDomain Code 2”

Update — root cause found and a working workaround I cracked it. Posting the solution here so other admins can stop trying random bundle IDs. Root cause (confirmed via watchOS sysdiagnose) When you install a profile with com.apple.applicationaccess + allowListedAppBundleIDs, lsd on the paired Apple Watch immediately sends uninstalledNotifications for every PluginKit extension whose bundle ID is NOT in the whitelist. The watch's Carousel then cascades by terminating the parent apps that own those extensions, disguising the action as user initiated quit. Captured from watchOS sysdiagnose at the moment of profile install: 17:22:56 lsd: Sending uninstalledNotifications for ( pluginID=com.apple.MobileSMS.MessagesAssistantExtension pluginID=com.apple.tincan.SiriExtension pluginID=com.apple.SessionTrackerApp.SessionTrackerSiriExtension ) 17:23:13 Carousel: com.apple.MobileSMS: terminateApplication - uninstalling app (user initiated quit) 17:23:13 Carousel: com.apple.tincan: terminateApplication - uninstalling app (u

This is a tricky aspect of NSTextField in table views. usesAutomaticRowHeights relies on the text field's intrinsicContentSize to determine row height. When isEditable is true, NSTextField internally changes its sizing behavior and stops reporting a multi-line intrinsic height, so the row collapses to a single line. Your observation that the text still wraps internally but the cell height doesn't update is exactly right. The fix is to stop using usesAutomaticRowHeights for editable text fields and calculate row heights manually using tableView(_:heightOfRow:). Use a separate non-editable text field as a measurement prototype — since non-editable text fields calculate wrapping height correctly — and call noteHeightOfRows(withIndexesChanged:) when the text changes so the row resizes as someone types. Here is a working example: // Prototype field for height measurement (non-editable, so wrapping height is correct) let measureField: NSTextField = { let tf = NSTextField(wrappingLabelWithString: ) tf.isEditable = f

I’m seeing what appears to be the same issue with my watch app distributed through TestFlight. For a small subset of users, the watch app icon stops opening entirely after the app has been installed and working for a while. Complications/widgets continue to work, but tapping the app icon does nothing. There’s no normal crash report. I pulled a sysdiagnose from one affected user, and the watch logs showed repeated launch denials for the main watch app bundle with messages like: signature state: Profile Missing, reason: Provisioning Profile Not Found Unable to launch because it has an invalid code signature, inadequate entitlements or its profile has not been explicitly trusted by the user cannot launch untrusted application I also saw MobileInstallation log: _InstallProvisioningProfile: Could not install embedded profile: 0xe800801f (Attempted to install a Beta profile without the proper entitlement.) What’s especially confusing is that: the same TestFlight build works fine on many other watches compl

If I have to go from iPhone->USB-C->to Ethernet to a hub, I assume I will be using something like a local area network to communicate between the two devices? Yes. However: In the full setup above (using real wired Ethernet) you don't actually need an additional hub. The two devices can communicate directly without a hub in the middle. The details are below, but you can use that logical architecture, but configure your ESP32-S3 to act as the iOS device's USB to Ethernet adaptor. At that point, you're just plugging the USB cable directly into the iOS device. If so, do you think this concept is a good idea? I see that the ESP32-S3 can have a USB-and-ethernet as a host mode. If I use a combination of USB-C-to-Ethernet Adapters like so, do you think I can bypass needing additional hardware? As a late follow-up on this, I believe the ESP32-S3 can be configured to run as a NCM (Network Control Model) device, which basically turns it into an Ethernet over USB accessory. I think Espressif even

Hello! Two of the customers of my app have reported this same behavior (IONIQ 5 Companion). Both reported it happening with third party wireless CarPlay adapters, and in both cases the issue was only resolved by rebooting their iPhones. Please see: https://github.com/gburlingame/ioniq-app/issues/33 and https://github.com/gburlingame/ioniq-app/issues/28 for screenshots. These are two engaged customers, and I'm glad to work with them to help understand and resolve whatever is happening.

Small extra detail from our latest sysdiagnose, in case it helps compare notes. The suspicious part for us is that the same two Watch-side profile IDs appear to be installed during the TestFlight update, then removed a few minutes later. Rough sequence, with app/profile IDs masked: 16:30:51 - iPhone AppConduit sees as updated/trusted and starts the install path. 16:30:51 - iPhone AppConduit also logs: ACXRemoteAppList ... App database is out of sync. 16:30:52 - iPhone/TestFlight asks the Watch for its provisioning profile list. 16:30:53 - iPhone/TestFlight requests two installProvisioningProfileWithData operations via AppConduit. 16:30:54 - Watch AppConduit installs profile . 16:30:54 - Watch AppConduit installs profile . 16:31:08 - Watch MobileInstallation starts installing the new Watch app bundle. 16:31:10 - Watch MobileInstallation reports the install succeeded for the new Watch app build. 16:31:11 - iPhone AppConduit marks as installed. 16:32:07 - The Watch app launches successfully aft

@ppwqgtl That “Profile Missing / Provisioning Profile Not Found” line is extremely interesting. We just captured a fresh sysdiagnose from our own recurrence and it now looks very similar. In our latest case, the sequence was: TestFlight installed our iOS app and paired Watch app build. AppConduit/MobileInstallation reported the Watch app install succeeded. The Watch app launched successfully once after the update. A few minutes later, TestFlight queried installed beta Watch apps and found our Watch app still installed. Immediately after that, TestFlight/appconduitd removed two Watch-side provisioning profiles. The next watch app launch failed before our app process started with the same security/profile trust denial. The files where we saw this were: iPhone sysdiagnose: logs/AppConduit/AppConduit.log.0 logs/AppConduit/AppConduit.log.1 logs/MobileInstallation/mobile_installation.log.0 Watch sysdiagnose: logs/AppConduit/AppConduit.log.0 logs/MobileInstallation/mobile_installation.log.0 The most useful

@ppwqgtl Small correction/update from our side: my earlier reply saying reboot fixed this was wrong. In the latest reproduction, a normal Apple Watch reboot did not recover the app. Deleting/reinstalling from TestFlight does recover it. Separately, one affected watch recovered after the battery drained completely, was left dead for hours, then charged/cold-booted. So this seems more persistent than a simple in-memory bad state. Our latest read is still that this is not an app crash. In the failed state, our app process is never created, there are no app startup logs, and launching with devicectl fails before our code runs with the same Security / RequestDenied shape. The strongest evidence we have now is around AppConduit / paired app state. In iPhone sysdiagnose we see AppConduit / ACXRemoteAppList reporting that the “App database is out of sync” around the relevant window. That lines up with the symptoms: the TestFlight watch app was installed, had launched successfully earlier on the same build/de