xcode github

This post documents an issue I reported in feedback FB19610114 and see if anyone knows of a workaround. Here is a copy of the feedback. Short version Manipulation (SwiftUI OR RealityKit) fails to translate entities after changing rooms. By changing rooms, I mean a human wearing an Apple Vision Pro leaving one room and entering another room. Once this issue occurs, it impacts all apps that use these features. A device restart is the only solution I have to fix it. Feedback FB19610114 This is an odd one. I'm using the new Manipulation Component in visionOS 26. Most of the time this works well. Sometime it stops working and when it does the only way to get it working again is to reboot the headset. When this happens, I can continue to rotate and scale items, but translation no longer works. It is as if the item is stuck to a fixed point in the parent scene (window, volume, etc). When this bug occurs, it affects every app across the entire operating system that is using manipulation, including the RealityKit comp

It is vital for Apple to refine its OCR models to correctly distinguish between Khmer and Thai scripts. Incorrectly labeling Khmer text as Thai is more than a technical bug; it is a culturally insensitive error that impacts national identity, especially given the current geopolitical climate between Cambodia and Thailand. Implementing a more robust language-detection threshold would prevent these harmful misidentifications. There is a significant logic flaw in the VNRecognizeTextRequest language detection when processing Khmer script. When the property automaticallyDetectsLanguage is set to true, the Vision framework frequently misidentifies Khmer characters as Thai. While both scripts share historical roots, they are distinct languages with different alphabets. Currently, the model’s confidence threshold for distinguishing between these two scripts is too low, leading to incorrect OCR output in both developer-facing APIs and Apple’s native ecosystem (Preview, Live Text, and Photos). import SwiftUI import Vis

I have ios UI tests that are build with command xcodebuild -workspace ... -scheme ... -configuration ... -derivedDataPath ... -destination ... -testPlan ... build-for-testing Then I run them with xcodebuild -destination ... -resultBundlePath ... -parallel-testing-worker-count ... -xctestrun ... test-without-building I also have following settings in testplan maximumTestRepetitions : 3, testRepetitionMode : retryOnFailure, With xcode 16.4 tests were retried on failure up to 3 times, but migrating to xcode 26.2 seems to change this behavior and tests are no longer retried. Is it expected behaviour and I should manually add params like -test-iterations 3 -retry-tests-on-failure into xcodebuild test-without-building command? Here is xcresult - https://drive.google.com/file/d/1xHgiZnIK_lptDSUf-fCyEnT9zYubZlCf/view?usp=sharing And testrun file -https://drive.google.com/file/d/1aBi2sTjy8zFYtgYn1KA60T8gwD_OnBCF/view?usp=sharing

I have an orphaned asset folder taking up 9.13GB located at: /System/Library/AssetsV2/com_apple_MobileAsset_iOSSimulatorRuntime/c0d3fd05106683ba0b3680d4d1afec65f098d700.asset It contains SimulatorRuntimeAsset version 18.5 (Build 22F77). Active Version: My current Xcode setup is using version 26.2 (Build 23C54). I checked the plist files in the directory and found what seems to be the cause of the issue: The Never Collected Flag: The Info.plist inside the orphaned asset folder explicitly sets the garbage collection behavior to NeverCollected: __AssetDefaultGarbageCollectionBehavior NeverCollected The Catalog Mismatch: The master catalog file (com_apple_MobileAsset_iOSSimulatorRuntime.xml) in the parent directory only lists the new version (26.2). Because the old version (18.5) is missing from this XML, Xcode and mobileassetd seem to have lost track of it entirely. What I Have Tried (All Failed) Xcode Components: The version 18.5 does not appear in Settings -> Components, so I cann

I wrote my own framework and it uses some OpenGL calls, I have my own direct replacements for these calls. But Xcode complains when I try to integrate these calls into a NSApp that all of these calls are deprecated. It must be in some module that Appkit or Cocoa uses to include all the headers as I went through and eliminated all potential references. I could just encapsulate all of this in a separate C or C++ file, but I would rather write it all in Obj-C. I know it's just a warning, but I like to treat warnings as errors to catch as many bugs as possible.

My project build failed in Xcode Cloud(works well in my local Mac), and the error shows: Preparing build for App Store Connect failed The error message is not clear enough to help us find the solution to fix it. Can anyone help with it?

Hi everyone, I’m seeing recurring internal AVFoundation camera logs on iOS 26.2 and I’m trying to understand whether this is expected behavior or a regression in the capture pipeline. These logs appear shortly after starting an AVCaptureSession, while video frames are being delivered, and also when the camera is stopped or the capture session is torn down. <<<< FigXPCUtilities >>>> signalled err=-17281 at <>:302 <<<< FigCaptureSourceRemote >>>> Fig assert: err == 0 at bail (FigCaptureSourceRemote.m:569) - (err=-17281) Even in this clean, minimal setup, the same logs appear on iOS 26.2 The exact same logic did not produce these logs on iOS 18.x. To rule out issues caused by my own code, GPT created a minimal SwiftUI example from scratch. My primary interest is to perform real-time processing on the video frames delivered by the camera (via AVCaptureVideoDataOutput), for tasks such as analysis, computer vision, or custom frame handling, wh

Platforms: macOS 15.x (Sequoia), Intel-Based App type: Endpoint Security (ES) client, notarized Developer ID app + LaunchDaemon Goal: Boot-time ES client that runs on any Mac (managed or unmanaged) Summary Our ES client launches and functions when started manually (terminal), but when loaded as a LaunchDaemon it fails to initialize the ES connection with: (libEndpointSecurity.dylib) Failed to open service: 0xe00002d8: Caller lacks TCC authorization for Full Disk Access We can’t find a supported way to grant Full Disk Access (SystemPolicyAllFiles) to a system daemon on unmanaged Macs (no MDM). Local installation of a PPPC (TCC) profile is rejected as “must originate from a user-approved MDM server.” We’re seeking confirmation: Is MDM now the only supported path for a boot-time ES daemon that requires FDA? If so, what’s Apple’s recommended approach for unmanaged Macs? Environment & Artifacts Binary (path placeholder): /Library/Application Support///App/.app/Contents/MacOS/ Universal (x86_64 + arm64