“xcode github”

Hi! I'm also new to iOS development and I have exactly the same issue. macOS 26.4 (25E246) Xcode Version 26.4 (17E192) What I've tried: Generated Apple Development certificate through Xcode → Settings → Accounts → Manage Certificates multiple times. Certificate and private key appear in Keychain Access but never paired (cert not expandable in My Certificates, which remains empty). Generated CSR manually via Keychain Access Certificate Assistant, uploaded to developer.apple.com, downloaded .cer, imported — same result, no pairing. Generated key and CSR entirely via openssl CLI, uploaded CSR to developer portal, downloaded cert, created .p12 with -legacy flag (standard openssl 3.x p12 fails with MAC verification failed on import). Imported p12 — certificate and public key import but private key silently dropped. Class 0x0000000F (private key) never appears in security dump-keychain, only 0x00000010 (public key) and 0x80001000 (certificate). security import of the PEM private key reports The sp

Hey Albert, Thanks for the prompt response. Here is the link to Github repo: https://github.com/VJM158/UIKitTabBar What happens when you disable Liquid Glass? Do you get the results that you want? - Yes, we get the desired result. I using Xcode 26.3 with iOS 26.2 simulator Using a fully custom view with buttons is definitely an option, but my concern is that I would lose a lot of built-in UITabBar behavior such as tapping the active tab to return to root, hidesBottomBarWhenPushed, accessibility support, badging, and other system-integrated behaviors. This is a fairly large and complex app, so I’m hesitant to replace UITabBar entirely unless that is really the only reliable path. Please let me know if my understanding is correct. I’m mainly trying to understand what the recommended path forward is here. Also, if Liquid Glass is enabled for the app, is the selected capsule in UITabBar mandatory?

It seems there is no way to update the Claude binary to newer versions within Xcode. Can you please add this feature? Perhaps that would help here. The version it is currently installing is 2.1.59, the latest version is 2.1.92.

Same issue here. After analyzing the crash log in detail, I can confirm this is not related to our code or derived data cache. Root cause: Infinite recursion (10,915 levels deep) in -[AXElement customActions] inside AXRuntime.framework, triggered by UIAccessibilityHierarchyEncoder when PreviewShell tries to serialize the accessibility tree on the AXRemoteElement-BackgroundFetch dispatch queue. The thread stack overflows into the stack guard region, causing EXC_BAD_ACCESS (SIGBUS) / KERN_PROTECTION_FAILURE. Environment: macOS 26.5 beta (25F5042g) Xcode 26.4 (17E192) Confirmed workaround: Setting a physical iOS device as the preview destination works correctly. The bug is isolated to the simulator runtime — PreviewShell on device does not go through the affected AXRemoteElement path. I've already filed a feedback report with the full crash log attached. I'd encourage everyone affected to file their own report — the more Incident IDs Apple has, the faster this gets prioritized.

Update — Working workaround found After extensive debugging, I found a two-part workaround that gives fully functional PiP with AVSampleBufferDisplayLayer on macOS. Root cause analysis The PiP window actually contains TWO stacked rendering paths: PIPPanel (contentView: 484×272) └─ AVPictureInPictureSampleBufferDisplayLayerView (1280×720) └─ AVPictureInPictureSampleBufferDisplayLayerHostView (layer = CALayerHost, contentsScale = 1.0) ├─ AVSampleBufferDisplayLayerContentLayer (734×413) ← correctly scaled video └─ AVPictureInPictureCALayerHostView (1600×900) ← broken overlay The good path (AVSampleBufferDisplayLayerContentLayer) renders the video correctly scaled to the PiP window size. The bad path (AVPictureInPictureCALayerHostView) is drawn ON TOP and is the source of all the visual problems. Inspecting its properties reveals: hasContents = false, sublayers = 0 — it contains no actual video content backgroundColor = solid black (CGColor gray=0, alpha=1) transform = [m11=0.8, m22=0.8, m33=0.8] — Apple applies

No, I don't use NSStatusBarButton in my codes, sorry. More generally, since I run Xcode on macOS 15, the number of such messages has become incredibly high... many of those logs have clearly nothing to do with what is under my control (the worse being when using UBSan and friends). This ultimately lead me to the deactivation of all logs (os_activity_mode=disable), but after that I couldn't even see some of my own logs anymore... I finally started using printf as a work around, but if someone knows a good solution to disable all system logs while keeping my own, I'm interested, thanks!

Xcode 26.4 still crashes. It's hard to believe this bug was reported so long ago, yet Xcode hasn't fixed it after so many versions 😓

Thanks for the post. Any chance you can provide a simple focused project we can download and run it to see what you are seeing? If so, please share a link to your test project. That'll help us better understand what's going on. If you're not familiar with preparing a test project, take a look at Creating a test project. What happens when you disable Liquid Glass? Do you get the results that you want? When you create a standard UIView (or SwiftUI View) that contains your custom buttons and layout and add custom view to the UITabBarController's view and anchor it to the bottom of the screen. When a user taps a button in your custom view, manually update the selected tab is when you get that result? Are you testing on iOS 26.4? What Xcode version are you using? Albert Pascual
  Worldwide Developer Relations.

same all morning, the developer system status page was updated 20min ago. Xcode Cloud has an outage now.

@DTS Engineer I started using the Xcode 26.5 Beta and this problem has not resolved.

Thank you for your response. I would like to clarify that all previously suggested steps have been completed: StoreKit Testing Disabled StoreKit configuration in Xcode is not used. The app connects directly to Apple’s sandbox environment for testing. Successful Sandbox Testing The In-App Purchase product (remove_ads, Non-Consumable) has been thoroughly tested in the sandbox environment. The StoreKit purchase sheet appears correctly, and the transaction completes successfully. A screen recording is available to demonstrate this behavior. Product Properly Submitted The In-App Purchase product is fully configured in App Store Connect and has been submitted for review together with the app version. Both the app binary and the IAP product are included in the same submission. Despite this, the app continues to be rejected again under Guideline 2.1(b) stating that Premium feature was still implemented without triggering any purchase flow.