Live Caller ID Lookup Extension - No option in phone settings

iOS 18 (22A3354) will not offer a option in settings (> Apps > Phone) after calling openSettings to enable live caller id lookup extension.

A few things you should look at here:

• This is specifically a "development" signed build, not Ad Hoc, TestFlight, etc. That's the only build type that will work without the approved entitlement.

• Try rebooting the device after you've installed your test app, then checking settings again. I've seen issues in the past where Xcode misses that an app should be present in settings, and but rebooting normally resolves those issues.

• Related to that point, for testing purposes, I also like to implement at settings bundle as it seems to help ensure the Settings.app picks up on the app.

Note that all of the issues in Settings.app seem to specifically be tied to Xcode installation, not TestFlight or the App Store.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer!

thank your for suggestions.

• iOS 18 was freshly installed on the iPhone (with an reset before)
• The app was deployed via Xcode to the iPhone (and not installed via TestFlight, AppStore, AdHoc, ...)

Unfortunately, a reboot did not help.

Can you please elaborate on the last point with the settings bundle?

Best Patrick

Can you please elaborate on the last point with the settings bundle?

A settings bundle is a plist structure the system uses to create any app specific settings an app implements. You can read more about them in "Implementing an iOS Settings Bundle", however, all you really need to do is add one to your project by choosing "File-> New-> File from Template..." and then choosing "Settings Bundle".

Expanding on what I said here:

Related to that point, for testing purposes, I also like to implement at settings bundle as it seems to help ensure the Settings.app picks up on the app.

Settings.app creates the entry for each app from two different "sources":

1. Apps own preference configuration, as configured by it's Settings Bundle.

2. Any other "system level" settings that should apply to that app.

...and leaves the app "off" entirely if neither of those apply.

Including your own Settings Bundle means that your app will always be present and, in my experience, seems to help ensure that #2 does what it should. I don't know if it will work in your case, but it's an easy thing to test.

__
Kevin Elliot
DTS Engineer, CoreOS/Hardware

Isn't LiveCallerIDLookupManager.shared.openSettings() intended to "offer a option in settings ... to enable live caller id lookup extension."?

Isn't LiveCallerIDLookupManager.shared.openSettings() intended to "offer a option in settings ... to enable live caller id lookup extension."?

Yes, but all it's really doing is opening that particular section, not doing an open "specific" to your app. Settings.app is still what's actually building and presenting the UI, hence my suggestion that you include a setting bundle.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi @DTS Engineer

We have uninstalled the app from the device, added the empty settings bundle, signed the app with a development certificate, reinstalled the app and restarted the phone. In the settings app there is an entry for the app itself (SettingsApp -> Apps -> Live Caller ID Lookup Demo). However there is no setting to enable live caller id lookup, neither in our app settings nor in the phone app settings (SettingsApp -> Apps -> Phone).

Our assumption is that there is some kind of setting missing in some plist (see attached info.plist at the end). Or do we need a special entitlement even if a development certificate and profile is used?

We can also provide our test project.

Actual behavior: There is no such option in both places.

• Screenshot 1 (Phone app settings)

• Screenshot 2 (Demo app settings)

Expected behavior: We expected to see an option to enable live caller id lookup extension in the native settings app of the operating system.

• Under: SettingsApp -> Apps -> Phone -> ?? (We don't know what the section would be called)
• Or alternatively: SettingsApp -> Apps -> Live Caller ID Lookup Demo (our demo app) -> ?? (We don't know what the section would be called)

Regards, Dan

Runtime environment:

• macOS: 14.7 (23H124)
• Xcode: Version 16.0 (16A242d)
• iOS: iOS 18.1 (22B5054e)
• iPhone: iPhone 13 Pro Max
• iPhone region: United States
• iPhone language: English

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>EXAppExtensionAttributes</key>
	<dict>
		<key>EXExtensionPointIdentifier</key>
		<string>com.apple.live-lookup</string>
	</dict>
</dict>
</plist>

So, I took a look at this in more depth this morning and here is what I've found:

a) I was able to replicate the issue you're seeing. From what I can tell the issue is actually below CallKit inside LaunchServices.

Unfortunately, I was not able to collect good diagnostic data (more on that shortly...), so while you're still able to reproduce the problem I'd appreciate you doing the following:

• Don't reboot your device before testing (see below).

• Delete the app off your device entirely.

• Reinstall the app using Xcode.

• Use LiveCallerIDLookupManager.openSettings() to open Settings.app.

• Assuming the issue reproduces, leave your phone alone (in Settings.app) for a minute or so, then trigger and collect a sysdiagnose using these directions.

• File a bug that includes a link to this forum post and upload the sysdiagnose to that bug.

• Once the bug is filed, please post the feedback number back here.

b) In the process of attempting to get good diagnostic data, I was able to get the approval UI to show up.

I'm not sure of exactly what was required, but here is what I did that got things working:

• With the app installed, reboot the device and try launching it again. If Settings.app fails to launch at all, please capture another sysdiagnose of that case and upload it to your bugs as well.

• Delete the app, then reinstall with Xcode.

• At this point, everything started working for me. If this works for you as well then... please capture another sysdiagnose and upload that to the bug as well.

• If the process above doesn't work for you, then please go through the same "cycle" again but this time don't capture a sysdiagnose for any failure(s). The sysdiagnose process is a pretty disruptive factor that I didn't do, since I wasn't expecting it to start working and was actually working out of the live log data.

Thank you for your help on the bug side, hopefully the sequence above will get it to load.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware