User Profile

I know this might not be the exactly correct spot to post this, but I'm hoping to draw attention to a MAJOR REGRESSION in parental controls in iOS 17, in hopes that Apple will quickly release an update fixing it. In iOS 17.0.0, parents can no longer delete the #images GIF search iMessages app from Apple. This could be removed in prior versions of iOS. Third-party apps can be removed from the Settings app, but not the ones from Apple. This change is going to expose millions of kids to the possibility of searching for, seeing, and sending ******** graphic images. If you think I'm overstating the case, try searching for "bikini" or "********" in the messages app, and then think about the fact that parents no longer have the ability to prevent their kids from accessing this content. Please, can someone from Apple respond that hopefully this was an oversight, and will be corrected in a forthcoming release? This represents a huge step backwards for the safety of iOS devices. Or if there is a better venue to reach out to Apple, could someone point that out to me? Thanks so much!

I'm experiencing a really strange crash, so I spent some time making the absolute minimal reproduction possible, and I'm hoping someone can look into it. (The reproduction repo is here, but note that you need to switch to the test-available branch to test the crash) Suppose I have some multi-platform SwiftUI code, and I want to conditionally add a view modifier for platforms that support an api. Here's some code that calls out to fullScreenCover(isPresented:onDismiss:content:), which is not available at all for macOS: public extension View { @available(iOS 14, tvOS 14, watchOS 7, *) @available(macOS, unavailable) // <-- NB: guard macOS 👍 func myModifier() -> some View { self.fullScreenCover(isPresented: .constant(true)) { Text("Hello fullscreen cover!") } } } Take note that the function is guarded with an @available(macOS, unavailable) atttribute. Now, with this code in my project, without even CALLING that function anywhere, I'm immediately getting a crash on macOS 10.15 Catalina, for a missing symbol. The core line of the crash is below, and if helpful, the entire crash report is here. Symbol not found: _$s7SwiftUI4ViewPAAE15fullScreenCover11isPresented9onDismiss7contentQrAA7BindingVySbG_yycSgqd__yctAaBRd__lFQOMQ This shouldn't be, right? That code path should never be taken on 10.15, if I'm understanding correctly? Is this a bug? Is there some sort of alternative compiler directive that would prevent this crash? Again, I have a super simple git repo reproducing this crash, just checkout the test-available branch, archive, sign, and it will crash on Catalina. Any help would be greatly appreciated! 🙏

I'm wondering how to deal with a TSI that seems to have gone totally silent. I opened the TSI on June 1 (bad timing with WWDC, I know). I got one reply during WWDC asking if I could attend a Swift Lab (I couldn't for schedule reasons, and it was the last day). I then got a reply on Monday, June 12, asking to attempt a repro with the most recent version of Xcode. I attempted the repro and replied back on June 15. Since then, I've sent 2 or 3 additional replies, and have heard nothing. It's been a total of 17 days since I've heard from Apple on the TSI (June 12). Is this normal? Is there some channel I could use to look into the lack of reply? If any Apple engineer/staff is reading, the case ID is 2793633. I would be very grateful for any help getting this moving again.

I'm not sure I'm even using the right terminology to describe the question, but I'll try to explain. I have a macOS utility application (LSUIElement=true) that does various things, some on a repeated schedule in the background. If there are multiple accounts on the computer, and "Fast User Switching" is enabled, then my application runs these background tasks for multiple users at a time -- fast switching to another user doesn't stop the application from doing things on a timer in the background (which I guess makes sense). One of the background repeating tasks is expensive and makes no sense to do if the user isn't the "current" or "foreground", or "active" (terminology?) user. So I found myself wanting to ask the question programatically "does my user have the screen?" I've done a lot of googling and exploring partially undocumented Swift and Objective-C APIs trying to figure this out, and I'm not sure if I'm on the right track, but was hoping someone could correct me or point me to some better concepts/resources/APIs, if possible. The best I've been able to come up with is querying who the "Console User" is -- which seems almost always to map to the user "with the screen". But I honestly don't even know what the Console User really indicates, and if it's an accurate proxy for the question I'm trying to ask, or if it's some vestigial unix red-herring. Here's some working Swift code that sort-of seems to answer the question I'm asking: import Foundation import SystemConfiguration func currentUserHasScreen() -> Bool { var uid: uid_t = 0 SCDynamicStoreCopyConsoleUser(nil, &uid, nil) return uid == getuid() } All that said, I'm hoping someone could share their knowledge on some specific questions related to this issue: What exactly is the ConsoleUser, and what information is it meant to convey? Does the Swift function shown above seem like an appropriate/correct/safe way to figure out if the current user has the screen? Is it even correct to ask "who has the screen?" -- could multiple users have the screen? (I experimented and was able to be logged in normally with one user on a machine, and then I screen-shared a different user, both worked at the same time -- who "has the screen" in that scenario?) Would it be better or more correct to ask "does this user have ANY screen/display?" For my use case, the background task has to do with taking screenshots, I don't want to take screenshots if nobody is logged in or looking at a screen (even though the OS happily will do so). When running the experiment mentioned in number 3 above, the screen sharing app prompted me saying "harriet" is currently using the display on "mini" -- what core concepts are being leveraged here? -- how does the OS know who "has the display", and is that what I should be querying instead? Would greatly appreciate any insight on as many of these issues as anyone has knowledge of, and I think future googlers would as well. 🙏

