“show when run”

Maybe back up a bit. To distribute iOS apps to internal users of your organization, you need to have an Enterprise Developer account. You can then distribute your iOS apps via your own internal website, as described here: https://support.apple.com/guide/deployment/depce7cefc4d/web I don't have an Enterprise account, so that's all I can say about it. It sounds like you are trying to run iOS apps on your Macs. You can certainly do that. However, that is a feature designed for end users' convenience. From a developer's perspective, it isn't more convenient. You can bypass the complications of the Enterprise account by developing Mac-native apps. Then you can distribute them on your own website as DTS Engineer describes. The difficulty here is going to be how you develop the iOS apps. If you are developing stand-alone apps, you could use SwiftUI or the Mac Catalyst framework to built Mac apps using cross-platform or iOS APIs. But if you are using some 3rd party tool to build your iOS apps, then you'll ha

Thanks for the tips — both already in place. The test app calls finishTasksAndInvalidate() after each run and waits for urlSession(_:didBecomeInvalidWithError:) before proceeding; that's what made the qlog files appear reliably. And yes, I pulled everything into a standalone macOS app — that's where all the measurements below were taken. I've been systematically comparing configurations. The key variable is request size: our /api/launch POST has ~18 KB of headers (cookies, auth tokens, experiment flags) plus a small body. With URLSessionConfiguration.default, measuring requestStart→requestEnd from URLSessionTaskMetrics: H3 · large headers · modern engine · with prewarm 230 ms - 542 ms H3 · large headers · modern engine · no prewarm 34 ms-57 ms H3 · large headers · classic engine · with prewarm 24 ms-26 ms H3 · small headers · any config 0 ms H2 · any config 0 ms (because, as I understand it, sending packets here is at a different level in tcp and the implementation doesn't know when it sent the last

[quote='885813022, DTS Engineer, /thread/824156?answerId=885813022#885813022'] Some of the information here may already be obvious or well understood to you. [/quote] Thank you for taking the time to write all this down. That context is very helpful, especially as I'm not super familiar with the lower level Unix APIs related to this. [quote='885809022, DTS Engineer, /thread/824156?answerId=885809022#885809022'] I don't think that's a safe assumption and, in practice, I think you're very likely to see lots of cases where a lookup ISN'T generated. I don't think a basic ls will generate a lookup call and I'd expect/hope the Finder would avoid it at least some of the time. [/quote] Both of those expectations don't The second expectation doesn't seem to be what happens in reality, at least on macOS 15.7.5. I've been testing with a sample file system that has a directory with 10,000 items. When I do a time ls /Volumes/MyFS/dir, I see that a lookupItem call was done for every single item (actually, 2 for each item,

Hi @Kunal07 Thanks for the focused repro, that's genuinely helpful. Could selecting Lock In Place be causing the ImmersiveSpace to be dismissed, which is why the RealityView content vanishes? I'm not yet sure why this only reproduces under TestFlight and not when running locally from Xcode. I'd greatly appreciate it if you could open a bug report. Please include a zipped copy of the minimal Xcode project that reproduces the issue and a reference to this forum post, and post the FB number back here once you do. Bug Reporting: How and Why? has tips on creating your bug report.

When a trying into my device and I set to for example something I don’t have en-IE, the system's internal fallback resolution path looks like this: en-IEDoes the app have Ireland English? No. en-GB (Does the app have British English? Yes.) I have that one set. Because your app includes en-GB, the system stops at step 2. It determines that en-GB will provide a much better localized experience. This is exactly right. The system for choosing which language to show in the UI is somewhat complex, taking into account the user's preferred languages, the languages supported by the app itself, and language fallbacks. The language fallbacks also evolve as support for new languages is added to the operating system (and very occasionally over time, if feedback is given that specific fallback languages don't feel right).

How background tasks and HealthKit work on watchOS was somehow discussed here and here. You can check if they help. iOS has a similar background execution time budget, but isn't as strict as watchOS. In a normal situation (meaning that your app has background execution time budget, the device's battery level is high, and no many apps are competing the background execution time), I'd expect that the system wakes your app and runs the updateHandler of your observer query (HKObserverQuery) whenever a process saves or deletes samples of the specified type. The update frequency (HKUpdateFrequency) for sample types is another factor to consider. For example, stepCount samples have an hourly maximum frequency in iOS, and so the updateHandler will be triggered at most once per hour, even you use enableBackgroundDelivery + .immediate. This is documented in the Discussion section here. Now to your questions: Are HKObserverQuery delivery frequencies (.immediate, .hourly, .daily) strictly best-effort hints rathe

Part 1... Disclaimer: Some of the information here may already be obvious or well understood to you. If it is, then thank you for your patience as I use this as an excuse to push out background information that other developers may find useful. Oh, I think I was a little unclear in what I wrote. What I was trying to say in a call to enumerateDirectory of this nature was that if I call enumerateDirectory with a non-minimal attribute set (i.e. include attributes that need more I/O to fetch), then I see that behavior. But you're right in that iterating over a directory with minimal attributes doesn't generally have additional lookupItem calls in my tests. Again, you have to be careful of the API you're using. The classic Unix directory iteration pattern[1] is to read the directory (readdir-> enumerateDirectory) and then retrieve metadata (stat-> lookupItemNamed). There are two problems with that: At a basic level, it generates a lot of syscalls, each of which nibble away at performance. From the file syste

It turns out we were not able to reproduce the crash with the following steps: Downloaded and installed their attached test app onto both paired iPhone + Apple Watch. Allowed data type authorization requested by the app. On watch launch, background observer query should have started as they implemented in applicationDidFinishLaunching. Could see the HR samples being retrieved by the query in the app’s UI when new data was detected. Put app into background, waited some time, injected new sample. Waited an hour+, injected new sample. Repeated the waiting+sample injection a few times. RE-foregrounded app. Used their refresh UI button. Could see the new samples showing up in UI. In this whole process, we never experienced an app crash or noticed a “CSLHandleBackgroundHealthKitQueryAction watchdog transgression” log on the watch (had a stream open the entire time). For us to further investigate the issue, would you mind to: Provide more granular specific reproduction steps about how to reproduce the crash