smb big sur

Not sure if this solution works for everyone, but I found in my case that xcodebuild was reaching out because I had an account defined in Xcode > Settings > Accounts. Once I deleted my account from Xcode, xcodebuild sped up to the same speed as when I unplug my network cable. But the caveat is that my team's build system doesn't have the Automatically manage signing checkbox checked for our projects and is setup to separately manage our certs / provisioning profiles / team identifiers, so removing my account from Xcode isn't a big deal.

Big thanks @DTS Engineer. after 2 days of additional research, i've mark next points. need to sign bundle, and execution file to, one without entitlements, second with. First of all we signing Sysex , than main app. Commands looks like next: codesign -f --timestamp --options runtime --sign ${certificate_name} ${app_bundle.app} codesign -f --timestamp --options runtime --entitlements ${app_entitlements} --sign ${certificate_name} ${app_bundle.app}/Contents/MacOS/${app_name} Also i have to removed keychain access group compatibility, cause when i've trying to run. It can't be run cause saying that signing is wrong. But after removing it solved. In console, i've see the error. Entitlement com.apple.security.application-groups=( group.com.ex.company.appname ) is ignored because of invalid application signature or incorrect provisioning profile its super strange message, and possibly can affect something, but not sure. (Maybe there is must be prefixed with TeamId?) Could you please add comments for it? an

I'll be honest, this has me completely baffled. I have a few comment below, but here's what I'd like you to do: File a code support incident using the button at the bottom of this page. In that request, make sure you mention that I asked you to and include the link to that forum post. I want to get my hands on the actual files involved, so lets move this off the forums. I'd like to get my hands on all the data you've got and it may be to big to send as an attachment. If you can include a link I can download it all from, that would be helpful. If you're in contact with any of your users how are able to reproduce the issue, then what would be most helpful is for them to reproduce the issue (install them app, wait a moment, launch the app and watch it fail), then collect a sysdiagnose. A few notes on that: It's helpful to reboot the machine before testing and to avoid running anything that isn't part of the test. It doesn't matter if the log is collected a few minutes after the issue and, in fact, it ma

It's okay to run multiple ARKitSession's in a single app. Further, they will share the coordinate system of the running app. There is a bit of a cost for additional running DataProvider's, as they all have their own connections to receive data. But in most cases that shouldn't have a big impact on your app's performance.

I would really like an answer to this last question. If the idea is that our API server gets a refresh + access token, then passes the access token to the (user side) app client, which they then use as a bearer token to access resources on the API server (at least, I think this is what is implied by the rather not-too-great docs), then you want to be able to either verify the access token on every request to your API server, which includes checking its validity. If it's nearing expiry, you should use the refresh token to request a new access token. If you have access token validity at 1h, and throttling on token endpoint calls at 1 per day, that's a big fail. Anyhow, I'd really like to know apple's preferred way of doing this, without us either (1) rolling our own token issuing on our servers; or (2) relying on a service such as Cognito in the middle to handle token issuing.

[quote='803106022, Gandolf, /thread/763453?answerId=803106022#803106022, /profile/Gandolf'] I'm working on a screen sharing app [/quote] Thanks for that. This is a well-trodden path, one that I’ve helped numerous developers navigate. Two things up front: I presume you’ve seen the PreLoginAgents sample code. Its read me document mentions a bug (r. 5636091). If you haven’t already done so, please open a DTS code-level support request so I can discuss that bug with your privately. IMPORTANT The submission form asks you whether someone asked you to contact DTS. Make sure to answer “Yes” and point to this DevForums thread. macOS 15 (currently a release candidate) has changes such that screen sharing apps need an additional capability. See Persistent Content Capture. [quote='803106022, Gandolf, /thread/763453?answerId=803106022#803106022, /profile/Gandolf'] does it get its own GUI Session ID? [/quote] You have to define what you mean by “GUI Session ID”. What API are you using that works in terms of session IDs. [q

[quote='803177022, Andrewfromvictoria, /thread/763405?answerId=803177022#803177022, /profile/Andrewfromvictoria'] I feel like this is a yes or no question. [/quote] I admire your optimism. I’m not aware of any scenario where we’ve shipped a consumer Mac [1] where the root volume was formatted to be case sensitive. OTOH, Apple is a big company with a bazillion products so I can’t give you the guarantee you’re looking for. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] It wouldn’t surprise me if we did it for some server configurations, back when that was a thing.

