“build disappears”

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

Thanks a lot for your answer! I'm currently trying to re-create an IAP and submit a new build with it. If that doesn't work, I'll create a feedback assistant ticket. Thanks for the suggestion!

This is still an issue on 26.3. @SubvertDev What I ended up doing was extracting the Icon Composer rendered icon variants from an Assets.car built with Xcode 26.0.1 and adding those back to the project as pre-rendered icons to the assets catalog. Updating the icons in the future will be a pain, but at least for now the app's compressed thinned size hasn't gone up by >20MB when building with Xcode 26.1 and later.

I found it! I searched the build settings for build in both apps and just went down the list, comparing every setting. The only difference was User Script Sandboxing, which was Yes in the smaller app and No in the larger app. When I turned that on in the larger app, it built files in batches like the smaller app, and finished in 38 seconds -- that's 21 times faster than before. This is going to make release days so much easier.

Hi, can you please confirm if you've already set up the product information in App Store Connect for the products you're looking to show in your app? Make sure that the products are shown as Ready to submit after adding all the required metadata so that you can use them in the TestFlight build. I would also highly suggest to take a look at this article around Testing In-App Purchases with sandbox and follow all the steps around checking the agreements, setting up the products in App Store Connect, and creating a sandbox Apple Account. Other useful resources you can check out from the docs: Submit an In-App Purchase Testing subscriptions and In-App Purchases in TestFlight