Post

Replies

Boosts

Views

Activity

Reply to Network privacy permission check
Hello Framework Engineer, I have an additional use case where an API for checking the Local Network permission would be useful: support for Chromecast and multicast-discovered speakers. Here are some issues we run into without such API 1) If we have a trigger point for the "<App> would like to find and connect to devices on your local network" and the user denies the permission, forget they did it, and then come back to the trigger point, we would like to be able to remind them and offer to bring them to our app Settings which is impossible without knowing the state of the permission. 2) If the user has previously granted permission at the trigger point and we were able to test the state of the permission at app launch, we could kick off the device discovery for them without waiting for them to come back to the trigger point. This is critical for reconnect scenarios, i.e., the app attempts to automatically reconnect to a Casting session that existed last time it was shut down. Without the API to check the permission our feature will be broken. 3) Some frameworks create singletons and will throw exceptions if we attempt to initialize them more than once. We would like to know we have the necessary permission to safely initialize those singletons. 4) Some frameworks may fail internally on the Local Network permission and throw obfuscated errors. In that case we wouldn't be able to tell if the failure is caused by the lack of permission and we can't provide useful feedback for our user. Unless we assume that any error may be caused by the lack of permission and tell the user something like "Please, make sure the Local Network permission is enabled in your iPhone's Settings", which is less than ideal. I hope It's possible to have this API so we don't have to resort to complex guessing. Please, help.
Jul ’20
Reply to How to detect if Local Network permissions are granted?
1 My use case is the following. When I establish a Chromecast session and background the app I need to close the connection while the app is backgrounded and re-open it when the app comes back to the foreground. If the user backgrounds the app, removes the Local Network permission for my app and foregrounds my app, the connection will hang and my app will be in a zombie state where it's waiting for connection and cannot make the decision to play locally because it still thinks it can reach the Chromecast device. Because we don't know the permission has been denied on foreground, we cannot close the connection that is open right away and clearly communicate to the user that we would need the permission to Cast. Instead we'll keep retrying to connect until the Chromecast SDK times out silently. That may take up to a minute and the user would need to terminate the app to be able to play locally. If the user continues to use the app in zombie state, after the timeout occurs the previously discovered devices are still cached and selectable because without knowing the permission state we won't know right away the devices became unavailable. If the user attempts to cast to one of the cached devices, we'll re-enter the zombie state without clear communication with the user about what the issue is. Without an API to check the state of the permission we will have to be guessing and the user may be confused in these use cases above, thereby making our UX far from ideal.
Jul ’20
Reply to Shiny app stops working after upgrade to iOS 16.4
We're experiencing the same issue with our app during passkey registration. I redacted the actual domain and app information below. ==== iOS 16.0.2 (app built with Xcode 14.2) Passkey registration worked correctly with the following setup iOS 16.0.2 (app built with Xcode 14.2). App association file in DOMAIN_URL has the content: { "webcredentials":{ "apps":["APP_ID.APP_BUNDLE_ID"] } } Associated domains in the project and developer mode is webcredentials:DOMAIN_URL?mode=developer On my iPhone, under Settings >> Developer, I have "Associated Domains Development" toggled on ==== iOS upgraded to 16.4.1 (re-ran the app built with Xcode 14.2) After the upgrade I ran the same app and AuthenticationServices started showing this error in the logs. ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" ==== Rebuilt the app for iOS 16.4.1 using Xcode 14.3 After rebuilding the app with Xcode 14.3 the error reason is Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Application with identifier APP_ID.APP_BUNDLE_ID is not associated with domain DOMAIN_URL" UserInfo={NSLocalizedFailureReason=Application with identifier APP_ID.APP_BUNDLE_ID is not associated with domain DOMAIN_URL} I wonder if any issues were introduced to the AuthenticationServices or to the debug options for Associated Domains.
Apr ’23