Fire certificate selection

[JeremyK]

I did some investigation using chatGPT to look into this, and I think I can see how you get your list of devices. The odd thing is, somehow Xcode is still letting me deploy an app to the device as it sees it as a destination but it doesn’t show up in any of the ways below, so I wouldn’t spend any time on it, this is just for info. We are going to tell our users that iOS 12.5 is getting the last update of our software and we won’t support it from next year. I think 9 years is pretty good to be fair.

I think that:

• Xcode has an internal compatibility path for legacy devices.
• That compatibility path is not exposed through devicectl, xcdevice, or xctrace.
• Fire therefore cannot currently discover those devices unless they use the same internal APIs (if Apple exposes them at all).

Below is a summary report I asked chatGPT to create to summarise what we found.

Fire cannot debug iOS 12.5 device with Xcode 26.5

Environment

• macOS Tahoe
• Xcode 26.5
• Latest Fire IDE (please substitute exact build number)
• Physical device: iPad mini 2 running iOS 12.5.x

Summary

Fire does not list the iOS 12 device as an available deployment/debug target.

However:

• Xcode recognises the device.
• Xcode reports it as ready for development.
• Xcode can successfully build, install and debug applications on the device.

This appears to indicate that the device is correctly paired and provisioned.

Investigation performed

1. Xcode

The device appears in Xcode’s Devices window.

Xcode can:

• recognise the device
• install applications
• launch applications
• debug applications

Therefore:

• pairing is working
• trust is working
• developer support files are installed
• provisioning is working

2. Fire

Fire does not list the device as a deployment target.

Only newer devices are listed.

3. CoreDevice (devicectl)

Command executed:

xcrun devicectl list devices

Output:

Name               Hostname                                                Identifier                             State                Model
----------------   -----------------------------------------------------   ------------------------------------   ------------------   -------------------------------------
                   8EB39A72-9044-5641-8FA2-48F26441436A.coredevice.local   8EB39A72-9044-5641-8FA2-48F26441436A   unavailable          iPad4,4
Jeremy phone       Jeremy-phone.coredevice.local                           B95B7FA6-F3B4-57CD-B7A8-C454456AD0B4   available (paired)   iPhone 16 Pro
Stocktake’s iPad   Stocktakes-iPad.coredevice.local                        84BD2090-EFB7-5B65-9BB7-20BDEA569CE2   connected            iPad mini (5th generation)
iPad (2)           iPad-2.coredevice.local                                 92B79B51-B782-5EB7-8262-CB4985555E72   unavailable          iPad mini (5th generation)

The iOS 12 iPad mini 2 is not listed.

4. xctrace

Command executed:

xcrun xctrace list devices

The iOS 12 device does not appear.

5. xcdevice

Command executed:

xcrun xcdevice list

The iOS 12 device does not appear.

6. system_profiler

Commands executed:

system_profiler SPUSBDataType

and

system_profiler SPUSBDataType | grep -A20 -B5 iPad

No information relating to the connected iOS 12 device was returned.

Assessment

This appears not to be a provisioning or pairing issue because Xcode is fully able to deploy and debug on the device.

It also appears not to be a Fire configuration issue because Apple’s public command-line tools also fail to enumerate the device.

Current behaviour is:

Tool	iOS 12 device visible
Xcode IDE	Yes
Fire	No
devicectl	No
xctrace	No
xcdevice	No

This strongly suggests that Xcode itself is using a device discovery mechanism that is different from the public CoreDevice command-line tooling.

Question

Is Fire relying solely on CoreDevice (devicectl) or the public device enumeration APIs?

If so, is there any possibility of adding a legacy enumeration path similar to the one Xcode itself is using so that pre-CoreDevice devices (such as iOS 12.x) remain available as deployment/debug targets?

[mh (marc hoffman)]

@JeremyK

Perfectly!! Thanks very much. I can build it, transport it and test it in TestFlight now as it does load again so should be good for the App Store.

Awesome! I just got a chance to test here as well, as it’s fixed for me too. All Xcode 27 (Beta 4) and Xcode 26.6 SDKs are uploaded with the fix now. I won’t be bothering to redo the previous ones, I think.

@JeremyK

I can’t connect to the device to debug though, as it’s not available in Fire for some reason - where does it get its list of devices from?

You should see something like this in the log:

Running /usr/bin/xcrun devicectl list devices -j /var/folders/9f/k6_0xsw91hdbgjgkby0zs6xc0000gn/T/ios-devices.json
Running /usr/bin/xcrun simctl list

try running the command manually to see what results you get. For me it works fine, although I see it has a problem with detecting, I guess, the device type; I will investigate. That could prevent it from running (I’m not set up to test that part right this second)

@JeremyK

(and I can’t add an iOS12 simulator). It does let me add the device as a destination in Xcode, but then it doesn’t appear in Fire, and lots of the simulators do appear even though I said never.

I’m not familiar with that. The “don’t use as destination” is probably a flag I don’t process; I’ll have a look. Where do you set this?

@JeremyK

Output:

Name               Hostname                                                Identifier                             State                Model
----------------   -----------------------------------------------------   ------------------------------------   ------------------   -------------------------------------
                   8EB39A72-9044-5641-8FA2-48F26441436A.coredevice.local   8EB39A72-9044-5641-8FA2-48F26441436A   unavailable          iPad4,4
Jeremy phone       Jeremy-phone.coredevice.local                           B95B7FA6-F3B4-57CD-B7A8-C454456AD0B4   available (paired)   iPhone 16 Pro
Stocktake’s iPad   Stocktakes-iPad.coredevice.local                        84BD2090-EFB7-5B65-9BB7-20BDEA569CE2   connected            iPad mini (5th generation)
iPad (2)           iPad-2.coredevice.local                                 92B79B51-B782-5EB7-8262-CB4985555E72   unavailable          iPad mini (5th generation)