Working on a macOS app, and I have the Deployment Target set to 11.0 in "General" > "Deployment Info". However, despite that, I'm still getting compiler errors like: 'preferredColorScheme' is only available in macOS 11.0 or newer And I'm having to add if #available(macOS 11.0, *) directives. Shouldn't Xcode realize that my deployment target is 11.0 and not force me to do the conditionals?

I'm still working on building a network content-filtering app. At this point, I've got the extension lifecycle activation issues working, have got some custom IPC communication working well between the containing app and the extension, and finally got test machine installation figured out - https://developer.apple.com/forums/thread/675164, and now I'm struggling with a different sort of issue. I have the filtering app installed on two test machines. The installation and IPC communication works fine, and the flow analysis block/allow logic is working really well, which is the core of the app's value proposition. The problem I'm encountering is this: after the network filter has been installed and running on a machine for 1-3 days, it begins to intermittently hang/fail when after the test machine is woken up from a sleep. To be more precise, the filter works very well, even after multiple sessions, waking/sleeping, shutdown and restart. But then, on both test machines, it seems to occasionally just completely fail. Every time this has happened, it has been after the test machine was idle, or sleeping for at least a few hours (usually overnight). Then, when the machine is woken back up, all network traffic flows fail. Some relevent (I think) facts: when the failure happens, the network extension still is running, I can find the pid with ps, and it shows green and running in the Network portion of System preferences I can still see the filter system extension logging things to console via os_log(), although I don't seem to be able to see in realtime the requests that are failing, but I see a lot of activity in console.log, indicating that the process itself doesn't seem to be stuck or hung up, as far as I can tell... removing the filter extension from the network system prefs panel and re-installing/activating it from the containing app always seems to restore correct behavior I tried attaching to the pid with lldb, which I was able to do, but I was over my head on what to do next at that point, I’m going to be be doing some research on live debugging running processes with lldb, because I have zero experience with this. the containing app is not showing any unusual memory or cpu consumption in xcode or activity monitor, and I don't know (yet) how to check similar vital stats for the root system extension, so I can't speak to that the network connections that fail seem to eventually just time-out, based on watching os logs in console. I can see some requests that I initiate eventually (30 seconds later or so) showiong up as errors in console, with references to timeout exceptions etc. But I don't see logging of those timed out requests in my content-filter system extension -- it's like they're hanging/timing out without ever being allowed to be handled by my extension i do an os_log for every request that I block, but these requests that just never complete also never show up in my extensions logging. I guess what I'm hoping is that the description of the problem I'm having triggers some idea in someone more experienced than I am in this domain. I'm struggling to know even where to start trying to debug the issue, especially since it usually takes a day or two to manifest, and then, only after sitting asleep overnight, or for several hours at a time, so it's difficult to repro and troubleshoot. Here are some of the questions I'd love any response to... what would be your first guess as far as what to troubleshoot/test given the description above? what would be your gut feeling of what I should do first, to investigate this and hopefully get to the bottom? could it be a memory issue? if so, can someone point me in the right direction of how to determine this and address it? has anyone had a similar problem with long-running sysex processes like this? Is it possible there's a known issue, or some undocumented footgun I'm running into having to do with the system extension API, and not so much my own code? I know these api's are relatively new -- do people have production apps in the wild using the content-filter extension point? Does anyone have any experience with these processes running for a long time on host machines? Or are there not many real deployed use-cases yet out there? the area of the app I feel the least confident in is the code around my inter-process-communication. Is it possible that some error of mine with overusing or wrongly managing the IPC communication could manifest as the problem above described? what happens with the content-filter sysex when the machine is asleep? Is it possible that requests queue up in some way that overwhelms the system after waking a long time later? or is there something else about the sleep/wake cycle that would point to the likely cause of the issue? Sorry for the super long writeup, I wanted to provide as much context to help trigger any helpful ideas from whomever might read this. I truly appreciate any input on this, thanks so much.