“show when run”

I want to clarify a few points from both your original post and Albert’s response. You’re using the term keyring, which is not a thing on Apple platforms. Rather, the equivalent thing is called the keychain. Using the right term will help, for example, when you go searching for documentation. macOS has two keychain implementations: The file-based keychain The data protection keychain We generally recommend the data protection keychain. However, you’re building a Network Extension transparent proxy, and those are generally packaged as a system extension [1]. Sysexen are roughly equivalent to a launchd daemon, and cannot use the data protection keychain. They can only use a file-based keychain, typically the System keychain. TN3137 On Mac keychain APIs and implementations talks about this stuff in much more detail. When talking about extensions on Apple platforms, it’s important to get your terminology straight. The application in which the extension is embedded is called the container application. The host app

As a software developer, my daily workflow involves running large numbers of terminal sessions simultaneously (tmux, multi-project workspaces, automation scripts, node-pty connections, etc.). The default PTY limit of 511 is far too low for modern development workflows. Furthermore, this default value is identical across all hardware — a maxed-out Mac Pro with 128GB RAM has the same 511 limit as a base-model MacBook Air, which doesn't scale with hardware capabilities. I've tried tmux control mode to reduce PTY usage, but it causes terminal output alignment issues that make it impractical for daily use. This means I must use PTY mode, and hitting the 511 ceiling is a frequent occurrence. Once the limit is reached, no new terminals can be created system-wide — not just in my app, but across Terminal.app, iTerm2, VS Code, and any other terminal-dependent process. This becomes a system-wide stability issue. Summary: 511 is an outdated default for modern developer workflows No hardware-aware scaling — same

I got a reply from Apple Support: To protect customer privacy, Apple shows App Analytics data only when a certain number of data points are available. The data is aggregated so that customers can remain anonymous. As soon as there are enough data points to show, you'll see your App Analytics data. This brings 0 bits of new information to the table, it's what we all suspected anyway and it's what any AI would say on this question. I need to know more precisely when the analytics appears. At least to do some planning and give estimates to myself and my clients. I would continue begging them for information. This would be especially important soon, because Trends would be removed – currently it's the only source of information about installs & In-App Purchases. Imagine in the future you won't be able to know anything about your app, even 2 months after release. What a torture. I now regret respecting user privacy and not installing third-party analytics.

Hi Thanks a lot for your previous hint — it helped me fix the bundle setup. I now have the following confirmed: The report extension is correctly embedded under: Work4Fun.app/Extensions/UsageReportExtension.appex Info.plist uses: EXAppExtensionAttributes → EXExtensionPointIdentifier = com.apple.deviceactivityui.report-extension Entitlements include: com.apple.developer.family-controls com.apple.developer.family-controls.app-and-website-usage App Group The compiled binary clearly contains my code (UsageReportExtension.init, makeConfiguration, etc.) However, at runtime: DeviceActivityReport is instantiated (I see my view appear) System logs show: Plugin query method called But the extension is never actually executed: no init no makeConfiguration no output file written in App Group I also tried: deleting the app rebooting the device reinstalling from Xcode re-authorizing Screen Time → same result So it looks like: → iOS resolves the extension, but does not launch it Have you seen this behavior before?

Hello, We're reviving of a very old app, we need to use the same app-id. The new one requires NFC and, so, it can now only run on iPhone. is it possible to force the UIRequiredDeviceCapabilities ?

[quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] my expectation would be that iterating the directory with geattrlistbulk and a minimal attribute set would avoid any additional lookupItem call [/quote] 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. [quote='885683022, DTS Engineer, /thread/824156?answerId=885683022#885683022'] What kind of filesystem are you working with? [/quote] It's a block device file system. I think maybe cached data wasn't the best word for me to use... I'm referring to references I'm keeping to instances of my subclass of FSItem. I have a helper function implemented on my subclass to get the non-

When the device is connected while Preview is running, I observe the host send OpenSession, then GetDeviceInfo, and then no further MTP commands. I do not see a later CloseSession. I don't know enough about your accessory to be certain about exactly what's going on, but I think what's actually happening here is that Preview is indirectly causing the session to open through its interactions with ImageCaptureCore. However, that also means that Preview doesn't really own/control the device itself; the major role of the ImageCapture framework is to allow multiple apps to interact with the same accessory. The problem is that once this happens, exclusive access to the USB interface is retained, so another application cannot connect to the device. What API are you actually trying to use here? From the device side, there is no obvious way to recover except forcing a USB disconnect/reset or shutting down the USB interface. Well... yes. There's no way for your accessory to know about the state of the connectin

Furthermore, Terminal responded that sysdiagnose must be run as root. I don't know how to do that.