smb big sur

I ran Into these. deleted the simulator default.store files deleted the derived data for the app deleted all the cached simulators stuff in derived data. quit and restart Xcode launch app on the simulator and recreated the store. All gone for now.Obviously I used a big hammer but it worked.

I have experimented a little more. I can reproduce this issue by: create a new project in Xcode 16 beta 6 with default settings Include any reference to NSDecimalRound() Build an Archive build from Xcode Launch the App. Here is the code I am adding to trigger the crash: public extension Decimal { func rounded(_ roundingMode: Decimal.RoundingMode = .plain) -> Decimal { var result = Decimal() var number = self NSDecimalRound(&result, &number, 0, roundingMode) return result } } This seems very bad so I have filed FB14900250 but this is a pretty big blocker for us to be able to ship anything right now.

No, this is not a behavior I'd rely on. A few big issues I see: We have not in fact documented that network extension are copied out of the app bundle and that the app bundle is not in fact required. The fact that this works today does NOT guarantee that it will work tomorrow. I'm not sure that it DOES in fact work today. Deleting an app from /Application should remove it's app extensions and, I believe, doing so through the Finder WILL in fact disable it. If using rm is bypassing that process, then I'd consider that an oversight, not an intentional behavior you can rely on. On the user experience side, you're removing the visible sign of what your product actually does, why it's there, a method to uninstall, etc. The MAJOR reason we require extension to be inside apps it to help make sure that invisible additions to the system are in fact visible. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Still not fixed and no feedback in the ticket (besides There is no workaround DTS can provide (...) from DTS team). Seems like installing random languages on user devices and breaking text suggestions while typing is not a big deal for Apple, all man-power is delegated to memoji development.

While we a have a number of recommendations on how to make Bluetooth connections more efficient, controlling Bluetooth transfer rate when using two iPhones is a bit more difficult, because, unlike when you are communicating with a BLE accessory which you may have access to their firmware, you would not be able to control certain connection parameters on an iPhone, which contribute to the overall transfer rate. Additionally, the connection parameters chosen by a specific iPhone at a specific time will not be the same as another iPhone at another time, because iOS may choose certain parameters that are optimum for various things, like power savings, device state, and also to work without interfering whatever else might be going on on the device at the time. And not necessarily choose the optimum settings for the fastest transfer rate. Also things might change between iPhone models and iOS versions. Because of all this, even if you were to establish a goal transfer rate in your tests, you cannot guarantee that t

Hello I’m actually building a fully immersive VR experience using big space VR like even if you have a vr environment, that environment will be fully matched to a big empty room, so I’m sure there will be no danger for the user, also my undergrad thesis is to create a haptic glove to work in the Vision Pro in escape room settings, so I need to be able to walk around the unity built VR, in order to interact with The scene I’ve built, I want to do a proof of concept of if you can walk around the space instead of locomotion or teleport will address motion sickness, Im also experimenting some IoT modules to be placed in the room for temp feedback

AMAZING !!!! big big big thanks !!!

One of our customer has reported that pushes are delivered with big delay. Pushes are send to APNS in less than 5 seconds as per our statistics but it takes sometimes up to 5 minutes for notifications to arrive on devices. I have investigated many, many issues like this and, in the VAST majority of cases, they could ALL be summarized as: A network (the device did not have a working network connection) or hardware (the device was not turned on) level issue meant it was unable to communicate with our push servers. At some later point a working connection was established with out servers. The push reach the device IMMEDIATELY after that connection was established, typically reaching the target apps in <1s of the connection being reestablished. ALL significant delivery delays on the device side were caused by the target app itself, NOT the system. In concrete terms, when it takes 6s for a push to reach a voip app AFTER it's reached the iOS device, it's because it took ~6s for that voip app to finish l