smb big sur

Nothing to do with networking is ever “basic” |-: [quote='788567021, Cassian93, /thread/788567, /profile/Cassian93'] [what’s] the best way to take consenting users' Watch data from Apple Health Kit and send it to our central server? [/quote] The best approach depends on the networking protocol spoken by your server. Presuming it’s HTTPS, I generally recommend using URLSession directly from your app. URLSession supports two style of session: Standard sessions Background sessions A standard session is best for small amounts of data where latency is critical. A background session is best for situations where latency isn’t such a big deal, or where you have a lot of data to upload. URLSession is one of our better documented APIs. Start with URL Loading System. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The screens are both HDMI TV's, no USB hub. Interesting. How similar* are the two TVs? *Age, manufacturer, etc. The gap between these events is every 2-10 seconds. CGDisplayIsActive and Online returns true and Asleep returns false for all screen representations, physical or virtual. Huh. Further clarifying, what state is the machine tending to live in? In other words, which screen is it claiming to be attached to most of the time (while the display is off)? Also, the big question here is still this: Is the machine supposed to be asleep? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Just wanted to check here to see if anyone else is running into the issue of CarPlay not working at all on iOS 26 Beta 1, even with the update on Friday. I plug my phone in (wired) and CarPlay never shows up. I've seen a Reddit thread where other folks are seeing the same thing. Have you filed a bug on this and, if so, what is the bug number? One thing to keep in mind here is that whether or not other people are experiencing a given issue doesn't actually matter when it comes to file bugs on our beta seeds. If think* you're experiencing a problem, then you should file a bug. That's true if you're the only person who seems to be having a given problem or if you find lots of people on the internet complaining about the problem. That's because, among many other reasons: It's entirely possible for a variety of unrelated problems to present the same way at the end user level. Even if EXACTLY the same problem is happening on all devices, it's entirely possible that the specific circumstances and details are very di

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