This change also caused significant problems for our app. Removing the distance filter seems to have fixed the issue and the app seems to be running ok in background again. I use accuracy 100m and no location indicator. However, one drawback of not having the distance filter is that when moving, even walking or on a bike, I get 20-30 events per minute mostly with no change in coordinates. I suspect an increase in the battery consumption assigned to our app due to this, which if true will make users unhappy.

Did you get any feedback on this? I am seeing similar strangeness with CoreMotion that I do not recognize from before. We have also been relying heavily on the sensitive motion detection in CoreMotion for the functionality of our app. I am still investigating and have limited access to phones but two thing I have not noticed before are that: While my iPhone 11 behaves as always, the iPhone 12 Pro never reports any motion events with confidence level 1 It takes forever to detect walking on the 12 Pro. While my iPhone 11 only requires a couple of steps, the 12 Pro now requires me to walk for several minutes to detect walking.

Adding some info since I could not edit the post. I think this is somehow related to the thread stack size. Running it again, the buffer size that broke things was not exactly the same but similar. Is it possible that there is a 256kb max stacksize for Intel simulator CPU and by statically allocating buffers that exceeds this limit I break something? From one of the crashes it seemed as Log.serialQueue.async {} internally copies information with malloc. Could it be that the info from the stack is copied so it can later be used inside Log.serialQueue.async{} but that by exceeding the 256kB in the C layer stack buffer, it tries to copy data outside of the allowed region?

Answering myself here. After further investigation, this happened due to that a third party library (pjsip) opens VPIO with mic and speaker even if configured for only playback. This was by design and could be solved by turning off EC in that lib. Then it seems as in iOS 15, if there is an input route over Bluetooth, it will use that, which was not the case in previous iOS versions. The solution here was to control the EC setting in the third-party library manually to get the desired behavior.

Thank you @edford that changed everything. I did not understand that from the error description. Just compiling the C libs for arm64 simulator and my app started immediately in the Simulator.

Seems to work again now

Indeed it is disappointing that this is limited to parental controls. There are so many important use cases to address outside of the parent-child relationship. Even without access to the details of the activity, having some activity or just screen-time information would allow for building helpful tools in a wide range of contexts.