User Profile

Hello! You can download the simulator manually from https://download.developer.apple.com/Developer_Tools/iOS_17_Simulator_Runtime/iOS_17_Simulator_Runtime.dmg and then install it using xcrun simctl runtime add iOS_17_Simulator_Runtime.dmg

Thank you for the response edford! Indeed, I am aware that the monolith approach we started on many years ago was wrong and it's clear we need to further break down our dependencies after de-spaghettifying our code. Unfortunately the map file didn't help so first I tried to identify and remove anything that belongs to AVKit (AVPlayerViewController, AVPictureInPictureController) but I'd still end up with +[AVSecondScreenController load] being called at one point so the issue was indeed an indirect dependency. I replicated our dependency graph in an empty project and then started experimenting with it, removing stuff that made might have been connected to AVKit, until eventually I found out what the "problem" was, which was QLPreviewController- whenever I had a reference to its initializer anywhere, this would trigger a load of AVKit and the call to the second screen class initializer. Considering my service library which is included from the main app and the extension targets, is there a way to selectively decide at runtime whether to load a framework or not? There isn't one as far as I know. Thanks!

Update 13 Oct 2021 iOS 15.1 (19B5042h) and 15.1 beta 3 (19B5060d): The Screen Time API still appears to be bugged out of its mind. I am not able to consistently list the applications from the child devices on the guardian device. It worked at one point for one child device with iOS 15.1 (19B5042h), meaning I was able to see the apps from the child device on the guardian device, but in my setup I had two child devices and I wasn't able to see and list the apps from the second one. I contacted Apple DTS and this is what they had to say: Q: How would I go about seeing and managing apps from the second device? I also tried factory resetting the second child device and re-authorizing, but the apps never showed up on the parent device, even after cold starting the app. Is there a way to choose between the devices/accounts available to manage via FamilyControls? A: There is no way to choose. All I can suggest is try de-authorizing both child devices and the guardian device, making sure all are enrolled in the same iCloud Family, and the child accounts are under 14 years old, and both have ScreenTime enabled. Make sure the guardian device can see the child devices in ScreenTIme. Then try again. If apps from both devices still don’t show up on the guardian device, then please file a bug report with sysdiagnose logs from all devices, so our engineers have the data they need to start investigating I submitted the bug report FB9700146 with attached sysdiagnose logs from all the devices, but I'm not optimistic about this.

FamilyActivityPicker does not list installed apps on either of the guardian's or child's devices, it only lists the categories. It's not clear at this point whether FamilyActivityPicker needs to be called on the parent or the child device. The apps are now shown in the app running on the child device. They are not shown on the parent device. After successfully authorizing a child device via AuthorizationCenter.shared.requestAuthorization, DeviceActivityCenter.startMonitoring always results in an MonitoringError.unauthorized error. This appears to have been fixed. Even though an app is authorized to managed ScreenTime on a child device, the child can always just delete the app. This is fixed, parental sign-in is now required to delete the app. The DeviceActivityMonitor extension is launched at the start of the interval, so that's good as well. But there's still the critical issue where the parent app cannot list and set restricted apps installed on the child device. I'm still wondering whether the parent app is responsible for transferring restriction information via its own transport (pushes?) or is there a built in mechanism to push the app selection to the child app. If that's the case, the child could just disable pushes for the app and he won't receive restriction updates any more. Another thing that's bugging me is that the FamilyActivityPicker is accessible on the child device without requiring authorization after it's been authorized once. As it stands now, the child could just update the selection and uncheck everything. I'll report this via Feedback Assistant.

The reason from your crash is in the crash log: exhausted real (wall clock) time allowance of 19.95 seconds Your app is taking too long to launch (or to be precise, to call didFinishLaunching from the app delegate). From the stack trace it looks like this is a React Native app so maybe in your RN code you are performing an operation that leads to a never ending loop, maybe performing a (blocking) networking call on the main thread? Have you tested your app without any connectivity?

Just wanted to say "thanks a lot!" everyone, especially Costique, this has been driving me absolutely nuts all night. I had a view attached to an UITableViewCell and I was setting its background to a certain color immediately after it was dequeued from the table view, but it would always revert to what was set in the xib. I tried to isolate the problem in a separate project, but it was working correctly and the backgroundColor setter was called only twice, while my original project setup caused it to be called 4 or 5 times. After studying the stack trace for a while I noticed to traits reference which lead me to this thread, I never would have thought that using named colors would lead to this behavior.