“show when run”

Hi, In the app I’m working on, we rely on SecKeychainUnlock to verify that a password can be used to unlock the login keychain. When macOS 26.4 rolled out, we started getting bug reports that led me to a discovery that makes me think SecKeychainUnlock behavior was changed. I’m going to illustrate my findings with a sample code: #include #include #include #include #include #pragma clang diagnostic ignored -Wdeprecated-declarations int main(void) { char password[100]; printf(password: ); scanf(%s, password); struct passwd *home = getpwuid(getuid()); if (!(home && home->pw_dir)) return 1; char path[1024]; strcat(path, home->pw_dir); strcat(path, /Library/Keychains/login.keychain-db); SecKeychainRef keychain = NULL; OSStatus result = SecKeychainOpen(path, &keychain); if (result != errSecSuccess) { fprintf(stderr, SecKeychainOpen failed (error %d)n, result); return 1; } SecKeychainStatus status = 0; result = SecKeychainGetStatus(keychain, &status); if (result != errSecSuccess) { fprintf(

Hi, I see an interaction issue between a DNS Proxy system extension and MDM on macOS: after some time the device stops processing MDM commands until reboot, while DNS filtering continues to work. Environment: macOS: 15.x / 26.x (reproduced on multiple minor versions) App: /Applications/MyMacProxy.app System extension: NEDNSProxyProvider as system extension Bundle id: com.company.agent.MyMacProxy.dnsProxy Deployment: MDM (SimpleMDM) DNS proxy config via com.apple.dnsProxy.managed Devices: supervised Macs Steps to reproduce: Enrol Mac into MDM. Install MyMacProxy app + DNS proxy system extension via pkg and apply com.apple.dnsProxy.managed profile. DNS proxy starts, DNS is filtered correctly, user network works normally. After some hours, try to manage the device from MDM: push a new configuration profile, remove an existing profile, or install / remove an app. 5.MDM server shows commands as pending / not completed. On the Mac, DNS is still filtered via our DNS proxy, and general network access (Safari

Hello! We built a macOS .pkg using pkgbuild (contains a DMG + postinstall bash script). The pkg works locally on the build machine but fails on other devices manually / via MDM unless signed. We tried signing with a Developer ID Installer certificate, but: security find-identity -p codesigning -v → 0 valid identities security find-identity -v → shows the cert Private key is present in Keychain OpenSSL check shows: X509v3 Extended Key Usage: Critical (Expected one might be: Code Signing) We recreated CSR + cert multiple times (G2 Sub-CA), ensured Login keychain, unlocked keychain, etc., but same result. Question: Why is the Developer ID Installer cert missing Code Signing usage and not recognized for signing? Is there any account restriction or step we might be missing? Any recommendations on resolving this issue. Thanks!

When running top-level async code in Swift Playgrounds, the LLDB RPC server crashes. For example, when running the following code from Concurrency section of The Swift Programming Language book: func fetchUserID(from server: String) async -> Int { if server == primary { return 97 } return 501 } let userIDs = await withTaskGroup(of: Int.self) { group in for server in [primary, secondary, development] { group.addTask { return await fetchUserID(from: server) } } var results: [Int] = [] for await result in group { results.append(result) } return results } print(userIDs) Xcode reports that the LLDB RPC server has crashed. The Swift Playground app reports “There was a problem running this playground.” However, in the case of the Swift Playground app, results are populated as expected. For example, the console shows “[97, 501, 501]”. Xcode does not print any results in the console. Tested with Xcode 26.4 (17E192) and Swift Playground Version 4.7 (2088). Wrapping the async code

Hi all, Apple dropping on-going development for FireWire devices that were supported with the Core Audio driver standard is a catastrophe for a lot of struggling musicians who need to both keep up to date on security updates that come with new OS releases, and continue to utilise their hard earned investments in very expensive and still pristine audio devices that have been reduced to e-waste by Apple's seemingly tone-deaf ignorance in the cries for on-going support. I have one of said audio devices, and I'd like to keep using it while keeping my 2019 Intel Mac Book Pro up to date with the latest security updates and OS features. Probably not the first time you gurus have had someone make the logical leap leading to a request for something like this, but I was wondering if it might be somehow possible of shoe-horning the code used in previous versions of Mac OS that allowed the Mac to speak with the audio features of such devices to run inside the Ventura version of the OS. Would it possible? Would i

Fellow Apple Developers and Apple Developer Support Team, If you’re seeing the message **“Your enrollment is being processed. Your enrollment ID is **” for weeks (or longer) with no updates, no follow-up emails, and no access to App Store Connect, you are not alone. I’m posting this in the hope of helping everyone experiencing the same frustrating delay and giving Apple a clear, visible signal that this is impacting real developers right now. My Situation (and Why It Matters) I submitted my Apple Developer Program enrollment several weeks ago, completed payment successfully, and have since sent two support emails requesting an update. The status remains unchanged. Meanwhile, my app is already live and performing well on Google Play. I’m ready to submit the iOS version, but I cannot even reach TestFlight or App Store Connect because the enrollment is still “processing.” Like many of you, I’ve read dozens of identical threads here on the forums and on Reddit in the past month alone—individual enrollments, organ

I have an app I am working on that makes a REST call, updates the UI with the info, and sends a notification. When I run Build and Run my app from Xcode using my iPhone as the destination, it works exactly as I want it to - my REST calls and notifications continue to work when the app is in the background. However, when I run my app that has been installed on my iPhone from the Xcode build/run directly (without Xcode in the picture), it does NOT behave correctly and only works when my app is in the foreground. What am I missing?

We’re having an iPad issue accessing the local network with iPadOS 26.3. We have an automation system that tests our app on an iPad using accessibility tags. the XCTest test code sends messages from the iPad via TCP/IP to setup external test equipment. The messages abruptly stopped transmitting across the iPad blood-brain barrier with iPadOS 26.3 (26.2.1 and earlier works fine). The technique that worked involved installing a helper app with the same bundleID as our app, allowing the helper app to access the network, and when our app runs it has network access through the helper. It’s clever and kludgey. Forums that we referenced in the past: https://developer.apple.com/forums/thread/663858 TN3179: Understanding local network privacy | Apple Developer Documentation I suspect that something was changed in 26.3 that closed our window. I need two things: ID what is different in 26.3 and fix the automation system. If there’s a new way for XCUITest code to access the local network I’m happy to try it out.

Environment: Xcode Version: Xcode 26.3 Affected iOS Versions: iOS 26.1 and later Working iOS Versions: iOS 26.0 and earlier Tested Devices: iPhone 15 Pro (iOS 26.2) - ❌ Bug presents iPhone 17 (iOS 26.1) - ❌ Bug presents iPhone Air (iOS 26.0) - ✅ Works as expected iPhone 16 Pro Max (iOS 18.0) - ✅ Works as expected Description: We have identified a severe localization regression regarding the setAlternateIconName(_:completionHandler:) API starting from iOS 26.1. Our application is strictly restricted to support only Traditional Chinese (zh-TW / zh-Hant). We have correctly configured CFBundleLocalizations, CFBundleDevelopmentRegion, and explicitly set CFBundleAllowMixedLocalizations to YES in our Info.plist. In iOS 26.0 and earlier, when changing the app icon, the system alert correctly displays in Traditional Chinese. However, in iOS 26.1 and later, the alert unexpectedly falls back to English, completely ignoring the app's localization constraints and the user's preferred device language. Crucial Observation: