“build disappears”

Still experiencing this issue on macOS 26 (Tahoe). We are seeing the same storefront region mismatch when testing IAP via TestFlight on macOS. Our observations: Machine-dependent: some macOS 26 machines can complete sandbox purchases, others cannot. Observed working on some 26.2 machines and failing on some 26.3 machines, though we have not confirmed OS version as the sole factor. The workaround of signing out of System Settings > Apple Account > Media & Purchases works, but it also signs out the system account, which is disruptive. The issue appeared after we submitted our build for TestFlight external testing review (public beta). Before that, with internal TestFlight testing only, this was not reported. This follows the same regression pattern others have reported: fixed in 15.2, regressed in 15.3+, and now recurring in macOS 26. Filed as FB22050500 with sysdiagnose logs.

I have had an app in waiting for review for almost 10 days. I also have a TestFlight build of another app that’s been in review for 4 days. the test flight delay is nuts.

Yes, same here. Submitted TestFlight external test (beta) app builds on Feb 09. The macOS build was approved Feb 11. The iOS build is still waiting for review. I upped the build number once, no dice. I requested a support ticket (email), no response. I had them call me. To their credit they called immediately. Explained the situation. The lady said she sent an 'expedite review request' to the review team. As a first time indie developer (first app), I am so excited to get my creation out there, and so distressed at this friction before I can even have beta testers test it. 24 hours after the alleged 'expedited review request', still waiting.

I'm having the same issue right now. It has been working up until this point and without changing anything, suddenly pushing tags it doesn't even find them. I'm trying to build a branch first as the instructions above describe.

I guess my wish would be for NSURL to either cache forever until explicitly cleared values or not cache at all because if we're caching on a cache that may not be a cache but sometimes it seems like a cache it's hard to cache. So, the first issue here is that not caching at all isn't really an option. Most of the data you retrieve from NSURL all came from the same API (getattrlist) and, much of the time, that data is ALWAYS retrieved in every call. getattrlist() is a bulk fetch API (it's designed to return a bunch of data at once) and the vast majority of the performance cost here is the cost of the syscall itself, NOT the retrieval of the data itself or the copy out of the kernel. Putting that in concrete terms, let’s say you ask for all of the times for a file (ATTR_CMN_CRTIME, ATTR_CMN_MODTIME, ATTR_CMN_CHGTIME, ATTR_CMN_ACCTIME, ATTR_CMN_BKUPTIME): Basically every file system is going to end up storing all of those values inside some kind of file system-specific structure, so the only cost here is the act

Hi, Thank you for your reply. It is important work within the exact same environment. I am currently using Xcode 26.2 with the iOS 26.0 simulator iPhone 17 or iPhone17 pro (should happen of any of them), and I was able to reproduce the issue on other MacBooks as well with same environment. During our investigation of crash reports, we found that this issue occurs in production on certain iOS versions. Reproducing it locally in the simulator has been the only reliable way to validate the behavior. I would greatly appreciate your assistance with this matter. The problem does not appear to be related to UIKit. I can reproduce it in SwiftUI using Text as well. Unfortunately, the stack trace is not very informative. The crash also occurs when simply passing this specific character to Safari within the simulator. In most cases, the crash can be reproduced by adding the character to a project and building it with the iOS 26.0 simulator using iPhone 17. When running the same project on iOS 26.0.1, the issue

I chatted with my Core Bluetooth colleague about this, and we’re not entirely sure how the failure you’re seeing can be caused by your execution context. Which isn’t to say that it’s not the case, just that the connection isn’t obvious. I usually debug problems like this in small steps. For example, in your case: I would build my agent as an app, with a menu bar and everything. I’d run that from the Finder (or Xcode) and see if Bluetooth behaves in that case. I’d then set it to run as a launchd agent, but still with the menu bar. And re-test Bluetooth. If that works, you know that the launchd agent context isn’t the cause of your issue. Finally, I’d then switch it to run without a menu bar by setting LSUIElement. And re-test Bluetooth again. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='877018022, vishalsehgal, /thread/815465?answerId=877018022#877018022, /profile/vishalsehgal'] We wanted to reduce the kernel overhead of assembling bytes that receiveMessage(completion:) does. [/quote] I have two things to note about this. First, there’s no guarantee that your network connections are being run by the kernel. Our platforms have a user-space networking stack and Network framework will choose that over the in-kernel stack in many common cases. Second, I’m concerned about this concept of “assembling bytes”. In general, UDP datagrams shouldn’t be fragmented and thus there’s no assembling of data at all. A packet arrives, it contains the full UDP datagram, and the content of that datagram is delivered to you. If you’re building something that does fragment UDP datagrams — that is, it sends datagrams that are larger than the path MTU and thus are subject to IP fragmentation — then it’d be better to work on not doing that rather than trying to worry about optimising this path. Moreov