This issue is back with vengeance on Tahoe 26.2, Xcode 26.2 I basically throw a sheet that depending on state might transition from view1, view2 and maybe view3 The sheet grabs the size of the first view that it renders, and when I transition to the second or 3rd view, nada. But the giant professional rounded corners are so cute.

Went on the iPhone app and it accepted my renewal. Not sure why the web app is refusing payments. Most likely a temporary glitch.

year 2025 and same issue, latest Mac and os, Sequoia

Woha, just upgraded my Mac to Sequoia and noticed this beauty. So basically .frame(minWidth, idealWidth, maxWidth) just became useless when my view is displayed in a .sheet Shouldn't y'apple folks infer that? If I did call .frame than make the view resizableSheet, otherwise display it at intrinsic size as it happens now. ... Thank you for the solution.

It seems the swift team is tightening the screws on concurrency, but ... The error is: Main actor-isolated property 'buttonMaxWidth' can not be mutated from a Sendable closure Where: @State private var buttonMaxWidth: CGFloat = 120 Now looking under the hood: @preconcurrency @inlinable nonisolated public func onPreferenceChange<K>(_ key: K.Type = K.self, perform action: @escaping @Sendable (K.Value) -> Void) -> some View where K : PreferenceKey, K.Value : Equatable but, I wonder why they did not mark this func as @MainActor isolated? I suspect the 2m lines behind that would have to be refactored. for now my solution 1 is to assume .onPreferenceChange(ButtonWidthPreferenceKey.self) { newSize in MainActor.assumeIsolated { buttonMaxWidth = newSize } } What's the point of all these rules if we can say ignore the rules in one line ? For solution 2, you can be more pedantic and declare a MainActor isolated func that you can than open a Task that calls it, too much work ... .onPreferenceChange(ButtonWidthPreferenceKey.self) { newSize in Task { @MainActor in setButtonMaxWidth(newSize) } }

I'v been writing an app for macOS for years. I'm not aware my app cares about devices. It should not, it only cares about full disk access. So how does the Mac figure out that my app needs access to Devices. I want to pre-fill this when I build the app so my customers do not freak out.

Spoke too soon var body: some Scene { WindowGroup { AppView(store: store) .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { userActivity in // handle it here } } } This will duplicate my current window. So now from one window I end up with 2 and 3 and so on.

I'm struggling to understand expectations on happy path and posting here for others in case they wonder. I have no sand boxed apps I create valid/signed/notarized MyTest.pkg with a post install script Distribute the package to end users They install it sudo installer -verbose -pkg MyTest.pkg -target / will install my new app End user runs the new app, which calls /Applications/MyTest.app/Contents/MacOS/MyTest register We get Operation not permitted This will also add an entry on the System Settings -> General - > Open at Login or ask the user to enable this item on right corner user notifications. Since we failed on 5, we call /Applications/MyTest.app/Contents/MacOS/MyTest status We get SMAppServiceStatus.SMAppServiceStatusRequiresApproval Now our app asks the user to allow our item that was magically added on the step 7 We are good to go and can now call our elevated privileged app or XPC. After a lot of fiddling with this new API, this seems to be making sense. Apple does not want us to do all this and not give the end user a final say. After all this work DO I still have to ask the end user to allow full disc access ?

man pkgbuild read on BundleHasStrictIdentifier

This did not answer the original question on how to run a system daemon (or a root daemon). As to That post creates an agent, but the setup for a daemon is very similar these comments are debatable. Provide an example of SMAppService.daemon(plistName:) and let us decide if it's easy.

Amazing. I wanted to upgrade my privileged helper form SMJobBless to SMAppService.daemon. Read the existing code from UpdatingYourAppPackageInstallerToUseTheNewServiceManagementAPI, ok it was nice and simple. Well I wanted to do a bit more, after all apple tells me SMJobBless is deprecated and I should look into the SMAppService class So I made this change class func register() { let service = SMAppService.daemon(plistName: "com.xpc.example.agent.plist") do { try service.register() print("Successfully registered \(service)") } catch { print("Unable to register \(error)") exit(1) } } Made sure to have the plist under $APP.app/Contents/Library/LaunchDaemons/com.xpc.example.agent.plist Boom, I immediately hit the wall. Apple sends me a not so useful error Unable to register Error Domain=SMAppServiceErrorDomain Code=3 "No such process" UserInfo={NSLocalizedFailureReason=No such process} Common guys, instead of riddles, give us better examples, more examples, that cover more than 1% of the functionality.

I added a second Developer ID Installer and I can't revoke the second one, not a big deal but yea it's not perfect. Now I have 2 of them.

Still there in 13.6.5, I wanted to debug some code in Ventura and fired up a VM.

My solution was found on superuser.com questions/526183 since apple does allow me to post the entire url. you basically make a copy of clients.plist, convert it to xml, edit to remove the app you do not like, convert it to binary, restart killall locationd

Yup the same bug ... A trivial feature that somehow does not work.