“build disappears”

Thank you for sharing your post. I understand that it can be frustrating, especially when the job is impacting your daily routine. I am eager to assist you in any way I can. I have a potential idea, but I would like to request a bug filing for further investigation. Typically, authentication tokens expire after a few hours. In a stable build, Xcode silently uses a “refresh token” to obtain a new session in the background. Consequently, the system may be terminating your session when the initial token expires. This is an issue that requires immediate attention. However, I am only speculating about the cause. Given that this issue is occurring across two separate computers and began specifically in beta 3, it is highly probable that the problem lies within the beta itself rather than a misconfiguration on your end. Instead of simply signing out and signing back in, I recommend completely deleting the integration from Xcode. Navigate to Xcode > Settings > Accounts (or the specific Claude Agent set

Thank you, I will file a bug report. For anyone else that finds this, the scrollbar: always shows on my Mac Mini (mouse and keyboard only) does not show on my Macbook Air (trackpad) automatically shows when I connect a bluetooth mouse to the Macbook Air, but still does not allow mouse interaction. When I turn off the bluetooth mouse, the scrollbar disappeared. The trackpad allows for scrolling the chart with 2-finger swipe gestures, with or without the bluetooth mouse connected.

All apps should build with the latest SDK, so you have access to the latest APIs, regardless of the distribution mechanism used. Regarding the UIDesignRequiresCompatibility questions, it's useful to see how this was described in the WWDC25 Platforms State of the Union: As you evaluate your app's UI and the time you need to adopt the new design, we're providing an option to continue to use your app's current design with Xcode 26. We intend this option to be removed in the next major release. Hopefully you're on your way with the adoption of the new design already, or have upcoming plans to tackle it. You'll have to look at your own specific situations and determine how long you can continue using it for specific hot fix situations against the above statements and the timing of your own planned adoption of the new design. What are the potential issues if a team continues development on Xcode 16 while others have migrated to Xcode 26? For example, could there be compatibility, build, or integra

Swift and Memory Safety What enhanced security features are useful for fully Swift apps? Enabling enhanced security features like PAC, EMTE, and typed allocations is still useful in Swift apps. In certain language modes, Swift apps which do not use unsafe can still have memory corruption issues due to data races (concurrently modifying a reference can cause reference counting errors). Similarly, although your application may be fully safe Swift, it may interact with libraries (provided by Apple or third parties) which are not fully memory safe, and so turning on enhanced security features will help protect you against issues not caused by your code. How can I use unsafe Swift methods safely? Methods with unsafe in the name can be used safely, but it requires more care and attention to do so. You won't always be able to avoid using such methods, but you can carefully isolate such code and of course make sure to devote more effort to reviewing and verifying any code that uses unsafe methods or types. How can I

is the issue fixed and may i know the root cause? Thank you This particular issue was determined to be an accessory failure, caused by the developer reducing the CHIP_IM_MAX_REPORTS_IN_FLIGHT constant from it's default value of 4 to 2. The difference between the working and failing cases where then caused by small differences pairing implementation, which then altered the report timing. I don't know why they original reduced that constant but, in general, altering this sort of constant in a hardware implementation is something I would recommend against. Part of the reason reference platforms exists is that, in practice, it's very difficult for platform and accessory implementors to create products the perfectly interoperate. Theoretically that's addressed by increasingly detailed specifications but anyone who's spent significant time reading a hardware specification knows that increased detail isn't necessarily all that helpful. Reference platforms help smooth out that process by providing a standardized impl

Hi, We are also affected by this TestFlight issue. The build is visible for internal testing, but when testers tap Install, TestFlight says: “The requested app is not available or doesn't exist.” We already checked the usual things and even tried creating a brand new app record, but the exact same problem still happens. It looks like many developers have run into this before. If anyone has a confirmed solution, please help share it. Was it: an Apple/TestFlight backend issue? an account/app distribution state issue? something Apple Support had to manually fix? Any real experience would be greatly appreciated.