Errors when using custom dev client

Hey! I have a managed app that I developed with Expo Go until today. Now I switched to a custom dev client, because a few libs I need won’t function otherwise. Now I only installed expo-dev-client so far and then ran expo run:ios (so no EAS involved). Everything seems to work fine, the app is opened in the simulator and does what it’s supposed to do. But in the console, there are a few errors that weren’t there before, like:

[CoreFoundation] AddInstanceForFactory: No factory registered for id <CFUUID 0x600000b25740> F8BB1C28-BAE8-11D6-9C31-00039315CD46
[UIKitCore] -[UIApplication getKeyboardDevicePropertiesForSenderID:shouldUpdate:usingSyntheticEvent:], failed to fetch device property for senderID (778835616971358211) use primary keyboard info instead.
[UIKitCore] -[UIApplication getKeyboardDevicePropertiesForSenderID:shouldUpdate:usingSyntheticEvent:], failed to fetch device property for senderID (778835616971358211) use primary keyboard info instead.
[CoreAudio]  HALC_ProxyObjectMap::_CopyObjectByObjectID: failed to create the local object
[CoreAudio]  HALC_ShellDevice::RebuildControlList: couldn't find the control object
[CoreAudio]  HALC_ProxyObjectMap::_CopyObjectByObjectID: failed to create the local object
[CoreAudio]  HALC_ShellDevice::RebuildControlList: couldn't find the control object
[CoreAudio]  AudioObjectPropertiesChanged: no such object
[AudioToolbox]            AQMEIO_HAL.cpp:2039  timeout
[CoreAudio]  AudioDeviceStop: no device with given ID
[CoreAudio]  AudioObjectPropertiesChanged: no such object
[AudioToolbox]            AQMEIO_HAL.cpp:2039  timeout
[CoreAudio]  AudioDeviceStop: no device with given ID
[CoreAudio]  AudioObjectPropertiesChanged: no such object
[AudioToolbox]            AQMEIO_HAL.cpp:2039  timeout
[CoreAudio]  AudioDeviceStop: no device with given ID
[CoreAudio]  AudioObjectPropertiesChanged: no such object
[AudioToolbox]            AQMEIO_HAL.cpp:2039  timeout
[CoreAudio]  AudioDeviceStop: no device with given ID

Is that to be expected or can I do something against these?

Running expo doctor reports 🎉 Didn't find any issues with the project! btw.

Hi @jonasmerlin

hmmm… I would also be concerned about those errors/warnings. I don’t usually test on iOS and am not using audio in my apps, so I haven’t seen those warnings before.

Maybe build a dev client and see if you still get the same warnings when you run it?

By the way, it’s not necessary to use expo run:ios and if you do use expo run:* you should be aware that it runs expo prebuild in the background before building your app. This has the effect of basically turning your app into a bare workflow app.

Because of the above, if I run expo prebuild or expo run I make sure to undo the changes afterwards (the main thing is I remove the generated ios and android directories, but I also revert the other changes for good measure). I do this because I prefer to stay on the managed workflow. If you do not clean up afterwards you will need to run expo prebuild or expo prebuild --clean to apply changes that you make to app.json to the native code.

See expo.fyi/prebuild-cleanup

Thanks for your answer @wodin

I’m new to this custom dev client stuff - how do I build one without EAS and without running expo run:*?

Also, I’m doing all of this to use OneSignal: GitHub - OneSignal/onesignal-expo-plugin: The OneSignal Expo plugin allows you to use OneSignal without leaving the managed workflow. Developed in collaboration with SweetGreen. Is that possible without turning to this state between managed and bare?

You can’t build a dev client without EAS Build. Why are you avoiding EAS Build? :slight_smile:

If you want to build on your own machine, you can use eas build --local. See the docs here: Run builds locally or on your own infrastructure - Expo Documentation

Yes, it’s supposed to work in the managed workflow. In theory all you would need to do is install the package and add the plugin in app.json.

I have not tried it myself, but I’ve seen someone on the forums who was having problems with entitlements for some builds of their app (it seemed to be random. Two builds in a row with the same source code might have one working and the other not). I think this is the relevant bug:

Here’s a post from one of the Expo Team members about the problem:

So I’m not sure, but until this issue is fixed you might need to tell Expo not to sync your entitlements automatically (or something like that.)

I think this is the guide you want to follow:

Hey, sorry I didn’t answer. This was actually a super helpful post. I didn’t know about the possilbility to build with --local befor and that was what kept me from using eas.

Now, the problem is that when I’m running eas build --profile development --platform ios --local, I get the following error:

Error: Distribution certificate with fingerprint <redacted> hasn't been imported successfully

Which then aborts the build process.

This error has been reported previously here and here.

But it’s not clear to me which certificates should be deleted from which of the keychains, like
wkozyra’s answers make clear as well.

Any ideas how I could proceed?

Thanks!

I’m not sure about the keychains. Maybe see if you can find any under /var/folders.

e.g. this one was in pablohduda’s build output in one of the threads you linked to:

/var/folders/g1/tbf2q5t55f538lby6bdbyw4c0000gn/T/turtle-v2-1bf2783c-3d54-424b-8eb0-917fd0e4b7d0.keychain

so maybe:

$ find /var/folders -type f -name '*.keychain'

