Popping Sound

The same error occurs to me. I assigned guardians to iPhones logged in with my child's account and activated communication restrictions. In addition, the following alerts and apps pop up on the console despite the fact that requests are made only when you are under a certain age using the AgeService before calling permissionKit. Error Domain=AskToCore.ATMessageComposeValidationError Code=4 The user is in a region that does not support this type of ask. NSLocalizedDescription: The user is in a region that does not support this type of ask. NSLocalizedFailureReason: The user must be in a supported region to use this feature. I'm not living in texas.

Even when a CLBackgroundActivitySession is instantiated immediately upon background launch, CLCircularGeographicCondition Enter events are suppressed. It's possible I'm overlooking something here, but what you're describing basically sounds like expected behavior. Quoting the CLBackgroundActivitySession class reference: Use CLBackgroundActivitySession to start a background activity session that allows a when-in-use authorized app to receive location updates or monitoring events. A when-in-use session can extend into the background (for example, when you background a navigation app that's providing directions) but it cannot start in the background. Everything else you've described is in line with what I'd expect when a session isn't active. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Error 3 is invalidKey. Under normal circumstances, you receive this error if something goes wrong with generating or retrieving the attestation key. Unfortunately due to a bug, there are some instances, where a user's instance of the app will constantly fail. If these subset of users have had their phones since iOS 17.0 or earlier, this would be explained by a known bug in earlier versions of iOS, which impacts an underlying dependency of DCAppAttestService and is fixed in iOS 17.1. While we don’t expect any new issues popping up from this point on, unfortunately any device that got stuck in this state from before 17.1 will not be automatically cleared. While there might be actions for the users to clear this error state, experience taught us that they are just as likely to make matters worse, so we are no longer recommending developers to reach out to their customers to resolve the issue. One solution would be to treat any app instance in this state which is running on an earlier iOS, or persistentl

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Regarding this: it doesn't seem to be an issue with DenyMulticast I don’t think multicast is a factor here, either for good or for ill. iOS has additional restrictions around multicast, but those do not apply on macOS. this command always works for any user When run how? From Terminal? If so, that’s not the evidence that you think it is. Quoting TN3179: macOS automatically allows local network access by: Any daemon started by launchd Any program running as root Command-line tools run from Terminal or over SSH, including any child processes they spawn Based on the info you’ve provided so far, it really does sound you’re bumping into local network privacy issues. This is complicated by the fact that Unix-y programs tend to do things that confuse local network privacy, for example: Common Unix-y techniques, like calling daemon man page, can break responsible code inference. Such p

I am developing a macOS virtual audio device using an Audio Server Plug-In (HAL). I want the virtual device to be visible to all applications only when my main app is running, and completely hidden from all apps when the app is closed. The goal is to dynamically control device visibility based on app state without reinstalling the driver. What is the recommended way for the app to notify the HAL plug-in about its running or closed state? Any guidance on best-practice architecture for this scenario would be appreciated. So, full disclaimer, I don't have a lot of direct experience with AudioServer plugins, so the advice I'm giving is coming from a general device management/architecture perspective, NOT from detailed experience with this particular plugin type. In any case, the place I would probably start with here is the sample project Building an Audio Server Plug-in and Driver Extension. You don't need any kind of DEXT for this, but that sample does how to deal with device appearan

This all sounds like an issue with specific hardware units. Let's go the bug report route on this. First we need a Bluetooth diagnostic log. Please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for Bluetooth for iOS to install a logging profile on your device. Then, once the logging profile is installed: reproduce the problem, keeping track of the actual time of the actions you take and the result you see. also include a sniffer log of the same if you have it. Please include the actual log, and an ASCII export of it from the logger. make sure there aren’t any extraneous BLE devices around, and no other apps are trying to connect to some other BLE device while you are conducting this test. Once the problem is reproduced, follow the instructions at the above link to trigger a sysdiagnose Please also let me know the BLE hardware/firmware/SDK you are using, along with version info. Once you have these, along with any other information you think would be us