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?
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.
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.)
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.
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
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
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.