Cannot show Automatic Strong Passwords for app bundleID

Question

This is the full error-message:

Cannot show Automatic Strong Passwords for app bundleID: com.ckbusiness.Wishlists due to error: Cannot identify the calling app's process. Check teamID and bundleID in your app's application-identifier entitlement

What am I missing here??

Soy

We are facing the same issue on iOS 14.2. Strong passwords were working correctly prior to iOS 14. – Putup

Same issue here. Works for us on iOS 14.1, iOS 14.2+ does not – Johen

Same here since iOS 14. Weird is that my Universal Links are still working as well as saving passwords to the keychain/associate domain. So basically my Associate Domain setup is still ok and only strong passwords is not working. Found no solution yet: Ask the same question with my setup/infos here: #65157278 – Ameliorate

Answer 1

We have the same issue with Xcode 12.2 and iOS 14.2 and applied more details on the Apple Developer forum.

Can this be related? The documentation of the Associated Domain File shows a new section at the bottom about macOS 11 and iOS 14:

Starting with macOS 11 and iOS 14, apps no longer send requests for apple-app-site-association files directly to your web server. Instead, they send these requests to an Apple-managed content delivery network (CDN) dedicated to associated domains.

Update - December 3:

We checked many things:

Code signing

Our target is set to "Automatically managing signing". In App Store connect we looked up the the entitlement:

1. Select app
2. Select "Activity"
3. Select a Build
4. Scroll down to "Store Information", the right column shows the Entitlements.

The com.apple.developer.team-identifier matches the prefix in the application-identifier. The latter matches exactly with the value in the apps array in the apple-app-site-association file on our website.

However, when performing Build & Run with Xcode on device, the debug app is signed with a different Signing Identity:

Apple Development: (other ID than com.apple.developer.team-identifier)

An estimated guess is that this would create a mismatch with the apple-app-site-association file. Hence we added this new id to the existing apple-app-site-association file and uploaded on our server:

{
   "webcredentials": {
       "apps": ["ABCDEF1234.com.domain.appName", // Release ID from App Store
                "1234ABCDEF.com.domain.appName"] // Debug ID from Xcode
    }
}

Tried again, still the same error. Also performed the usual stuff like:

1. Uninstall app from iPhone and reboot iPhone
2. Clean Build Folder in Xcode
3. Delete Xcode folder DerivedData from /Users/xxx/Library/Developer/Xcode and rebooted MacBook

Availability of apple-app-site-association file

While updating this file on our server, we found a docu update. In June 2019 (when we launched this particular app) it mentions to place the file in 2 folders:

• https://<fully qualified domain>/apple-app-site-association
• https://<fully qualified domain>/.well-known/apple-app-site-association

Note: Currently only the later .well-known directory is mentioned.

It appeared that our file was only in the first folder. So we duplicated it and checked again, but still the error is shown.

To rule out that it takes time for iOS 14 to update changes of the apple-app-site-association file based on the new Apple-managed content delivery network (CDN), we even used the mode option in the entitlements file:

While you’re developing your app, if your web server is unreachable from the public internet, you can use the alternate mode feature to bypass the CDN and connect directly to your private domain. You enable an alternate mode by adding a query string to your associated domain’s entitlement as follows:

webcredentials:doamin.com?mode=developer

Again, no luck.

TestFlight version

To avoid using Xcode debugger and it's debug signing, archived the Xcode 12.2 build and submitted it to App Store. Verified the entitlements from the build in App Store Connect as described above. They match the apple-app-site-association file.

Released for internal TestFlight testing and tested on device. Tapping the first password text field does not show the password suggestion.

Conclusion

Although we seem out of options, hopefully any of these exercises can inspire others to identify a solution. Or it's just a massive Apple bug and we need to wait for a fix from them.

Renewal

Also verified on latest iOS 14.3 beta 3, no password is suggested anymore. – Renewal

Any updates on this issue? I not working still iOS14, Xcode 12.3 – Ameliorate

In my case it's even worse. Instead of the autofill not showing up at all, I am getting suggestions as if I had set the textContentType to .username. Basically the iOS keyboard is suggesting a username for my password textfield. Yuck - Apple plz fix. – Uund

@Uund same here. – Jargon

would you be able to build and run with your distribution certificate? I am having the same problem and think just including the development certificate id in the association file is not the fix. I wonder if anybody who doesn't have a certificate mismatch is having this problem. – Torpor

Any update on this? I'm still experiencing this issue (iOS 14.5, Xcode 12.5). – Reduplicative

@Uund Still the same problem (iOS 15.2, Xcode 13.1). – Multipartite

This was helpful for us to figure out the solution (will post in a separate answer below) - the key was the Apple CDN, also developer mode is not working to bypass the CDN for us – Shotten

Answer 2

We just hit this problem with iOS 16.4.1, Xcode Version 14.3 (14E222b).

We followed the steps in the answers, and ultimately figured out that the apple-app-site-association takes a while to update on the Apple CDN (and using ?mode=developer in the entitlements did not work).

Here is the troubleshooting steps we went through:

1. Check the Apple CDN by loading: https://app-site-association.cdn-apple.com/a/v1/<domain>

2. If the CDN cache has not updated yet (shows outdated file), then try to invalidate the cache by loading: https://app-site-association.cdn-apple.com/a/v1/<domain>?timestamp=<current epoch time> (get the epoch time from here https://www.epochconverter.com) This may take a while to updated (> 8 hours for us)

3. When testing, we made sure to delete the app before running it, as per Apple that forces the device to reload the associations file from the CDN

Shotten

Answer 3

Work again in Version 13.0 beta (13A5155e) !

Ameliorate