“eskimo”

Earlier I wrote: [quote='884707022, DTS Engineer, /thread/821961?answerId=884707022#884707022'] The permanent solution will involve a fix to Xcode [/quote] which was a bit simplistic. There are actually three factors involved here: The capabilities assign to your team The Xcode version The Developer website The second two have recently been updated, and it’s possible that that’s sufficient to resolve this issue. If you try the obvious path forward with the latest Xcode 26.5 beta, do you still have problems? If you don’t, then you’re all set. If you do, then my advice from earlier stands. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887403022, apisdk, /thread/825833?answerId=887403022#887403022, /profile/apisdk'] We plan to transition our testing environment to use an App Store Organization team account [/quote] Cool. [quote='887403022, apisdk, /thread/825833?answerId=887403022#887403022, /profile/apisdk'] we won't be able to use our internally built stage-based automated build/distribution pipeline for this workflow [/quote] Keep in mind that you have a bunch of options to automate the TestFlight process, including: Command-line tools (xcodebuild, altool, and so on) Xcode Cloud The App Store Connect API So while you will need to change your process, you can still automate it. [quote='887403022, apisdk, /thread/825833?answerId=887403022#887403022, /profile/apisdk'] One piece of feedback I'd like to share regarding the Apple Developer Portal UX: [/quote] The best way to get that in front of the right folks is to file it in Feedback Assistant. See Bug Reporting: How and Why? for lots of hints and tips on that process. Please post y

[quote='887325022, fbartolom, /thread/825703?answerId=887325022#887325022, /profile/fbartolom'] I found a solution by making the closure sendable: [/quote] I don’t think that’s a valid solution. The closure passed to your application(handleEventsForBackgroundURLSession:completionHandler:) is not sendable, because it has to be called on the main thread. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887385022, greggwon, /thread/825449?answerId=887385022#887385022, /profile/greggwon'] And again, this is Mac (Designed for iPad) build [/quote] Ah, yeah, I got mixed up with the terminology. A “Mac (Designed for iPad)” build takes you down the iOS apps on Mac path, which is definitely not Mac Catalyst. Sorry about the confusion. iOS apps on Mac should follow iOS conventions, so: There’s no hardened runtime or App Sandbox, so no need for com.apple.security.device.audio-input or com.apple.security.device.microphone. You do still need NSMicrophoneUsageDescription. With that in mind, I sat down to try this out. Here’s what I did: Using Xcode 26.4 on macOS 26.4.1, I created a new test project. I wired up two buttons to some basic recording code (see below). In the Info tab of the target settings, I added a NSMicrophoneUsageDescription property. I ran the app on my iPhone. I tapped the Start button. iOS presented the microphone permission prompt. I tapped Allow. I spoke some words. I tapped the Stop button.

I can’t can think of a couple of cases where environment variables are dropped in a way that confuses folks: If the Hardened Runtime is enabled, certain dynamic linker environment variables are scrubbed. If you open an app from the Finder, it doesn’t pick up the environment variables you’ve set in Terminal. However, as Etresoft said, we need more info to be able off more reliable advice. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887338022, Nickkk, /thread/825481?answerId=887338022#887338022, /profile/Nickkk'] should I then extract the sysdiagnose and look in the system_logs.logarchive file? [/quote] Yes. Alternatively, if this happens on a Mac you control, you can generate a log snapshot like so: % sude log collect [quote='887338022, Nickkk, /thread/825481?answerId=887338022#887338022, /profile/Nickkk'] In the sysdiagnose I uploaded to Feedback Assistant I can only see the last 5 minutes, is that correct? [/quote] If you open the log in Console, it defaults to showing the last 5 minutes. The Showing popup between the two panes lets you control that filter. See the screenshot in this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Just to be clear, both U4ALRF5A38 and VELCFRZBHZ are Team IDs. [quote='887294022, iceboy, /thread/825789?answerId=887294022#887294022, /profile/iceboy'] this issue only happens on a few individual devices. [/quote] I’d like to clarify that point. So your app works on most devices? And then fails on some specific ones? Are the failing devices ones that you control? Or are you investigating this based on reports coming in from your users? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thanks for the extra info. Do you have a newer bug number for this? As I mentioned above, FB13640480 caused changes to be rolled out in macOS 15. That resolution means that the bug is effectively closed. If it didn’t fully resolve the issue then we need a new bug to drive further investigation. If you have a new bug number, I’d be interested in hearing about that. If not, my advice is that you file a new bug now, and then reply with that number. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

