smb big sur

I can't speak to timing, but what will happen has to happen in an iOS update. There will be a future version of iOS where an application that does not support the scene-based lifecycle will not launch. So, let's look at the options: You have an existing app on the App Store. You released it ages ago. It uses the app lifecycle. You have not updated it to use the scene-based lifecycle. This app will launch on older versions of iOS, but it will not launch on the new version of iOS. (This will trim a lot of old apps from the App Store.) You have an existing app on the App Store. You released it ages ago. It uses the app lifecycle. You update it to use the scene-based lifecycle. This app launches on the old versions of iOS, and the new version of iOS. You're developing an app in Xcode that supports an older version of iOS that allows the app lifecycle method, and your app uses that app lifecycle method. You can build this app and run it on that version of iOS without issue. It launches fine. If you attempt to run

Would it be possible to disable or hide the “Leave” button in the system screen? No. You can certainly file an enhancement request asking for use to provide/tweak what we show here, but the system is always going to provide some way for the user to directly stop the PushToTalk session. That's because one of the primary goals of the PushToTalk framework was providing user level control over this. I only receive the APNs push notification “type: voip-ptt“ once per active channel. My forum post here goes into this in depth, but the quick summary is that you shouldn't think of the PushToTalk framework's channel as the same thing as your apps. The PushToTalk framework's channel is simply it's connection to your app. There will ONLY ever be one of them and you should not be creating/leaving/joining that channel dynamically. You join it when your PTT session starts and you don't leave it until you session is done. Again, see my other forum post for more details on that means in practice. My app is running in the bac

Yesterday, I announced on another thread that the bug disappeared: I can announce that this bug has magically disappeared with the latest version of Xcode Version 16.3 (16E140) installed on my Mac. I never got any response back from Apple directly whether this was a bug or not and whether this has been solved in whatever shape or form. Completely in the dark and just by retrying over and over again I finally discovered the bug has been fixed. I would really like to understand what is the purpose of the Feedback Assistant other than a big black hole where you submit a bug into without ever getting any valuable feedback. Very disappointed the way Apple's support for developers is working, given the yearly fee you have to pay. Happy, the bug is miraculously solved so I finally can provide an update of my app that works for Mac (designed for iPad) situations again. However, with a new update of my app submitted to App Store I once more hit the same bug. So not resolved yet.

So, the key detail in you post is actually this: I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app. Outside of a few odd edge cases that don't apply here, as far as the system is concerned your bundle ID is what defines YOUR app. That is: Two app bundles are considered the same app if they have the same bundle ID, even if EVERYTHING else is different. Two app bundles are considered different apps, even if the ONLY difference between them is their bundle IDs. That's important because it's why patterns like this: I make a new project with a different name it works without a hitch, this error only occurs with projects with the same bundle identifier as my old app. ...are almost always caused by data the system is tracking ABOUT your app, NOT your apps own code. The next thing I would do here is perform two simple tests to quickly verify that nothing else might be involved. Starting with the project that's failin

They said Xcode will just read the .icon file so I assume this is only on macOS 26. I'd love to hear a confirmation of that - I'm not going to load Beta macOS. Beta Xcode was a big enough step for me. Someone asked in the group lab if the .icon files were back portable. The answer was Yes but I think what they meant was you can use the output of the Icon Composer back in older Xcode because they are just PNG or SVG files. (whatever you imported) I seem to remember never coming back from deleting the AppIcon asset. It's in the back of my mind as a Bad Idea! I think I created a new project and copied all my files back in. Probably I didn't have a recent enough commit. Xcode 26 Icon Composer Any Appearance Default Dark Dark Tinted Mono

One other thing to keep in mind here is that App Store distribution certificates only need to be valid at the time that you upload the app. So the expiration of such certificates is usually not such a big deal. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I filed this under FB17853906. Perfect, thank you. I spoke with an engineer at the Apps & Services WWDC lab and they recommended I post here to make sure the bug gets looked at and routed to the correct team Excellent advice and I hope the lab was helpful! In terms of the bug, I've verified the routing and, after taking a look at this myself, I suspect this is duplicate of an issue we're already investigating. I can't comment on future plans or release schedules, but fixing this is definitely a priority. One comment here: The kernel panic does not occur when using smb instead of nfs. The underlying issue here is tied of the management of mbuf's in the kernel, not nfs itself, and I believe smb is very likely to experience a similar panic. I wouldn't expect it to occur under the same circumstances (the implementation are just to different), but I believe the panic itself can occur. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

I can announce that this bug has magically disappeared with the latest version of Xcode Version 16.3 (16E140) installed on my Mac I never got any response back from Apple directly whether this was a bug or not and whether this has been solved in whatever shape or form. Completely in the dark and just by retrying over and over again I finally discovered the bug has been fixed. I would really like to understand what is the purpose of the Feedback Assistant other than a big black hole where you submit a bug into without ever getting any valuable feedback. Very disappointed the way Apple's support for developers is working, given the yearly fee you have to pay. Happy, the bug is miraculously solved so I finally can provide an update of my app that works for Mac (designed for iPad) situations again.

Many, many thanks, Nickkk, for your great suggestion! In the meantime I discovered that the misbehavior disappears in macOS 12 Monterey and macOS 11 Big Sur, that I happen to have installed on two other computers. I don’t know about macOS 13 or 14, that I don’t have already installed anymore. In any case, I finally found the — very unexpected — cause of the bug. I applied Nickkk’s idea. It took me quite a while, because the app is very big and I wanted to reduce it in relatively small steps, so as not to miss the cause of the misbehavior. A few times of course I had to come back to a previous reduction, and so on. Finally I found the part of the code that produces the bug. Here is a description of what is involved. • I wanted to observe NSApp’s property “effectiveAppearance” in order to modify the content of certain windows whenever effectiveAppearance changes, • so in my document class’s init method I added the statement [NSApp addObserver:self forKeyPath:@effectiveAppearance optio

Exactly same issue here, Apple is not clear at all, they just say it wasn't possible to complete. Then you need to call to support to understand what is going on. Payment, same think, the collect your credit card, but don't give you feedback, is the process correct? is wrong? Dude, how apple is big doing sume dub thinks like that? I've never seen any company hidden the errors and don't care with the user is facing, you have to figure out by yourself what is the problem

I’m gonna let Kevin answer your main question I can never resist a good file system question. Searching some more online, I found someone mentioning that one has to request this entitlement from DTS. Is this true? Yes, that is correct. However, the criteria for granting this entitlement are very narrow, so it is only granted to backup applications. I'm not sure that this would qualify: I actually want to make a snapshot of a user-selected directory so that my app can sync it to another volume while avoiding that the user makes changes during the sync process that would make the copy inconsistent. Having said that, I'm also not sure you need volume snapshotting for that. Breaking down your options: Would fs_snapshot_create be faster than traversing the chosen directory and creating clones of each nested file with filecopy and the flag COPYFILE_CLONE? So, there are three options here, loosely ordered by performance: Create a snapshot with fs_snapshot_create. Clone the entire directory using clonefile() (see man