The iOS 12 iPad mini 2 is not listed.

Ok, if devicectrl doesnt list it were SOL i think, becaise i use that for all communication…

@JeremyK

Is Fire relying solely on CoreDevice (devicectl) or the public device enumeration APIs?

It does

@JeremyK

If so, is there any possibility of adding a legacy enumeration path similar to the one Xcode itself is using so that pre-CoreDevice devices (such as iOS 12.x) remain available as deployment/debug targets?

you tell me

does Bin/ios-deploy (do we still ship that? i have it in my Bin) show the device?

ios-deploy.zip (68.4 KB)

[mh (marc hoffman)]

LOL. spend half an hour tracing this only to find:

I disabled this last fall because we actually cannot debug on debvice anymore with thr APIs Apple allows us (at lest as per Xcode 26; i should revisit). Its all guarded behind entitlements we cannot get, i remember spending the betetr part of a week on this back then.

ios-deploy stopped working, we swicthed to devicectrl which had gotten almost all the tools we need – except debugging. And every path we tried to launch with debugger faile don missing entitlements Apple only gives Xcode..

[JeremyK]

@mh

Awesome! I just got a chance to test here as well, as it’s fixed for me too. All Xcode 27 (Beta 4) and Xcode 26.6 SDKs are uploaded with the fix now. I won’t be bothering to redo the previous ones, I think

Great, except I’ve just made another small change and gone through the process again and it’s not now working. Grr. It must be something else now though, because I did a

otool -L “/[my path]/Payload/Logonn.app/Logonn”

which shows that the UIUtilities.framework isn’t there (it was yesterday).

@mh

/usr/bin/xcrun simctl list

devices.txt (47.2 KB)

Big list - they aren’t all shown in Fire. Couldn’t find a message in console about the device list though.

@mh

'm not familiar with that. The “don’t use as destination” is probably a flag I don’t process; I’ll have a look. Where do you set this?

In devices:

[mh (marc hoffman)]

@JeremyK

In devices:

Oh, i expect that to be an Xcode-internal flag. but i’ll check

[JeremyK]

@JeremyK

Grr. It must be something else now though,

And yet it isn’t, as I see this in the analytics log, so I need to work out what I did different (I did try an earlier Fire at one point this morning, perhaps it was that):

Termination Description: DYLD, Library not loaded: /System/Library/SubFrameworks/UIUtilities.framework/UIUtilities | Referenced from: /var/containers/Bundle/Application/690067C7-4722-46CE-80B5-EFB00CA16F65/Logonn.app/Logonn | Reason: image not found
Triggered by Thread: 0

[mh (marc hoffman)]

@JeremyK

And yet it isn’t, as I see this in the analytics log, so I need to work out what I did different (I did try an earlier Fire at one point this morning, perhaps it was that):

Termination Description: DYLD, Library not loaded: /System/Library/SubFrameworks/UIUtilities.framework/UIUtilities | Referenced from: /var/containers/Bundle/Application/690067C7-4722-46CE-80B5-EFB00CA16F65/Logonn.app/Logonn | Reason: image not found
Triggered by Thread: 0

So the failure moved form linking to now failing at runtime?

[mh (marc hoffman)]

Codex thinks no:

This is not coming from the newly generated UIUtilities.fx.

I verified:

• The active iOS 27 UIUtilities.fx contains no Frameworks or linker options.
• Relinking the original failing app objects with the same lld command, minus -framework UIUtilities, produces an executable loading UIKit only.
• Resolving symbols from UIKit’s embedded UIUtilities TAPI document also records UIKit—not UIUtilities—in both lld and Apple ld.

So Logonn itself was still linked with a direct UIUtilities dependency, most likely through a stale binary/link cache or another explicit linker input.

Please send me either:

• The new verbose lld ... line for Logonn, or
• The local path to the built Logonn.app/Logonn.

A clean rebuild is also a useful first discriminator. No further source changes were made.

[JeremyK]

@mh

So the failure moved form linking to now failing at runtime?

It’s always been runtime. Codebot thinks that TestFlight is adding it and I should disable bitcode. I notice if I build a debug ipa and drop that into the iPad with configurator, it works (and looking in the payload for the ipa shows no Uiutilities), but getting the one via Testflight fails. Odd, because the first one this morning is fine. Shame I can’t get that actual ipa file back to examine it to see if I can tell the tool used to build, just to double check, as I’ve also tried Xcode 26.1 and an older Fire.

[JeremyK]

Anyhow. Just did another build (with Xcode 26.6 and latest Fire with your files from yesterday - which incidentally I just dropped into my ../Library/Application Support/RemObjects Software/EBuild/SDKs/Island/Darwin folder to replace the ones it was using) and checked no Uiutilities framework present. Uploaded to TestFlight and now it does load correctly on the device. I’m going to leave it there (assuming the testing goes well) and that will be the last build for those.

Thanks for your assistance, as always marc

[mh (marc hoffman)]

@JeremyK

It’s always been runtime.

Wait, the UIUtilities issue was a LINKER error, no? it was for me.

[JeremyK]

@mh

Wait, the UIUtilities issue was a LINKER error, no? it was for me.

In this latest issue I built the app fine, it just crashed on load on ios12.

[mh (marc hoffman)]

@JeremyK

In this latest issue I built the app fine, it just crashed on load on ios12.

Ah ok. i’d say this is a sepaarte issue then. On newer OSs and 25.5/6 it works fine? Are the deployment tergets set to include iOS 12 for all libraries you use? Any “library x was bulld with deployment target y” warnings?