So I’m asking by a perspective as a consumer level of using VM apps built by other developers. Thanks for that clarification. The Apple Developer Forums are primarily focused on helping developer with code-level questions, so you’re not really in the right place. Having said that, I can provide some insight. macOS has two virtualisation APIs: Virtualization is a high-level API that makes it very easy to run a VM. Hypervisor is a low-level API for developers who need a lot of control. Neither has support for battery pass through. It’s feasible for a developer using Hypervisor to support battery pass through to guests that aren’t running macOS. Doing that for macOS guests would almost certainly require a bunch of unsupported reverse engineering. If you were a developer using these APIs then I’d recommend that you file an enhancement request for this feature. However, as a user of VM apps then that’s probably not the best path forward. It’s fine for users to file ERs for user-level stuff, but in this case you’d

This isn’t something we can help you with here on the forums. Rather, you need to continue to escalate this via official channels. For the details, see this post. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

The short answer here is “No.” This is the sticking point: [quote='825926021, Benim120, /thread/825926, /profile/Benim120'] only fires while app is running [/quote] You’re looking for an API that will resume or relaunch your app in the background when the network configuration changes. iOS has no such API. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

[quote='887014022, dverevkin, /thread/786223?answerId=887014022#887014022, /profile/dverevkin'] that does not appear to be the case [/quote] Agreed. Since I posted that my understanding of how this stuff works has shifted, meaning that I no longer believe that the key is tied to your App ID. When you think about this it kinda makes sense. When you store a SE-protected key in the keychain, you have the option to put it in a keychain access group that’s accessible by multiple apps. If the key bytes were tied to your App ID, those other apps wouldn’t be able to use the key. So, I repeated you tests here in my office, and I see the same results. I’m able to successfully pass an SE-protected key between two apps (running on iOS 26.4.2). Pasted in below are the code snippets I used for this. Thanks for setting things straight here! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com For the source app: func generateAndSaveKey() throw

I’ve responded over on that other thread because there’s no point having two threads going concurrently. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

In their thread PrathibhaD wrote: [quote='887017022, PrathibhaD, /thread/825491?answerId=887017022#887017022, /profile/PrathibhaD'] is there … any plan from Apple to fix it in upcoming releases? [/quote] I can’t talk about The Future™. You won’t be able to see the status of oleksandr91’s bug directly. However, if you file your own bug and ask that it be marked as a duplicate of theirs (FB22704560), you’ll be notified if and when we start seeding a build with a fix. [quote='887017022, PrathibhaD, /thread/825491?answerId=887017022#887017022, /profile/PrathibhaD'] is there any particular fix for making the window act as the first responder … ? [/quote] It’s hard to suggest a focused workaround with knowing what the underlying cause is, which we don’t. However, you’re working with an NSView so you have access to AppKit. For example, you might get the view’s window, via the window property, and then start messing with that, for example, calling -makeKeyAndOrderFront: on it. Normally I wouldn’t suggest such shenani

Thanks for those extra titbits. Using that, I was able to reproduce the problem: Using Xcode 26.4, I created a new project from the iOS > App template, choosing Swift as the language. I set the deployment target to iOS 17.7. And chose Any iOS Simulator as the run target. I added the Enhanced Security capability and checked Enable Hardware Memory Tagging. At this point things were still building just fine. I added a new Objective-C class to the project. And lo! that triggers the problem. I then raised the deployment target up to iOS 18.6 and the problem went away. So, it seems like the combination of a simulator build for iOS 17 with MTE enabled. Interesting. That’s clearly a supported configuration, so you should definitely file a bug about this. Once you’re done, reply here with your bug number so that I can add my own internal comments to it. How much testing do you do in the iOS 17 simulator? If the answer is “None at all.” you could work around this by temporary raising the deployment target for your s