The final solution: This site was helpful: https://blog.arrogantrabbit.com/ssl/Root-CA-macOS/ Create a Certificate for our local development Using the Certificate Assistant to first create a Root CA for the computer Jacaranda (store in System) Using the Certificate Assistant to create a leaf Certificate for the domain xpedite.local (store in Login) Trust the certificate authority. Export the certificate authority to local-cert using the .cer format. I'm creating Jacaranda.cer We can drag and drop this RootCA .cer file onto the simulator to install it. Inside the simularor you can check in Settings | General | About | Certificate Trust Settings to ensure it has been installed. Export the leaf certificate to local-cert using the .cer format. I'm creating xpedite.local.cer You will be prompted for a password, I'm using '***********' Export the leaf key to local-cert using the .p12 format. I'm creating xpedite.local.p12 You will be prompted for a password, I'm using '***********' Run the commands: openssl x509 -i

Thanx @Vision Pro Engineer Michael, I did follow your suggestion and filed a feedback report that apple may add this for the users to know the progress of loading the big 3d Models so far I guess most of the progress bars I have seen in other apps are dummy and not really accurately showing the loading progress of the model rather a timer with some random values or a timer with a delay bar evaluated by the developer him self and it might be different on the user real device.

Thank you a lot for response! Starting with the bottom line question first, the big question I'd ask here is what you're actually trying to block and why. I'm not sure there is any good way to block everything at the USB layer and unless you that's REALLY what you want. The customers wants to have such possibility in DLP system. Criteria to block is device properties ( e.g. productId, vendorId etc.) I found solution which is based on USBDeviceReEnumerate() and it alows to unplug the device. ( see 'https://developer.apple.com/forums/thread/741051'). That post is an excellent example of what makes this area so frustrating. That post is basically asking I've just detected a mount request in my ES client, how do I prevent the mount. That question has an obvious answer. If you want to block I/O to a block storage device, you can do so by: Denying mount in your ES client. Denying open to the device node in your ES client. At that point the mass storage device cannot be accessed from user space. Adding USB

locationServicesEnabled() has everything to do with authorization. If the user disables this setting, your app will not able to receive authorization, and if it has been authorized before, it will lose that authorization. You only need to check this if your app cares and can do something about why it does not have authorization. You can always just check .authorizationStatus and decide on your next steps if it is not important to know 'why'. It may seem like just a setting, but it is a synchronous call that needs to go out of your process to check that setting, and that is not an atomic action. Meaning, your main thread will block while it is waiting for a response. Whether it is a big issue or not depends on your app. It may matter to you if you are playing video, streaming real time data, or gaming. Or you may not care if your app mostly sits idle at your UI. Hence it's a warning you may heed or ignore. Argun Tekant /  DTS Engineer / Core Technologies

Hi, I created Feedback Post, it has FB15025859 I'm really curious about your response, solving this issue would be very helpful for upcoming new features for our player-environment for a very big audience in germany.

Thank you a lot for response! Starting with the bottom line question first, the big question I'd ask here is what you're actually trying to block and why. I'm not sure there is any good way to block everything at the USB layer and unless you that's REALLY what you want. The customers wants to have such possibility in DLP system. Criteria to block is device properties ( e.g. productId, vendorId etc.) I found solution which is based on USBDeviceReEnumerate() and it alows to unplug the device. ( see 'https://developer.apple.com/forums/thread/741051'). However, using USBDeviceReEnumerate() leads to looping because the system tries to plug the device again and again. Are there any way to avoid this looping? Is it safe if application constantly calls USBDeviceReEnumerate()? Strictly speaking, it is possible to block USB devices through the IOKit stack. You an use either of those user clients to obtain exclusive access, at which point no one else will be able to communicate with the device. Thank you! It so

NSTextLayoutManager.usageBoundsForTextContainer gives me a wildly inacurrate (much too big) height, and enumerating the documentRange.endLocation Y coordinate in reverse gives me a too small height. Any workarounds for these issues yet? I can't get any reasonable/reliable text height estimation from NSTextLayoutManager. And enumerating in a forward direction is not possible, since if you have lets say 10000 lines, this will destroy performance for a non-contiguous text view since we are always forcing layout of the complete text.