Also, see if you get the same error if you create a new, blank app and try to build that. If that works, maybe add OneSignal and see if it still works or if it breaks.

Onesignal issue should be fixed if you update expo-cli eas-cli and onse-signal-plugin to the latest version.
Managed credentials should “just work” and one signal guide is no longer necessary unless you want to manage your credentials on your own.

Issue with local build with importing certifcate in most cases was caused by some other distribution certificates you already have in your keychain, without seeing it it’s hard to tell what exactly needs to be removed.
I’m guessing a bit, but based on what I’m seeing in my keychain you will probably need to remove

  • Distribution certificate from “My certificate” section
  • public and private key from “Keys” section
    • it might be named similar to certificate so it should be obvious in this case
    • but it might be just named <key>, so it’s hard to tell which is which in this case

Development certs are fine, you do not need to remove those

1 Like

@jonasmerlin, make sure you’ve got the latest eas-cli-local-build-plugin installed too. I’ve had problems in the past when that was out of date.

globally installed eas-cli-local-build-plugin is no longer necessary (we use npx to run local builds)

1 Like

Thanks

Hey @wkozyra, first: thanks for your answer! I’m still having the same issue, regardless of what I’m trying. My Keychains don’t have anything under the “My Certificates” section and only the System one has 4 Apple Keys under the “Keys” section. (See Screenshot attached for an overview of all the Chains I have and the 4 Keys.)

Wether I’m letting eas manage my credentials for me or use credentials.json, I’m still getting the Error: Distribution certificate with fingerprint <fingerprint> hasn't been imported successfully error.

I started looking into the code of the build-tools and as far as I can tell, this line simply runs faslane’s import_certificate action (via this line). And that import_certificate action seems to me what is most likely going wrong, right? (I already tried installing fastlane not through homebrew but via the Gemfile, but that didn’t do anything.)

Now, I’d like to see the output that faslane itself generates, but changing the call to

   await runFastlane([
      'run',
      'import_certificate',
      `certificate_path:${certPath}`,
      `certificate_password:${certPassword}`,
      `keychain_path:${this.keychainPath}`,
      `keychain_password:${this.keychainPassword}`,
      'log_output:true',
      '--verbose',
    ]);

… doesn’t do anything, because the spawn output doesn’t get through I guess. Anything I can pass that would get me that fastlane output?

Thanks!

I don’t think you should remove those keys :slight_smile:

Since it’s running fastlane as a command, one way to do this would be to replace the fastlane command with something that logs the arguments and output when running the real fastlane command.

If I look for fastlane on my machine (installed with Homebrew) I find it in the following locations:

% find /opt \( -type f -o -type l \) -name 'fastlane' -ls
41848347        0 lrwxr-xr-x    1 michael          admin                  39 May 18 11:31 /opt/homebrew/bin/fastlane -> ../Cellar/fastlane/2.206.0/bin/fastlane
41848348        0 lrwxr-xr-x    1 michael          admin                  32 May 18 11:31 /opt/homebrew/var/homebrew/linked/fastlane -> ../../../Cellar/fastlane/2.206.0
41848346        0 lrwxr-xr-x    1 michael          admin                  26 May 18 11:31 /opt/homebrew/opt/fastlane -> ../Cellar/fastlane/2.206.0
41848303        8 -r-xr-xr-x    1 michael          admin                 327 May 18 11:31 /opt/homebrew/Cellar/fastlane/2.206.0/bin/fastlane
41848307        8 -rwxr-xr-x    1 michael          admin                 569 May 18 11:31 /opt/homebrew/Cellar/fastlane/2.206.0/libexec/bin/fastlane
41845447        8 -rwxr-xr-x    1 michael          admin                 673 May 18 06:10 /opt/homebrew/Cellar/fastlane/2.206.0/libexec/gems/fastlane-2.206.0/bin/fastlane

So /opt/homebrew/bin/fastlane is just a symlink to /opt/homebrew/Cellar/fastlane/2.206.0/bin/fastlane.

If I check what those files are, the first is a shell script and the other two are Ruby code:

% file /opt/homebrew/Cellar/fastlane/2.206.0/bin/fastlane /opt/homebrew/Cellar/fastlane/2.206.0/libexec/bin/fastlane /opt/homebrew/Cellar/fastlane/2.206.0/libexec/gems/fastlane-2.206.0/bin/fastlane
/opt/homebrew/Cellar/fastlane/2.206.0/bin/fastlane:                               Bourne-Again shell script text executable, ASCII text, with very long lines (314)
/opt/homebrew/Cellar/fastlane/2.206.0/libexec/bin/fastlane:                       Ruby script text, ASCII text
/opt/homebrew/Cellar/fastlane/2.206.0/libexec/gems/fastlane-2.206.0/bin/fastlane: Ruby script text executable, ASCII text

You could edit the shell script or one of the Ruby scripts to do the logging, but I think it’s cleaner to do this:

  • Rename the one that’s in your $PATH to fastlane.real
  • Create a new fastlane file with the following contents:
echo "ARGS: $@" >>/tmp/fastlane.log
fastlane.real "$@" | tee -a /tmp/fastlane.log
  • Make sure the newly created script is executable

Then try running a build and see what is logged in /tmp/fastlane.log.

When you’re finished debugging of course you can revert the above.